A post-quantum cooperative authentication method and system based on handshake message binding

Abstract

The application discloses a post-quantum cooperative authentication method and system based on handshake message binding, and belongs to the technical field of network security, VPN and TLS secure communication. In view of the technical problems that in the scene of VPN remote access and zero trust, the private key of the server is leaked, the gateway is imitated, and the post-quantum signature is easily replayed or degraded due to the lack of binding with the certificate identity and the security policy, the application obtains authentication correlation factor data containing at least post-quantum policy information, and generates binding data by mixing and matching, and sends the post-quantum cooperative signature generated by the signature coordination module in the node group according to the threshold aggregation to the handshake message, the client recalculates the binding data and combines the authentication elements to jointly verify, and the identity is confirmed by time, so that the reliable binding of the post-quantum enhanced authentication and the TLS session is realized without replacing the existing certificate system, and the risks of private key leakage, signature replay and policy degradation are effectively resisted.

Description

Technical Field

[0001] This invention relates to the fields of network security, VPN and TLS secure communication technology, and in particular to a post-quantum collaborative authentication method and system based on handshake message binding. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] In real-world deployment scenarios such as Virtual Private Network (VPN) gateways, zero-trust access systems, and remote office access platforms, the server is typically deployed at the entry point in a data center or cloud, providing secure remote access services to clients distributed across different network environments. The server needs to verify its identity to the client via a TLS control channel to ensure that the client is connecting to a legitimate access point and not a spoofed gateway.

[0004] In existing solutions, the server relies on a single device to hold a private key for the national cryptographic SM2 elliptic curve public-key cryptosystem (ShangMi 2, SM2), RSA public-key cryptosystem (Rivest-Shamir-Adleman Public-Key Cryptosystem, RSA), or Elliptic Curve Digital Signature Algorithm (ECDSA) to generate a traditional signature for authentication. However, the development of quantum computing has exposed this system to long-term security risks. Furthermore, once the single point of private key is leaked, attackers can impersonate the server at any geographical location, induce a large number of clients to connect to a malicious gateway, and thus steal sensitive data from the enterprise's internal network.

[0005] Even if attempts are made to enhance the signature by introducing post-quantum signatures, the existing schemes only treat it as independent additional data and do not cryptographically bind it to the session parameters, server certificate identity, and security policies specific to the current Transport Layer Security (TLS) protocol. Attackers can still bypass the enhanced protection by replaying old signatures, replacing certificates, or inducing the system to fall back to the traditional authentication mode. As a result, the identity authentication security of critical entry devices such as VPN gateways and zero-trust access points cannot be reliably guaranteed. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a post-quantum collaborative authentication method and system based on handshake message binding. By hashing the handshake message, certificate identity, and post-quantum policy encoding into binding data, and scheduling the node group to collaboratively sign it before sending it to the client for joint verification, a secure authentication method and system that is resistant to replay, degradation, and private key leakage is achieved.

[0007] To achieve the above objectives, the present invention is implemented through the following technical solution: In a first aspect, the present invention provides a post-quantum collaborative authentication method for a server, comprising: Obtain authentication association factor data that includes post-quantum authentication strategy information; The authentication association factor data is encoded according to a preset encoding rule, and a cryptographic hash operation is performed to generate binding data. The binding data is sent to the signature coordination module, so that the signature coordination module schedules the corresponding collaborative signature node group to perform post-quantum collaborative signature operation on the binding data according to the post-quantum authentication strategy information, and aggregates and generates post-quantum collaborative signature data when the threshold condition is met. The post-quantum collaborative signature data is sent to the client as authentication data bound to the handshake message used for identity authentication, so that the client can regenerate or verify the bound data and perform joint verification with authentication elements. If all verifications pass, the server-side identity authentication is confirmed to be successful.

[0008] Furthermore, the authentication association factor data also includes at least: The current TLS handshake message digest information, the certificate identity information corresponding to the server's digital certificate, the client's random number, and the server's random number.

[0009] Furthermore, the post-quantum authentication strategy information includes at least: a post-quantum signature algorithm identifier, a collaborative signature node group identifier, a threshold strategy identifier, a degradation control strategy identifier, and a public key binding identifier.

[0010] Furthermore, the binding data is also used to ensure that the post-quantum collaborative signature data is simultaneously limited to this TLS handshake session, the identity corresponding to the server digital certificate, and the post-quantum authentication strategy adopted this time.

[0011] Furthermore, the collaborative signature node group includes multiple collaborative signature nodes, each of which stores a signature authorization credential, a share of the post-quantum signature private key, or node key material used to generate the post-quantum collaborative signature. The threshold condition corresponds to the t-of-n collaborative signature strategy, where n is the total number of collaborative signature nodes and t is the minimum number of valid partial signatures that meet the aggregation requirements.

[0012] Furthermore, the post-quantum collaborative signature data is encapsulated in an additional authentication message that has a handshake message binding relationship with the CertificateVerify message, a TLS extended field, a VPN control channel custom authentication payload, or a server authentication additional field and sent.

[0013] Furthermore, the joint verification of the authentication elements includes at least: Verify the certificate chain of the server-side digital certificate, verify whether the traditional signature matches the current TLS handshake message digest, verify whether the quantum collaborative signature data corresponds to the bound data, verify the public key binding relationship corresponding to the public key binding identifier, and verify whether the downgrade control policy identifier conforms to the client's local security policy.

[0014] A second aspect of the present invention provides a post-quantum collaborative authentication method for a client, comprising: Receive authentication association factor data and post-quantum collaborative signature data sent by the server; Regenerate binding data based on the authentication association factor data, and verify it with the binding data associated with the received post-quantum collaborative signature data; After the binding data verification is passed, the authentication elements in the authentication association factor data and the post-quantum collaborative signature data are verified by combining the authentication element joint verification. Once all verifications pass, the server-side identity authentication is confirmed to be successful. The authentication association factor data includes at least post-quantum authentication strategy information. The post-quantum collaborative signature data is generated by the signature coordination module scheduling the corresponding collaborative signature node group to perform post-quantum collaborative signature operations on the bound data according to the post-quantum authentication strategy information and aggregating it when the threshold condition is met. The bound data is generated by the server encoding the authentication association factor data according to the preset encoding rules and performing cryptographic hash operations. The post-quantum collaborative signature data is bound to the handshake message used for identity authentication.

[0015] A third aspect of the present invention also provides a post-quantum collaborative authentication method based on handshake message binding, comprising: The server obtains authentication association factor data, which includes at least post-quantum authentication strategy information. The server encodes the authentication association factor data according to a preset encoding rule and performs a password hash operation to generate binding data; The server sends the binding data to the signature coordination module; the signature coordination module, based on the post-quantum authentication strategy information, schedules the corresponding collaborative signature node group to perform post-quantum collaborative signature operations on the binding data, and aggregates and generates post-quantum collaborative signature data when the threshold condition is met, and returns the post-quantum collaborative signature data to the server; the server sends the post-quantum collaborative signature data to the client as authentication data that is bound to the handshake message used for identity authentication; The client receives the authentication data, regenerates or verifies the binding data, and performs joint verification with the authentication elements. If all verifications pass, the client confirms that the server-side identity authentication is successful.

[0016] In a fourth aspect, the present invention also provides a post-quantum collaborative authentication system based on handshake message binding, comprising: a server and a client; The server is configured to: acquire authentication association factor data, which includes at least post-quantum authentication strategy information; encode the authentication association factor data according to a preset encoding rule and perform a cryptographic hash operation to generate binding data; send the binding data to the signature coordination module and receive post-quantum collaborative signature data returned by the signature coordination module; and send the post-quantum collaborative signature data to the client as authentication data bound to the handshake message used for identity authentication. The client is used to receive the authentication data, regenerate or verify the binding data, and perform joint verification with authentication elements. If all verifications pass, the client confirms that the server-side identity authentication is successful.

[0017] Compared with the prior art, the beneficial effects of the present invention are: This invention can be deployed in scenarios such as VPN remote access, zero-trust gateways, and enterprise private network entry points. In these scenarios, post-quantum authentication policy information is used as a key component of authentication association factor data. After encoding and hashing to generate binding data, it is sent to the signature coordination module. The signature coordination module schedules the corresponding collaborative signature node group to perform collaborative signing on the binding data according to the post-quantum authentication policy information. When a threshold condition is met, it aggregates and generates post-quantum collaborative signature data, enabling the server to complete the post-quantum signature without possessing the complete private key. This effectively reduces the risk of VPN gateways or zero-trust access points being impersonated by attackers due to server private key leakage, thereby inducing a large number of remote clients to access the internal network. At the same time, the post-quantum collaborative signature data is bound and sent with the handshake message used for identity authentication. When the client recalculates the bound data and performs joint verification with authentication elements, it can confirm the consistency between the post-quantum authentication result and the current TLS handshake session, the server certificate identity, and the authentication policy. This prevents attackers from bypassing the enhanced protection by replaying old signatures, replacing certificates, or downgrading to traditional authentication modes. This invention achieves reliable binding of post-quantum enhanced authentication and TLS handshake without replacing the existing certificate system, and is suitable for network entry point protection scenarios that require long-term security for remote access. Attached Figure Description

[0018] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0019] Figure 1 This is a flowchart of the method according to Embodiment 1 of the present invention; Figure 2 This is a schematic diagram illustrating the relationship between the generation and verification of bound data and post-quantum collaborative signature data in this invention; Figure 3 This is a schematic diagram of the OpenVPN control channel application process of the present invention; Figure 4 This is a schematic diagram of the post-TLS quantum collaborative authentication method of the present invention; Figure 5 This is a schematic diagram of the structure of the TLS-based quantum collaborative authentication system of the present invention; Among them, 100 is the client; 200 is the server; 300 is the signature coordination module; 400 is the collaborative signature node group; 500 is the policy configuration unit; and 600 is the underlying cryptographic library. Detailed Implementation

[0020] The following detailed description is exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0021] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0022] In this embodiment of the invention, the data collection and processing strictly adhere to the requirements of relevant laws and regulations, obtaining informed consent or separate consent from the data subject, and conducting subsequent data use and processing within the scope of laws, regulations, and the data subject's authorization. All data acquisition in this embodiment is based on compliance with laws and regulations and user consent, representing the lawful application of the data.

[0023] Terminology Explanation: Client: The client that initiates and verifies TLS control channel authentication.

[0024] Server-side: The server sends the server-side digital certificate and triggers the post-quantum collaborative signature.

[0025] Signature Coordination Module: This module schedules and coordinates signature node groups and aggregates partial signature data.

[0026] Collaborative signature node group: A node group consisting of multiple collaborative signature nodes.

[0027] Collaborative signature nodes: Nodes that store node key materials and generate partial signature data.

[0028] Underlying cryptographic library: A cryptographic library that performs traditional cryptographic operations and post-quantum verification-related operations.

[0029] Transport Layer Security (TLS) control channel: A control connection established based on the TLS handshake process for authentication, key negotiation, and security parameter negotiation.

[0030] Server-side digital certificate: A digital certificate or digital certificate identity information used to represent the identity of the server and can be verified by the client.

[0031] Post-quantum collaborative signature data: Authentication data jointly generated by multiple collaborative signature nodes based on the post-quantum signature algorithm or post-quantum signature strategy, which is used to prove that the bound data has been authorized and signed by the collaborative signature node group.

[0032] Policy configuration unit: A configuration file, database, policy service, module, or device used to provide post-quantum authentication policy information.

[0033] The terms mentioned above are commonly used technical terms in this field, but they have specific meanings in the context of this invention. Those skilled in the art should understand these terms in conjunction with the overall technical solution of this invention. The following embodiments will provide a detailed description of the technical solution of this invention to facilitate its implementation by those skilled in the art.

[0034] Example 1 As described in the background section, in scenarios such as VPN gateways, zero-trust access, and remote work, the server relies on the SM2 / RSA / ECDSA private key held by a single device to complete identity authentication in the TLS control channel. This faces both the long-term security threat of quantum computing to traditional public-key cryptography and the risk of server identity being forged due to a single point of private key leakage. Even with the introduction of quantum signature enhancement, existing solutions do not bind them to the current handshake session, certificate identity, and security policies. Attackers can still bypass the protection by replaying the signature, replacing the certificate, or downgrading to the traditional mode.

[0035] To address the aforementioned issues, this invention, while retaining the existing certificate system, involves the server combining the TLS handshake message digest, certificate identity information, a post-quantum authentication policy including algorithms and threshold policies, and a double-random number encoded hash into binding data. This binding data is then aggregated by a collaborative signature node group via a signature coordination module, generating a post-quantum collaborative signature based on thresholds. This signature is sent to the client as authentication data bound to the identity authentication message. The client recalculates the binding data and performs joint verification of the certificate, traditional signature, post-quantum signature, and policy. Identity is confirmed only when all verifications pass. Thus, without replacing the existing certificate system, this invention achieves reliable binding of post-quantum enhanced authentication with the handshake session, certificate identity, and security policy, effectively resisting post-quantum computing attacks, single-point private key leakage, signature replay, and policy degradation risks, thereby improving the long-term security of TLS control channel identity authentication.

[0036] In a typical embodiment of the present invention, taking the server-side perspective as an example, such as... Figure 1 As shown, a post-quantum collaborative authentication method for the server is disclosed, the specific steps of which include: Obtain authentication association factor data that includes post-quantum authentication strategy information; The authentication association factor data is encoded according to a preset encoding rule, and a cryptographic hash operation is performed to generate binding data. The binding data is sent to the signature coordination module, so that the signature coordination module schedules the corresponding collaborative signature node group to perform post-quantum collaborative signature operation on the binding data according to the post-quantum authentication strategy information, and aggregates and generates post-quantum collaborative signature data when the threshold condition is met. The post-quantum collaborative signature data is sent to the client as authentication data bound to the handshake message used for identity authentication, so that the client can regenerate or verify the bound data and perform joint verification with authentication elements. If all verifications pass, the server-side identity authentication is confirmed to be successful.

[0037] The following detailed description is provided in conjunction with specific implementation methods.

[0038] This embodiment details the implementation process of the post-quantum collaborative authentication method based on handshake message binding in a VPN remote access scenario from the perspective of the server.

[0039] This embodiment takes an enterprise VPN remote access scenario as an example: The enterprise intranet has a VPN gateway deployed as a server, and remote employees located throughout the country access the enterprise intranet to access business systems such as OA and finance through VPN client software (such as OpenVPN client).

[0040] Step 1: Obtain authentication-related factor data.

[0041] Remote employees launch a VPN client on their personal laptops, enter the enterprise VPN gateway domain name, and initiate a TLS control channel handshake request. This handshake request includes at least a client-generated random number (ClientRandom), the cipher suites supported by the client, and a policy statement requiring the enabling of post-quantum collaborative authentication. Based on its own configuration and the client's handshake request, the VPN gateway determines that this handshake will employ a dual authentication strategy: SM2 certificate authentication combined with ML-DSA post-quantum collaborative signature.

[0042] Specifically, the authentication association factor data obtained by the VPN gateway includes the following information: (1) Current TLS handshake message digest information. The VPN gateway calculates the TLS handshake message digest value based on the handshake messages that have been sent and received during the current TLS handshake process (including at least the client greeting message and the server greeting message).

[0043] (2) Certificate identity information (CertID) corresponding to the server digital certificate. The VPN gateway obtains the national cryptographic SM2 digital certificate it has deployed, and performs a cryptographic hash operation (such as SM3 or SHA-256) on the DER encoded content of the certificate to generate a certificate fingerprint as the certificate identity information.

[0044] (3) Post-quantum authentication policy information (PQPolicy). The VPN gateway obtains the post-quantum authentication policy used in this handshake from the policy configuration unit. This policy information includes at least: post-quantum signature algorithm identifier, such as Module-Lattice-Based Digital Signature Algorithm (ML-DSA), collaborative signature node group identifier, threshold policy identifier (such as 2-of-3), degradation control policy identifier, and public key binding identifier.

[0045] (4) ClientRandom and ServerRandom. The clientRandom comes from the handshake request initiated by the remote employee VPN client, while the serverRandom is generated by the VPN gateway when sending the server greeting message.

[0046] The CertificateVerify message is a crucial message in the TLS handshake protocol used for server authentication. Its content consists of data generated by the server signing the current handshake message digest using the private key corresponding to its digital certificate. This data is used to prove to the client that the server possesses a private key matching the certificate's public key. This invention sends the post-quantum collaborative signature data to the client as authentication data bound to the CertificateVerify message in the handshake process. This allows the client to verify the post-quantum collaborative signature data alongside the traditional signature. Successful server authentication is confirmed only when both verifications pass, thus achieving dual security protection through traditional certificate authentication and post-quantum enhanced authentication.

[0047] Step 2: Generate binding data.

[0048] The VPN gateway performs normalized encoding on the authentication association factor data obtained in step 1 according to the preset field order and field length encoding rules, and performs a password hash operation on the encoded data to generate binding data (BindData).

[0049] Specifically, the binding data is generated as follows: BindData = Hash(HandshakeDigest||CertID||PQPolicy||ClientRandom||ServerRandom); where "||" represents data concatenation operation and Hash represents password hash operation (such as SM3 or SHA-256).

[0050] The binding data generated in the above manner will simultaneously limit the post-quantum collaborative signature to the following three dimensions: (1) the current VPN remote access session (bound by HandshakeDigest, ClientRandom and ServerRandom); (2) the identity corresponding to the VPN gateway SM2 digital certificate (bound by CertID); and (3) the post-quantum authentication policy adopted in this session (bound by PQPolicy).

[0051] It should be noted that, taking TLS 1.3 as an example, although both traditional authentication signatures and the post-quantum collaborative signature of this invention are related to the same TLS handshake session, their data structures and signing mechanisms differ. Traditional authentication signatures are generated according to the TLS protocol, and their content to be signed includes the context data specified by the protocol and the handshake message digest up to the generation of the CertificateVerify message; the CertificateVerify message carries the signature algorithm identifier and signature value. The client recalculates the handshake message digest based on the sent and received handshake messages and verifies the traditional signature using the public key in the server's digital certificate. The client's random number, server's random number, and server certificate message are included in the corresponding handshake message and are therefore indirectly protected through the handshake message digest, but are not encoded again as independent fields into the traditional signature input.

[0052] This invention, following a preset field order and field length encoding rule, standardizes and encodes the handshake message digest information, the certificate identity information corresponding to the server's digital certificate, the post-quantum authentication strategy information, the client's random number, and the server's random number, and performs a cryptographic hash operation to generate binding data (BindData). Then, the collaborative signature node group generates post-quantum collaborative signature data based on this binding data. Therefore, for the same handshake session, the random numbers and certificate sources referenced by the two signatures can be the same, but their data structures to be signed, signature key systems, and authentication purposes differ. The post-quantum collaborative signature further explicitly binds the post-quantum signature algorithm, the collaborative signature node group, the threshold policy, the degradation control policy, and the public key binding relationship.

[0053] Optionally, the binding data may also include a TLS session identifier, a VPN gateway domain identifier, a control channel instance identifier, a timestamp, or a signature restart count to further enhance the uniqueness and timeliness of the binding relationship.

[0054] Step 3: Call the signature coordination module to generate post-quantum collaborative signature data.

[0055] The VPN gateway sends the binding data generated in step 2 to the signature coordination module deployed in the enterprise cryptographic service cluster. Upon receiving the binding data, the signature coordination module selects the corresponding node group from pre-deployed collaborative signature node groups in multiple security domains (e.g., different data centers, different availability zones) based on the collaborative signature node group identifier in the post-quantum authentication policy information. Each collaborative signature node group includes multiple collaborative signature nodes, each storing a signature authorization credential, a post-quantum signature private key share, or node key material used to generate the post-quantum collaborative signature. The signature coordination module determines the post-quantum signature algorithm to be used based on the post-quantum signature algorithm identifier and determines the threshold condition based on the threshold policy identifier. The threshold condition corresponds to the t-of-n collaborative signature policy, where n is the total number of nodes in the collaborative signature node group, t is the minimum number of valid partial signatures required to aggregate and generate a valid post-quantum collaborative signature, and t is an integer greater than or equal to 2 and less than or equal to n; n is an integer greater than or equal to 2. For example, the threshold condition might be 2-of-3 (i.e., at least 2 out of 3 signature nodes must generate valid partial signatures for aggregation). It's important to note here that in collaborative signatures, no single node holds the complete private key, and no single node can independently generate a complete signature. Each node only knows a portion of the private key (a share of the private key), and therefore can only generate "partial" signature results. Only by aggregating a sufficient number of partial signatures can a complete post-quantum collaborative signature data be generated.

[0056] The signature coordination module distributes the bound data to three selected collaborative signature nodes. Each collaborative signature node is deployed in a different security zone within the enterprise (such as a production data center, disaster recovery data center, and security management zone), and each stores its own share of the post-quantum signature private key. Each node generates partial signature data based on the bound data and its local private key share.

[0057] It should be noted that before generating partial signature data, each collaborative signature node can first generate a commitment value corresponding to a local random number or intermediate calculated value and send it to the signature coordination module. After receiving commitment values ​​that meet the threshold number (at least 2), the signature coordination module will then trigger each node to generate partial signature data to prevent participating nodes from selectively tampering with the intermediate values ​​of other nodes.

[0058] The signature coordination module verifies the validity of the partial signature data returned by each collaborative signature node. When the number of valid partial signature data reaches a threshold (at least two valid partial signatures), the signature coordination module aggregates the valid partial signature data to generate complete post-quantum collaborative signature data.

[0059] Optionally, when the post-quantum signature algorithm involves rejection sampling, norm constraints, or intermediate value validity checks, the signature coordination module can determine whether the signed aggregate data meets the validity constraints through mask values, commitment opening, distributed comparison, multi-party computation, or zero-knowledge proofs. If not, the signature coordination module sends the failure result and signature restart count to each node participating in the signature. Each node re-derives random parameters based on the session identifier, the bound data digest, and the signature restart count and re-executes part of the signature generation process.

[0060] The signature coordination module returns the aggregated post-quantum collaborative signature data to the VPN gateway. This post-quantum collaborative signature data includes at least the ML-DSA signature value, as well as the post-quantum signature algorithm identifier, collaborative signature node group identifier, threshold policy identifier, participating node identifier digest, and binding data digest.

[0061] Step 4: Send the post-quantum collaborative signature data to the VPN client.

[0062] The VPN gateway sends the post-quantum collaborative signature data obtained in step 3 as authentication data that has a handshake message binding relationship with the TLS CertificateVerify authentication message to the VPN client of the remote employee.

[0063] Specifically, post-quantum collaborative signature data can be encapsulated in additional authentication messages that have a handshake message binding relationship with the CertificateVerify message, TLS extended fields, VPN control channel custom authentication payloads, or server authentication additional fields and sent.

[0064] While sending post-quantum collaborative signature data, the VPN gateway also needs to ensure that the VPN client can obtain the associated information required for generating the binding data (including handshake message digest, certificate identity information, and post-quantum authentication policy information) so that the client can regenerate or verify the binding data.

[0065] Optionally, the post-quantum collaborative signature data can also be encapsulated in an additional authentication message that has a handshake message binding relationship with the CertificateVerify message or a custom authentication payload of the VPN control channel.

[0066] Step 5: The VPN client completes authentication.

[0067] After receiving the post-quantum collaborative signature data and related authentication information sent by the VPN gateway, the remote employee's VPN client performs the following verification operations: (1) The VPN client regenerates the binding data according to the same preset encoding rules as the VPN gateway based on the received information, and compares and verifies it with the binding data digest carried in the post-quantum collaborative signature data sent by the VPN gateway.

[0068] (2) The VPN client shall perform joint verification of authentication elements, including at least: verifying the legality of the certificate chain of the VPN gateway's SM2 digital certificate (ensuring that the certificate is issued by the enterprise CA and has not expired); verifying whether the SM2 traditional signature in the CertificateVerify message matches the current TLS handshake message digest; verifying whether the quantum collaborative signature data after verification corresponds to the regenerated binding data; verifying whether the ML-DSA verification public key corresponding to the public key binding identifier is consistent with the VPN gateway certificate identity information; and verifying whether the downgrade control policy identifier in the quantum authentication policy information after verification conforms to the client's local security policy.

[0069] (3) When the binding data verification passes and the joint verification of the above authentication elements passes, the VPN client confirms that the VPN gateway currently connected is the enterprise's legitimate remote access gateway, the identity authentication is successful, and continues to complete the subsequent handshake process of the TLS control channel. Then, the data channel is established, and remote employees can access the enterprise's intranet OA, finance and other business systems normally.

[0070] If any verification fails (such as an attacker impersonating the VPN gateway IP, replaying an old signature, replacing a certificate, or attempting to downgrade to pure SM2 authentication mode), the VPN client immediately terminates the TLS control channel handshake and displays a pop-up message: "Security authentication failed. There is a risk at the current access point. Please check your network environment and try again." At the same time, it generates an authentication failure report containing the failure reason code for the enterprise security operations center to trace and investigate the source.

[0071] At this point, the server-side authentication method for VPN remote access scenarios has been implemented.

[0072] It should be noted that in this embodiment, the VPN gateway digital certificate is a Chinese national cryptographic SM2 digital certificate, and the certificate identity information is the certificate fingerprint obtained by performing an SM3 hash operation on the DER encoded content of the digital certificate. The post-quantum signature verification public key establishes a correspondence with the certificate identity information through the extended field of the server digital certificate. Even if the VPN gateway is deployed in a DMZ area and faces a high risk of attack, an attacker who obtains the gateway's local SM2 private key still cannot pass authentication alone. At least two collaborative signature nodes deployed in different security areas must be compromised simultaneously to forge complete authentication data, thereby significantly improving the post-quantum capability of server identity authentication and the ability to resist private key leakage (unauthorized disclosure or leakage of information) in remote access scenarios.

[0073] As one implementation method, such as Figure 2As shown, during collaborative signature and consistency processing, each collaborative signature node first generates a commitment value corresponding to a local random number or intermediate calculated value before generating partial signature data. The signature coordination module 300 then triggers the generation of partial signature data after receiving commitment values ​​that meet the threshold number. This method reduces the risk of participating nodes selectively engaging in malicious behavior based on intermediate values ​​from other nodes.

[0074] In another implementation, when the post-quantum signature algorithm involves rejection sampling, norm constraints, or intermediate value validity checks, the signature coordination module 300 determines whether the aggregated signature data meets the validity constraints through mask values, commitment opening, distributed comparison, multi-party computation, or zero-knowledge proofs. Each collaborative signature node does not directly disclose its local private key share or complete random share.

[0075] When the aggregated signature data does not meet the validity constraints, the signature coordination module 300 sends a failure result and a signature restart count to the participating collaborative signature nodes. Each collaborative signature node re-derives random parameters based on the session identifier, the bound data digest, and the signature restart count, and re-executes part of the signature generation process. This ensures that each node has a consistent state regarding the rejection sampling failure result, avoiding the leakage of private key share information due to unilateral termination or inconsistent restart.

[0076] Post-quantum collaborative signature data may include at least one of the following: post-quantum signature value, post-quantum signature algorithm identifier, collaborative signature node group identifier, threshold policy identifier, participating node identifier digest, and binding data digest; it may also include commitment verification data, partial signature validity proof, timestamp, degradation control policy identifier, or signature restart count.

[0077] As one implementation, during public key binding and policy configuration, the post-quantum signature verification public key or its digest can establish a correspondence with the certificate identity information through the server-side digital certificate extension field, client-side trusted configuration file, server-side authentication policy statement, or pre-configured public key binding table. When performing joint verification, client 100 can query the corresponding post-quantum signature verification public key or its digest based on the certificate identity information of the server-side digital certificate and check whether it matches the post-quantum authentication policy information. Server 200 can determine whether to enable post-quantum collaborative authentication, the post-quantum signature algorithm used, the post-quantum key exchange algorithm, the TLS key exchange group, the collaborative signature node group identifier, and threshold parameters based on configuration items, and pass the configuration items to the underlying cryptographic library 600 or the signature coordination module 300. Post-quantum signature algorithms may include ML-DSA, Falcon, SLH-DSA, or combinations thereof. In scenarios with normal security levels, a combination of server-side digital certificate authentication and single post-quantum signature verification can be used; in scenarios with high security levels, a combination of server-side digital certificate authentication and t-of-n post-quantum collaborative signature authentication can be used; in transitional deployment scenarios, whether to allow a fallback to the traditional authentication mode can be controlled by the downgrade control policy identifier and the client-side local policy.

[0078] As one implementation method, the binding data can be encoded in the order of field identifier, field length, and field value to avoid parsing ambiguity caused by concatenating different fields. The field identifier indicates whether the field is TLS handshake message digest information, certificate identity information, post-quantum authentication policy information, client random number, server random number, session identifier, or signature restart count; the field length indicates the byte length of the field value; and the field value carries the corresponding binary data or normalized text data. Server 200 and client 100 regenerate the binding data using the same field order and encoding rules, thereby ensuring that both parties obtain a consistent binding data digest for the same TLS control channel session.

[0079] Post-quantum authentication policy information can take the form of a combination of policy version number, algorithm suite identifier, collaborative signature node group identifier, threshold parameter, degradation control policy identifier, and public key binding identifier. Specifically, the policy version number distinguishes policy configurations at different stages; the algorithm suite identifier indicates ML-DSA, Falcon, SLH-DSA, or a combination thereof; the collaborative signature node group identifier indicates the set of nodes participating in this authentication; the threshold parameter indicates the t-of-n policy; the degradation control policy identifier indicates whether the client allows a fallback to a non-post-quantum collaborative authentication mode; and the public key binding identifier associates certificate identity information with the post-quantum signature verification public key or its digest.

[0080] Post-quantum collaborative signature data can be encapsulated in the following order: signature data version, post-quantum signature algorithm identifier, collaborative signature node group identifier, threshold policy identifier, participating node identifier digest, binding data digest, post-quantum signature value, and optional proof data. The signature data version supports subsequent protocol extensions; the participating node identifier digest allows the client or auditing system to confirm the actual set of nodes participating in the signature; the binding data digest is used for comparison with the binding data digest recalculated by the client; and the optional proof data may include commitment verification data, partial signature validity proof, timestamps, and signature restart counts.

[0081] The above field organization method is not limited to a specific encoding format. TLV encoding, ASN.1 structure, CBOR structure, JSON normalized encoding, TLS extended field encoding, or VPN control channel custom payload encoding can be used. Regardless of the encoding method used, the server 200, the signature coordination module 300, and the client 100 should all adopt consistent normalization rules for the fields involved in signing and verification to avoid inconsistent verification results due to differences in field order, character encoding, handling of empty fields, or length interpretation.

[0082] As one embodiment, during client-side joint verification and failure handling, after receiving the server's digital certificate and post-quantum collaborative signature data, client 100 can perform joint verification according to a preset order. First, client 100 verifies whether the server's digital certificate's certificate chain, validity period, purpose, revocation status, and certificate subject information conform to the local trust policy. Second, client 100 verifies whether the traditional signature in the TLS control channel authentication message corresponds to the current TLS handshake message digest information. Third, client 100 regenerates the binding data according to the same normalization rules as server 200 and calculates the binding data digest.

[0083] Client 100 then queries the corresponding post-quantum signature verification public key or its digest based on the certificate identity information of the server's digital certificate, and checks whether the verification public key or its digest matches the public key binding identifier in the post-quantum authentication policy information. If they match, client 100 continues to verify whether the post-quantum signature algorithm identifier, collaborative signature node group identifier, threshold policy identifier, and degradation control policy identifier in the post-quantum collaborative signature data conform to the client's local security policy. Only when the certificate identity, binding data digest, public key binding relationship, threshold policy, and degradation control policy are all consistent can client 100 use the corresponding post-quantum signature verification public key to verify the post-quantum collaborative signature data.

[0084] If any verification step fails, client 100 terminates the TLS control channel handshake and can generate an authentication failure reason code. The authentication failure reason code can include certificate chain verification failure, traditional signature verification failure, inconsistent binding data digest, post-quantum signature verification failure, mismatch of cooperating signature node groups, threshold policy mismatch, failure to meet degradation control policies, or inconsistent public key binding relationships. Server 200 and signature coordination module 300 can record the failure reason code, session identifier, participating node identifier digest, and timestamp for subsequent auditing and fault location.

[0085] In scenarios where transitional deployment is permitted, client 100 can determine whether to allow a fallback to traditional certificate authentication mode based on its local security policy. If the downgrade control policy indicates that post-quantum collaborative authentication must be enabled for this connection, then even if traditional certificate authentication passes, client 100 must not continue to establish a TLS control channel. If the local security policy allows a fallback in a specific gray-scale environment, client 100 can record the fallback event and report it according to a preset alarm policy, thereby preventing attackers from forcing a silent system downgrade by deleting the post-quantum capability declaration.

[0086] As one implementation method, during collaborative signature node deployment and security auditing, each collaborative signature node in the collaborative signature node group 400 can be deployed in different physical hosts, different security domains, or different management boundaries to reduce the risk that the post-quantum collaborative signature capability will be completely controlled due to the compromise of a single device. The signature coordination module 300 can select participating nodes according to the node group identifier and threshold parameters provided by the policy configuration unit 500, and check the node online status, node certificate, node authorization credentials, and node health status before generating post-quantum collaborative signature data.

[0087] When generating partial signature data, each collaborative signing node can first verify the bound data digest, session identifier, and local node identifier. Only after successful verification can the local node key material be used to generate the partial signature data. The signature coordination module 300 verifies the validity of each partial signature data before aggregation; for partially signature data that fails verification, the corresponding node identifier can be recorded and the data rejected from being included in the aggregation process. This method reduces the risk of malicious nodes submitting invalid partial signature data, leading to server-side authentication failures or unclear audit results.

[0088] The system can also generate audit logs for the post-quantum collaborative authentication process. Audit logs may include TLS session identifiers, server-side digital certificate fingerprints, binding data digests, post-quantum signature algorithm identifiers, collaborative signature node group identifiers, threshold policy identifiers, actual participating node identifier digests, signature restart counts, authentication results, and failure reason codes. Audit logs can be stored by the server (200), the signature coordination module (300), or a separate audit system to meet the traceability and accountability requirements in high-security access scenarios.

[0089] The aforementioned deployment and auditing methods enable this invention not only to achieve post-quantum authentication enhancement on a single server, but also to be applicable to multi-node scenarios such as VPN gateway clusters, zero-trust access gateway clusters, and government / enterprise private network entry points. In these scenarios, even if server 200 is compromised at a single point, the attacker still needs to simultaneously satisfy the threshold policy of the collaborative signature node group 400 and generate signature data consistent with the current TLS handshake, certificate identity, and post-quantum authentication policy in order to pass the joint verification of client 100.

[0090] As one implementation method, such as Figure 3 As shown, the method of this invention can be applied to the OpenVPN control channel. The OpenVPN client is client 100, and the OpenVPN server is server 200. OpenVPN server 200 continues to use the server digital certificate to complete basic identity authentication, while introducing post-quantum collaborative signature data during the TLS control channel identity authentication phase. The specific process is as follows: 1) OpenVPN client 100 initiates a control channel handshake request to OpenVPN server 200.

[0091] 2) OpenVPN server 200 sends the server digital certificate to OpenVPN client 100.

[0092] 3) The OpenVPN server generates binding data based on the TLS handshake message digest, the certificate identity information corresponding to the server's digital certificate, and the post-quantum authentication policy information.

[0093] 4) OpenVPN server 200 calls signature coordination module 300, and the collaborative signature node group 400 generates quantum collaborative signature data for the bound data.

[0094] 5) The OpenVPN server 200 sends the post-quantum collaborative signature data as control channel authentication data to the OpenVPN client 100. This post-quantum collaborative signature data can be encapsulated in the OpenVPN control channel's custom authentication payload, or it can be sent as additional authentication data bound to a TLS CertificateVerify message.

[0095] 6) OpenVPN client 100 verifies the server's digital certificate, regenerates the binding data based on the local control channel security policy, and verifies the post-quantum collaborative signature data. When both the server's digital certificate and the post-quantum collaborative signature data are verified successfully, OpenVPN client 100 confirms successful authentication of the control channel server's identity.

[0096] 7) After successful control channel authentication, OpenVPN client 100 and OpenVPN server 200 continue to complete the subsequent handshake process of the control channel and establish a data channel according to the original data channel parameters.

[0097] In the above implementation, post-quantum collaborative authentication only applies to the TLS authentication phase of the OpenVPN control channel, without changing the symmetric encryption algorithm, data encapsulation format, or data channel key usage of the OpenVPN data channel. This approach improves the post-quantum capability of the control channel server's authentication and its resistance to private key leakage (unauthorized disclosure or outflow of information) without altering the data channel encryption algorithm configuration, thereby reducing system modification costs and improving deployment compatibility.

[0098] Example 2 In a typical embodiment of the present invention, a post-quantum collaborative authentication method for a client is provided, comprising: Receive authentication association factor data and post-quantum collaborative signature data sent by the server; Regenerate binding data based on the authentication association factor data, and verify it with the binding data associated with the received post-quantum collaborative signature data; After the binding data verification is passed, the authentication elements in the authentication association factor data and the post-quantum collaborative signature data are verified by combining the authentication element joint verification. Once all verifications pass, the server-side identity authentication is confirmed to be successful. The authentication association factor data includes at least post-quantum authentication strategy information. The post-quantum collaborative signature data is generated by the signature coordination module scheduling the corresponding collaborative signature node group to perform post-quantum collaborative signature operations on the bound data according to the post-quantum authentication strategy information and aggregating it when the threshold condition is met. The bound data is generated by the server encoding the authentication association factor data according to the preset encoding rules and performing cryptographic hash operations. The post-quantum collaborative signature data is bound to the handshake message used for identity authentication.

[0099] Example 3 In a typical embodiment of the present invention, a post-quantum collaborative authentication method based on handshake message binding is provided, applied to server-client interaction, including: The server obtains authentication association factor data, which includes at least post-quantum authentication strategy information. The server encodes the authentication association factor data according to a preset encoding rule and performs a password hash operation to generate binding data; The server sends the binding data to the signature coordination module; the signature coordination module, based on the post-quantum authentication strategy information, schedules the corresponding collaborative signature node group to perform post-quantum collaborative signature operations on the binding data, and aggregates and generates post-quantum collaborative signature data when the threshold condition is met, and returns the post-quantum collaborative signature data to the server; the server sends the post-quantum collaborative signature data to the client as authentication data that is bound to the handshake message used for identity authentication; The client receives the authentication data, regenerates or verifies the binding data, and performs joint verification with the authentication elements. If all verifications pass, the client confirms that the server-side identity authentication is successful.

[0100] like Figure 4 As shown, the TLS control channel authentication method has the following specific process: S101, client 100 initiates a TLS control channel handshake request to server 200. The handshake request includes at least one of the following: client random number, supported cipher suites, supported signature algorithms, supported key exchange groups, and a policy statement on whether post-quantum collaborative authentication is required.

[0101] S102, Server 200 determines the authentication strategy to be used in this TLS control channel handshake based on its own configuration and the handshake request from Client 100, and sends its server digital certificate to Client 100. The server digital certificate can be a Chinese national cryptographic digital certificate, specifically an SM2 digital certificate.

[0102] S103, Server 200 calculates TLS handshake message digest information based on the handshake messages sent and received during the current TLS handshake process. The TLS handshake message digest information can be a TLS handshake message digest value, or data further derived from the TLS handshake message digest value.

[0103] S104, Server 200 obtains the certificate identity information corresponding to the server's digital certificate. The certificate identity information may include the certificate fingerprint, certificate serial number, certificate subject identifier, public key digest, or a combination of the above. Specifically, the certificate identity information is the certificate fingerprint obtained by performing a cryptographic hash operation on the DER-encoded content of the server's digital certificate or the certificate subject data after PEM decoding.

[0104] S105, Server 200 obtains post-quantum authentication policy information provided by Policy Configuration Unit 500. The post-quantum authentication policy information includes at least the post-quantum signature algorithm identifier, the collaborative signature node group identifier, the threshold policy identifier, and the degradation control policy identifier, and may also include the post-quantum signature verification public key or its digest.

[0105] S106, Server 200 generates binding data based on TLS handshake message digest information, certificate identity information, and post-quantum authentication policy information. Specifically, the binding data is generated as follows: BindData = H(HandshakeDigest||CertID||PQPolicy||ClientRandom||ServerRandom). Where H represents a cryptographic hash operation, HandshakeDigest represents the TLS handshake message digest information, CertID represents the certificate identity information, PQPolicy represents the post-quantum authentication policy information, ClientRandom represents a client-side random number, and ServerRandom represents a server-side random number.

[0106] In other implementations, the binding data may also include a TLS session identifier, a server name identifier, a control channel instance identifier, a timestamp, or a signature restart count. By incorporating this information into the binding data, the post-quantum collaborative signature data can be limited to the current TLS control channel session, reducing the risk of signature replay and policy replacement.

[0107] S107, the server 200 sends the binding data to the signature coordination module 300. The signature coordination module 300 selects the corresponding collaborative signature node group 400 based on the post-quantum authentication strategy information.

[0108] S108, multiple collaborative signature nodes in the collaborative signature node group 400 generate partial signature data based on the binding data and local node key material. The collaborative signature node group 400 can adopt a t-of-n collaborative signature strategy, where n is an integer greater than or equal to 2, and t is an integer greater than or equal to 2 and less than or equal to n; when at least t collaborative signature nodes generate valid partial signature data, the signature coordination module 300 generates post-quantum collaborative signature data.

[0109] S109, Server 200 sends post-quantum collaborative signature data to Client 100 in a manner that binds the post-quantum collaborative signature data to the authentication message in the TLS control channel via a handshake message. The post-quantum collaborative signature data can be encapsulated in an additional authentication message that is bound to the CertificateVerify message via a handshake message, a TLS extended field, a VPN control channel custom authentication payload, or a server-side authentication additional field.

[0110] S110, Client 100 verifies the validity of the certificate chain of the server's digital certificate, verifies whether the traditional signature corresponding to the authentication message matches the current TLS handshake message digest information, regenerates or verifies the binding data, and verifies whether the post-quantum collaborative signature data corresponds to the binding data. Client 100 also verifies whether the post-quantum signature algorithm identifier, collaborative signature node group identifier, threshold policy identifier, and degradation control policy identifier conform to the local security policy. If all verifications pass, Client 100 determines that the server's authentication is successful; if any verification fails, Client 100 terminates the TLS control channel handshake.

[0111] Example 4 In a typical embodiment of the present invention, a post-quantum collaborative authentication system based on handshake message binding is provided, comprising: a server and a client; the server is configured to acquire authentication association factor data, the authentication association factor data including at least post-quantum authentication strategy information; encode the authentication association factor data according to a preset encoding rule and perform a cryptographic hash operation to generate binding data; send the binding data to a signature coordination module and receive post-quantum collaborative signature data returned by the signature coordination module; and send the post-quantum collaborative signature data as authentication data bound to a handshake message used for identity authentication to the client; the client is configured to receive the authentication data, regenerate or verify the binding data, and perform joint verification with authentication elements, confirming successful server-side identity authentication when all verifications pass.

[0112] Specifically, such as Figure 5 As shown, the TLS-based quantum collaborative authentication system includes a client 100, a server 200, a signature coordination module 300, a collaborative signature node group 400, a policy configuration unit 500, and an underlying cryptographic library 600. The collaborative signature node group 400 includes multiple collaborative signature nodes 401, 402 to 40n.

[0113] Client 100 initiates the TLS control channel handshake, receives the server's digital certificate and post-quantum collaborative signature data, and performs joint verification. Server 200 performs the TLS control channel handshake, sends the server's digital certificate, generates binding data, and sends the post-quantum collaborative signature data. Signature coordination module 300 receives the binding data, schedules the collaborative signature node group 400 to generate the post-quantum collaborative signature data, and verifies and aggregates partial signature data.

[0114] The collaborative signature node group 400 is used to generate partial signature data based on the binding data. Each collaborative signature node can separately store signature authorization credentials, a share of the post-quantum signature private key, or node key material used to generate the post-quantum collaborative signature. The policy configuration unit 500 is used to store or provide post-quantum authentication policy information, including whether post-quantum collaborative authentication is enabled, the post-quantum signature algorithm identifier, the collaborative signature node group identifier, the threshold policy identifier, the degradation control policy identifier, the post-quantum signature verification public key or its digest, and the binding relationship between certificate identity information and the post-quantum signature verification public key. The policy configuration unit 500 can be configured in the server 200, the signature coordination module 300, the underlying cryptographic library 600, or a standalone policy device.

[0115] The underlying cryptographic library 600 is used to perform traditional certificate chain verification, traditional signature verification, cryptographic hash operations, post-quantum signature verification, and cryptographic operations related to the TLS control channel. The underlying cryptographic library 600 can be called by the server 200 and the client 100, and can also cooperate with the signature coordination module 300 to complete part of the signature verification.

[0116] The steps and methods involved in Examples 2 to 4 above correspond to those in Example 1. For specific implementation details, please refer to the relevant description section of Example 1.

[0117] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.

[0118] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0119] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A post-quantum collaborative authentication method for the server side, characterized in that, include: Obtain authentication association factor data that includes post-quantum authentication strategy information; The authentication association factor data is encoded according to a preset encoding rule, and a cryptographic hash operation is performed to generate binding data. The binding data is sent to the signature coordination module, so that the signature coordination module schedules the corresponding collaborative signature node group to perform post-quantum collaborative signature operation on the binding data according to the post-quantum authentication strategy information, and aggregates and generates post-quantum collaborative signature data when the threshold condition is met. The post-quantum collaborative signature data is sent to the client as authentication data bound to the handshake message used for identity authentication, so that the client can regenerate or verify the bound data and perform joint verification with authentication elements. If all verifications pass, the server-side identity authentication is confirmed to be successful.

2. The post-quantum collaborative authentication method for the server as described in claim 1, characterized in that, The authentication association factor data also includes at least: The current TLS handshake message digest information, the certificate identity information corresponding to the server's digital certificate, the client's random number, and the server's random number.

3. The post-quantum collaborative authentication method for the server as described in claim 1, characterized in that, The post-quantum authentication strategy information includes at least: post-quantum signature algorithm identifier, collaborative signature node group identifier, threshold strategy identifier, degradation control strategy identifier, and public key binding identifier.

4. The post-quantum collaborative authentication method for the server as described in claim 1, characterized in that, The binding data is also used to ensure that the post-quantum collaborative signature data is simultaneously limited to this TLS handshake session, the identity corresponding to the server digital certificate, and the post-quantum authentication strategy adopted this time.

5. The post-quantum collaborative authentication method for the server as described in claim 1, characterized in that, The collaborative signature node group includes multiple collaborative signature nodes, each of which stores a signature authorization certificate, a share of the post-quantum signature private key, or node key material used to generate the post-quantum collaborative signature. The threshold condition corresponds to the t-of-n collaborative signature strategy, where n is the total number of collaborative signature nodes and t is the minimum number of valid partial signatures that meet the aggregation requirements.

6. The post-quantum collaborative authentication method for the server as described in claim 1, characterized in that, The post-quantum collaborative signature data is encapsulated in an additional authentication message that has a handshake message binding relationship with the CertificateVerify message, a TLS extended field, a VPN control channel custom authentication payload, or a server authentication additional field and sent.

7. The post-quantum collaborative authentication method for the server as described in claim 1, characterized in that, The joint verification of authentication elements includes at least: Verify the certificate chain of the server-side digital certificate, verify whether the traditional signature matches the current TLS handshake message digest, verify whether the quantum collaborative signature data corresponds to the bound data, verify the public key binding relationship corresponding to the public key binding identifier, and verify whether the downgrade control policy identifier conforms to the client's local security policy.

8. A post-quantum collaborative authentication method for client applications, characterized in that, include: Receive authentication association factor data and post-quantum collaborative signature data sent by the server; Regenerate binding data based on the authentication association factor data, and verify it with the binding data associated with the received post-quantum collaborative signature data; After the binding data verification is passed, the authentication elements in the authentication association factor data and the post-quantum collaborative signature data are verified by combining the authentication element joint verification. Once all verifications pass, the server-side identity authentication is confirmed to be successful. The authentication association factor data includes at least post-quantum authentication strategy information. The post-quantum collaborative signature data is generated by the signature coordination module scheduling the corresponding collaborative signature node group to perform post-quantum collaborative signature operations on the bound data according to the post-quantum authentication strategy information and aggregating it when the threshold condition is met. The bound data is generated by the server encoding the authentication association factor data according to the preset encoding rules and performing cryptographic hash operations. The post-quantum collaborative signature data is bound to the handshake message used for identity authentication.

9. A post-quantum collaborative authentication method based on handshake message binding, characterized in that, include: The server obtains authentication association factor data, which includes at least post-quantum authentication strategy information. The server encodes the authentication association factor data according to a preset encoding rule and performs a password hash operation to generate binding data; The server sends the binding data to the signature coordination module; the signature coordination module, based on the post-quantum authentication strategy information, schedules the corresponding collaborative signature node group to perform post-quantum collaborative signature operations on the binding data, and aggregates and generates post-quantum collaborative signature data when the threshold condition is met, and returns the post-quantum collaborative signature data to the server; the server sends the post-quantum collaborative signature data to the client as authentication data that is bound to the handshake message used for identity authentication; The client receives the authentication data, regenerates or verifies the binding data, and performs joint verification with the authentication elements. If all verifications pass, the client confirms that the server-side identity authentication is successful.

10. A post-quantum collaborative authentication system based on handshake message binding, characterized in that, include: Server and client; The server is used to obtain authentication association factor data, which includes at least post-quantum authentication strategy information. The authentication association factor data is encoded according to a preset encoding rule and a cryptographic hash operation is performed to generate binding data; the binding data is sent to the signature coordination module, and the post-quantum collaborative signature data returned by the signature coordination module is received; And send the post-quantum collaborative signature data to the client as authentication data that is bound to the handshake message used for identity authentication; The client is used to receive the authentication data, regenerate or verify the binding data, and perform joint verification with authentication elements. If all verifications pass, the client confirms that the server-side identity authentication is successful.

Images