Distributed node unified identity authentication method and system based on QUIC protocol

Abstract

The invention relates to a QUIC protocol-based distributed node unified identity authentication method and system, belongs to the technical field of network security, is applied to a client, and comprises the following steps: registering a client domain name identity through a certificate authority, obtaining a client certificate, and pre-storing a server certificate chain; generating a QUIC initial data packet according to the target server domain name identifier and the client certificate, and sending the QUIC initial data packet to the server; receiving a QUIC handshake data packet returned by the server; verifying the legality of the server certificate based on the server certificate chain, and if the server certificate is legal, calculating a pre-master key according to the client DH private key and the server DH public key; deriving a 1-RTT session key based on the pre-master key; generating a signature verification message, and sending the client certificate and the signature verification message to a server; and synchronously using the 1-RTT session key to encrypt the application layer data with the server, and transmitting the data to the server in the 1-RTT encryption space of the QUIC protocol. According to the invention, the reliability of node identities and the confidentiality of data are ensured.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a distributed node unified identity authentication method and system based on the QUIC protocol. Background Art

[0002] As the core carrier of global information infrastructure, the internet's infrastructure was initially designed based on the premise of mutual trust among network nodes. However, with the exponential expansion of network scale and the massive influx of heterogeneous devices, this design, lacking a native authentication mechanism, has gradually exposed serious security flaws. Because the network transport layer fails to effectively verify the true identity of communicating nodes, malicious nodes can easily forge identities to launch man-in-the-middle attacks, data theft, or denial of service. This has led to identity impersonation becoming a systemic risk that hinders the development of internet security.

[0003] The current Internet Protocol (IP) address, the core identifier for nodes, is essentially a hybrid of identity and network location. Despite years of industry effort to decouple these two attributes and build independent identity systems, progress has been limited. This tight coupling of dual attributes prevents node identity from existing independently of network topology. Once a node's location changes due to cross-network migration, dynamic address allocation (such as DHCP), or Network Address Translation (NAT), its identity becomes invalid. To address this fundamental flaw, application service providers are forced to implement their own authentication mechanisms within upper-layer protocols like HTTP, using username / password-based account systems and third-party social logins. This decentralized solution creates a new structural contradiction: various applications form closed identity silos, forcing users to maintain multiple independent authentication credentials. This not only significantly increases operational burdens but also amplifies security risks due to inconsistent authentication strength (e.g., weak password policies).

[0004] In exploring the technical path to unified identity, the industry has tried various solutions, but all have significant limitations. For example, directly using IP addresses as identifiers cannot achieve persistent identity binding due to the dynamic nature of address allocation and is vulnerable to IP spoofing attacks. Embedding user identifiers at the data link layer (such as inserting broadband accounts into Ethernet frames) requires modifying the underlying frame structure, resulting in bandwidth waste and inability to adapt to mobile internet scenarios. The IP authentication header (AH) at the network layer can verify packet integrity, but it cannot resolve identity trust issues and is incompatible with widely deployed NAT devices. More complex solutions, such as Resource Public Key Infrastructure (RPKI), attempt to bind IP addresses through certificates, but they are difficult to implement due to their inability to overcome the dynamic nature of addresses. Transport layer security protocols (such as ESP) provide encryption capabilities, but the processing overhead of their multi-layer protocol stack makes it difficult to meet the requirements of high-concurrency, low-latency scenarios.

[0005] Currently, existing solutions are limited by rigid protocol layer constraints (e.g., TCP cannot carry client identity during the handshake phase) or implementation complexity (e.g., RPKI requires restructuring the global routing system), and have yet to fully decouple identity from location. Therefore, establishing a decentralized, persistent, and verifiable global node identity system while ensuring efficient communication remains a pressing technical challenge. Summary of the Invention

[0006] Based on this, the present application provides a distributed node unified identity authentication method and system based on the QUIC protocol.

[0007] In the first aspect, this application provides a distributed node unified identity authentication method based on the QUIC protocol, which adopts the following technical solutions: A distributed node unified identity authentication method based on the QUIC protocol, applied to a client, the identity authentication method comprising: Register the client domain name identity through a certificate authority, obtain a client certificate, and pre-store the service client certificate chain; wherein the client certificate includes the client domain name identifier and the client DH public key; Generate a QUIC initial data packet based on the target server domain name identifier and the client certificate and send it to the server; wherein the QUIC initial data packet includes the target server domain name identifier, the client domain name identifier and the client DH public key; Receive a QUIC handshake packet returned by the server; the QUIC handshake packet includes the server certificate and the server DH public key; Verify the legitimacy of the server certificate based on the server certificate chain. If it is valid, calculate the pre-master key based on the client DH private key and the server DH public key; Deriving a 1-RTT session key based on the pre-master key; wherein the 1-RTT session key is derived from the pre-master key, the client random number and the server random number using the HKDF algorithm; Generate a signature verification message and send the client certificate and signature verification message to the server; the signature verification message includes a digital signature of the handshake data hash value; Synchronously encrypt application layer data using the 1-RTT session key with the server, and transmit the data to the server within the 1-RTT encryption space of the QUIC protocol.

[0008] By adopting the above technical solution, during the connection establishment process of the QUIC protocol, the client and server strictly verify their identities through certificate and key exchange to ensure the security of subsequent communications. Compared with traditional identity authentication methods, this application provides higher security and lower communication latency by introducing digital certificates and key exchange mechanisms, ensuring the reliability of node identities and the confidentiality of data, and solving security issues such as identity impersonation and data tampering in traditional authentication methods. At the same time, because the QUIC protocol is implemented in user mode, it has higher scalability and can effectively promote the popularization and application of secure Internet communications.

[0009] Optionally, the step of verifying the legitimacy of the server certificate based on the server certificate chain includes: Parse the QUIC handshake packet and extract the server certificate and server DH public key; Verify whether the CA signature chain of the server certificate is complete based on the pre-stored server certificate chain, and check whether the domain name identifier of the server certificate is consistent with the target server domain name identifier; if so, determine that the server certificate is legal; if not, determine that the server certificate is illegal.

[0010] By adopting the above technical solutions and deeply integrating the PKI system with the QUIC protocol stack, a strong authentication mechanism for client-server identity is implemented at the transport layer for the first time. The client parses the cryptographic parameters in the QUIC handshake packet and dynamically builds a trust path based on a pre-configured certificate chain. This triple mechanism, combined with CA signature chain verification, revocation status checking, and domain name consistency matching, ensures the non-repudiation and authenticity of the server's identity.

[0011] Optionally, after determining that the server certificate is illegal, the method further includes: Terminate the QUIC connection establishment process; Returns an authentication failure error code to the client application layer and records the server certificate fingerprint to the local blacklist.

[0012] By adopting the above technical solutions, illegal certificates are immediately blocked and fingerprint blacklist strategies are implemented, thus building an active defense barrier and effectively curbing phishing attacks and man-in-the-middle threats.

[0013] Optionally, the steps of calculating the pre-master secret key based on the client DH private key and the server DH public key include: The pre-master key is calculated based on the Diffie-Hellman key exchange algorithm. The calculation formula is: Pre-master secret key = DH_compute_key(K_ client_priv ,K_ server_pub ); Among them, K_ client_privis the client DH private key, K_ server_pub The server DH public key.

[0014] Optionally, the identity authentication method further includes: When transmitting data within the 1-RTT encryption space of the QUIC protocol, if a change in the client IP address is detected, the QUIC connection identifier remains unchanged; Reusing the 1-RTT session key to encrypt data on the new IP path; Send a connection migration notification frame to the server.

[0015] By adopting the above technical solutions, we achieve the unification of network-layer transparent migration and transport-layer session persistence. In scenarios where the client IP address changes, the persistence of the QUIC connection identifier (CID) maintains the continuity of the logical session. Reusing 1-RTT session keys avoids the overhead of key renegotiation, and the address verification token mechanism ensures the legitimacy and attack resistance of the new path through a cryptographic challenge-response model.

[0016] In the second aspect, this application provides a distributed node unified identity authentication method based on the QUIC protocol, which adopts the following technical solutions: A distributed node unified identity authentication method based on the QUIC protocol, applied to a server, the identity authentication method comprising: Register the server domain name identity through a certificate authority, obtain a server certificate, and pre-store a list of authorized client domain names; wherein the server certificate includes the server domain name identifier and the server public key; Receive the QUIC initial data packet sent by the client, and parse it to obtain the target server domain name identifier and the client domain name identifier; Verify the QUIC initial data packet based on the authorized client domain name list. If the verification passes, generate a server DH public key and construct a QUIC handshake data packet to send to the client; the QUIC handshake data packet includes the server certificate and the server DH public key; Receive a client certificate and a signature verification message sent by the client; the signature verification message includes a digital signature of a hash value of the handshake data; Extract the public key from the client certificate and verify whether the digital signature is consistent with the handshake data hash value. If the signature verification is successful, calculate the pre-master key based on the server DH private key and the client DH public key, and derive the 1-RTT session key synchronized with the client; Synchronously encrypt application layer data using the 1-RTT session key with the client, and transmit the data to the client within the 1-RTT encryption space of the QUIC protocol.

[0017] By adopting the above technical solution, combined with server certificates, client certificates, digital signatures and the Diffie-Hellman key exchange protocol, strong identity authentication and key negotiation are achieved during the connection establishment phase of the QUIC protocol. Through this identity authentication process, the server can accurately identify and verify the identity of the client, ensuring that the data transmission of subsequent communications is carried out under encryption protection, and effectively preventing security issues such as identity impersonation and data theft. Compared with traditional identity authentication mechanisms, this application provides a more secure, flexible and low-latency identity authentication solution, which is particularly suitable for unified identity authentication of large-scale Internet nodes.

[0018] Optionally, the steps of extracting a public key from the client certificate and verifying whether the digital signature is consistent with the handshake data hash value include: Parsing a public key from the client certificate; Decrypt the digital signature using the client certificate public key to obtain a signature hash value; Recalculate the handshake data hash value. If the signature hash value is equal to the handshake data hash value, the signature verification is successful. If the signature hash value is not equal to the handshake data hash value, it means that the signature verification has failed.

[0019] By adopting the above technical solutions and deeply integrating the digital signature verification mechanism with the QUIC / TLS protocol stack, we have established an end-to-end strong authentication system for client identities. The server parses the X.509 certificate to obtain the public key, verifies the authenticity of the handshake data signature based on the mathematical principles of asymmetric encryption, and combines it with a collision-resistant hash algorithm to ensure data integrity.

[0020] Optionally, after the signature verification fails, the following steps may also be performed: Send a TLS Alert message containing the error type; Terminates the QUIC connection and records the client certificate fingerprint to the audit log.

[0021] By implementing this technical solution, when signature verification fails, a three-tiered response strategy is implemented: encrypted alert messages notifying the error type, forced connection termination, and fingerprint auditing. This enables proactive security defense and post-event tracing capabilities. Furthermore, the integration of audit logs and blacklist mechanisms provides infrastructure support for analyzing abnormal behavior in distributed nodes, significantly improving the reliability and anti-APT attack capabilities of the Internet's unified identity authentication system.

[0022] In a third aspect, this application provides a distributed node unified identity authentication system based on the QUIC protocol, which adopts the following technical solutions: A distributed node unified identity authentication system based on the QUIC protocol, applied to a client, the identity authentication system comprising: The client identity registration module is used to register the client domain name identity through the certificate authority, obtain the client certificate, and pre-store the service client certificate chain; wherein the client certificate includes the client domain name identifier and the client DH public key; A data packet transmission module, configured to generate a QUIC initial data packet based on the target server domain name identifier and the client certificate and send the QUIC initial data packet to the server; wherein the QUIC initial data packet includes the target server domain name identifier, the client domain name identifier, and the client DH public key; A handshake packet receiving module is used to receive a QUIC handshake packet returned by the server; the QUIC handshake packet includes a server certificate and a server DH public key; The server certificate verification module is used to verify the legitimacy of the server certificate based on the server certificate chain. If it is legitimate, it calculates the pre-master key based on the client DH private key and the server DH public key; A session key generation module, configured to derive a 1-RTT session key based on the pre-master key; wherein the 1-RTT session key is derived from the pre-master key, a client random number, and a server random number using the HKDF algorithm; A signature verification message generation module is used to generate a signature verification message; the signature verification message includes a digital signature of the handshake data hash value; The sending module is used to send the client certificate and signature verification message to the server; The client data encryption transmission module is used to synchronize with the server using the 1-RTT session key to encrypt application layer data and transmit data to the server within the 1-RTT encryption space of the QUIC protocol.

[0023] Fourthly, this application provides a distributed node unified identity authentication system based on the QUIC protocol, which adopts the following technical solutions: A distributed node unified identity authentication system based on the QUIC protocol, applied to a server, the identity authentication system comprising: A server identity registration module is used to register the server domain name identity through a certificate authority, obtain a server certificate, and pre-store a list of authorized client domain names; wherein the server certificate includes the server domain name identifier and the server public key; The data packet parsing module is used to receive the QUIC initial data packet sent by the client and parse it to obtain the target server domain name identifier and the client domain name identifier; A data packet verification module is configured to verify the QUIC initial data packet based on the authorized client domain name list. If the verification succeeds, the module generates a server DH public key and constructs a QUIC handshake data packet to send to the client; the QUIC handshake data packet includes a server certificate and a server DH public key. A receiving module, configured to receive a client certificate and a signature verification message sent by a client; the signature verification message includes a digital signature of a hash value of the handshake data; A signature verification module is used to extract the public key from the client certificate and verify whether the digital signature is consistent with the handshake data hash value. If the signature verification passes, the pre-master key is calculated based on the server DH private key and the client DH public key, and a 1-RTT session key synchronized with the client is derived; The server-side data encryption transmission module is used to synchronize with the client using the 1-RTT session key to encrypt application layer data and transmit data to the client within the 1-RTT encryption space of the QUIC protocol. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a first flow chart of the identity authentication method of one of the embodiments of the present application.

[0025] Figure 2 This is a process demonstration diagram of unified identity authentication based on the QUIC protocol in one of the embodiments of this application.

[0026] Figure 3 This is an information interaction demonstration diagram of one of the embodiments of this application.

[0027] Figure 4 This is a second flow chart of the identity authentication method of one of the embodiments of the present application.

[0028] Figure 5 This is a third flow chart of the identity authentication method of one of the embodiments of the present application.

[0029] Figure 6 This is a fourth flow chart of the identity authentication method of one of the embodiments of the present application.

[0030] Figure 7 This is the fifth flow chart of the identity authentication method of one of the embodiments of the present application. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical solutions and advantages of this application more clear, the following Figure 1-Figure 7 It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0032] The embodiment of the present application discloses a distributed node unified identity authentication method based on the QUIC protocol on the client side.

[0033] Reference Figure 1 , a distributed node unified identity authentication method based on the QUIC protocol, applied to the client, the identity authentication method includes: Step S101: register the client domain name identity through a certificate authority, obtain the client certificate, and pre-store the service client certificate chain; The client certificate contains the client domain name identifier and the client DH public key; Specifically, during the initial authentication phase, the client registers its domain identity with a certificate authority (CA) and obtains a client certificate issued by the CA. This client certificate contains the client's domain identity and its corresponding Diffie-Hellman (DH) public key. Through the issuance of this certificate, the client obtains a publicly verifiable identity credential, ensuring its uniqueness and reliability.

[0034] Furthermore, pre-storing the server certificate chain prepares for subsequent authentication. When the client receives the certificate returned by the server, it can verify the legitimacy of the server certificate using the pre-stored server certificate chain. This step ensures that the client provides an equivalent authentication mechanism to the server upon connection. This authentication mechanism uses digital certificates instead of traditional IP addresses or usernames and passwords, which is crucial for preventing impersonation and improving overall network security.

[0035] Step S102: Generate a QUIC initial data packet based on the target server domain name identifier and the client certificate and send it to the server; wherein the QUIC initial data packet includes the target server domain name identifier, the client domain name identifier, and the client DH public key; In an embodiment of the present application, the target server domain name identifier in the QUIC initial data packet is embedded in the QUIC initial data packet through the TLS extension, and the client domain name identifier is embedded in the QUIC initial data packet through the Transport Parameter parameter.

[0036] Specifically, after the client completes certificate registration and storage, it will then generate an initial QUIC protocol packet based on its client certificate and the target server's domain name identifier and send it to the server. This packet contains the client's domain name identifier and DH public key. Through this initial packet, the client not only conveys its own identity information to the server, but also the necessary information for key exchange, so that subsequent secure communication can be carried out based on the public key exchange between the two parties.

[0037] Understandably, this step leverages the efficiency of the QUIC protocol, ensuring identity information can be exchanged from the very first packet of the connection without affecting connection latency. During the QUIC connection establishment process, in addition to conventional transmission control, security verification information can also be embedded, ensuring that the entire communication link is established on a trusted identity foundation from the outset.

[0038] Step S103: Receive the QUIC handshake data packet returned by the server; Among them, the QUIC handshake packet includes the server certificate and the server DH public key; Specifically, when the server receives the initial packet from the client, it responds with a QUIC handshake packet containing the server's certificate and the server's DH public key. The core task of the handshake packet is for the server to prove its identity through its certificate and provide the public key information used for subsequent key exchange. The public key in the server certificate is signed by the CA, proving the legitimacy of the server's identity.

[0039] As you can understand, after receiving the server's handshake packet, the client verifies the validity of the server's certificate to ensure the identity provided by the server is authentic. This verification process typically involves verifying the server's digital certificate is valid, signed by a trusted CA, and that the server's identity matches the expected one, using a certificate chain. This process ensures that both parties' identities are correctly confirmed, laying the foundation for subsequent key negotiation and encrypted transmission.

[0040] Step S104: Verify the legitimacy of the server certificate based on the server certificate chain. If it is valid, calculate the pre-master key based on the client DH private key and the server DH public key. Specifically, after verifying the legitimacy of the server's certificate, if the certificate is valid, the client uses its own DH private key and the server's DH public key to calculate a pre-master secret key. This pre-master secret key is the basis for key negotiation between the two parties and provides the core key for subsequent encryption operations. This process relies on the Diffie-Hellman key exchange protocol, which allows two parties to generate a shared secret key using their respective public and private keys without transmitting the keys themselves during communication.

[0041] In this way, the client and server can securely generate a shared secret without directly transmitting the secret key, which is crucial for ensuring the security of subsequent communications. The calculation of the pre-master secret is based on the server's identity verification, ensuring that only legitimately verified servers can participate in the key exchange process.

[0042] In this embodiment of the present application, the steps of calculating the pre-master key based on the client DH private key and the server DH public key include: The pre-master key is calculated based on the Diffie-Hellman key exchange algorithm. The calculation formula is: Pre-master secret key = DH_compute_key(K_ client_priv ,K_ server_pub ); Among them, K_ client_priv is the client DH private key, K_ server_pub The server DH public key.

[0043] Step S105: derive a 1-RTT session key based on the pre-master key; wherein the 1-RTT session key is derived from the pre-master key, the client random number, and the server random number using the HKDF algorithm; Once both the client and server have the pre-master secret, the next step is to derive a 1-RTT session key from the pre-master secret and the client and server's random numbers using the HKDF (HMAC-based Key Derivation Function) algorithm. HKDF is an HMAC-based key derivation function that generates multiple keys using the pre-master secret and additional input data. This 1-RTT session key is used to encrypt subsequent data transmissions.

[0044] Specifically, the 1-RTT session key derivation process ensures randomness and unpredictability, thereby improving encryption strength. This key derivation method allows the client and server to share a single key for subsequent encrypted communications, while preventing the risks of man-in-the-middle and replay attacks. The use of 1-RTT session keys also significantly improves communication security, avoiding security vulnerabilities commonly encountered in traditional communication protocols.

[0045] Step S106: Generate a signature verification message and send the client certificate and signature verification message to the server; the signature verification message includes a digital signature of the handshake data hash value; After the 1-RTT session key is derived, the client generates a signature verification message and sends it to the server. The signature verification message is the result of digitally signing the hash value of the previous handshake data. The client signs the hash value using its private key, proving that it is a legitimate client and can decrypt and generate the signature verification message.

[0046] After receiving the signature verification message from the client, the server verifies the signature using the client's public key. If successful, the client's identity is confirmed to be legitimate, completing the authentication process. Digital signatures not only ensure data integrity and immutability, but also prove that the data originated from the client holding the private key, thereby enhancing communication security.

[0047] Step S107: Synchronize with the server to encrypt the application layer data using the 1-RTT session key, and transmit the data to the server in the 1-RTT encryption space of the QUIC protocol.

[0048] After authentication and key exchange are complete, the client and server begin encrypted communication in the 1-RTT encryption space using a shared 1-RTT session key. In the QUIC protocol, the 1-RTT encryption space is used to protect the security of transmitted data, ensuring that it cannot be eavesdropped or tampered with during subsequent communications. All data transmitted via the QUIC protocol is encrypted using the 1-RTT session key, ensuring data confidentiality and integrity during communication. This step fully protects the entire communication process, ensuring that data transmission is carried out under the dual protection of authentication and encryption, significantly enhancing the security of network communications.

[0049] In the above implementation, during the connection establishment process of the QUIC protocol, the client and the server strictly verify their identities through certificate and key exchange to ensure the security of subsequent communications. Compared with traditional identity authentication methods, this application provides higher security and lower communication latency by introducing digital certificates and key exchange mechanisms when establishing a connection, ensuring the reliability of node identities and the confidentiality of data, and solving security issues such as identity impersonation and data tampering in traditional authentication methods. At the same time, because the QUIC protocol is implemented in user mode and runs on a more common transport layer, it has higher scalability and can effectively promote the popularization and application of secure Internet communications.

[0050] Reference Figure 2 This is a process demonstration diagram of unified identity authentication based on the QUIC protocol shown in this application, where CRYPTO is the data frame carrying TLS 1.3 messages in QUIC; CH is the ClientHello message, which carries the client identity, server identity and DH key exchange information; SH is the ServerHello message, which contains DH key exchange information and is upgraded to a more secure confidential Handshake space.

[0051] Reference Figure 3The following diagram illustrates information exchange, using bob.user accessing bob.home as an example. The key information exchange is illustrated. The signature in the certificate verification is obtained by signing the previous TLS message with each party's private key. In this application, a connection is established and subsequent encrypted data transmission is allowed only after the node's identity is authenticated, ensuring the authenticity of both communicating parties at the source.

[0052] The above process disclosed in the embodiment of the present application is very naturally combined with the QUIC protocol, and the client domain name identity can be sent to the server in the first data packet of the connection establishment for preliminary verification by the server. During the initial handshake process of the QUIC protocol, the message exchange of identity authentication is increased, but the number of additional round-trip communications is not increased, thereby minimizing the impact on the connection establishment time and improving communication efficiency while ensuring the security of identity authentication. At the same time, during the connection migration process of the QUIC protocol, when the network location of the node changes (such as switching from WiFi to a mobile data network), the present application can re-verify the other party's node through the encrypted secure connection migration of the QUIC protocol itself, ensuring the continuity and security of the connection, and avoiding problems such as identity impersonation or communication interruption due to network switching. On the QUIC protocol, both streaming reliable transmission and unreliable datagram transmission can be performed, all under secure encrypted transmission after mutual authentication, meeting various scenarios.

[0053] In contrast, TCP cannot incorporate this client identity into the TCP three-way handshake and must rely on the TLS handshake after the TCP connection is established to convey the message, thus missing the optimal opportunity for client authentication. However, TCP can also achieve a similar effect by adding the client_name to a custom TLS extension in the ClientHello message during the subsequent TLS handshake. This is also the solution for TLS transmission over TCP in this application, but it is far less elegant than the QUIC protocol. In addition, TCP is a system protocol stack, and TLS is a standard library. Modifying and establishing a unified identity interface on top of them is difficult to implement.

[0054] Reference Figure 4 As an implementation of step S104, the step of verifying the legitimacy of the server certificate based on the server certificate chain includes: Step S201: Parse the QUIC handshake packet and extract the server certificate and server DH public key; Specifically, when the client receives the QUIC handshake packet returned by the server, it needs to parse its internal structure to extract key security parameters. The QUIC protocol encapsulates the TLS 1.3 handshake process in a CRYPTO frame, which contains the server's certificate chain (CERT message) and Diffie-Hellman (DH) public key (delivered via the ServerHello message).

[0055] The server's DH public key is used to subsequently calculate the Pre-Master Secret. Its security relies on the difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP), ensuring that a man-in-the-middle cannot derive the private key from an intercepted public key. The server's certificate chain includes the server's entity certificate and intermediate CA certificates, forming a complete chain of trust for client verification.

[0056] Step S202: Verify whether the CA signature chain of the server certificate is complete based on the pre-stored server certificate chain, and check whether the domain name identifier of the server certificate is consistent with the target server domain name identifier; if so, jump to step S203; if not, jump to step S204; Step S203: Determine whether the server certificate is legitimate; Step S204: Determine whether the server certificate is illegal.

[0057] Among them, the client starts from the server entity certificate in the server certificate chain and verifies the issuer signature step by step: use the public key of the upper CA certificate to decrypt the digital signature of the current certificate, calculate the hash value of the certificate body data (such as SHA-256), and compare the decryption result with the hash value to see if they are consistent. Repeat this process until it links to the trust anchor (TrustAnchor) preset by the client (such as the root CA certificate). If any level of signature verification fails or the certificate chain is broken, it is judged to be illegal. In addition, you can also use the Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) to query whether the certificate has been actively revoked by the CA (such as in the case of private key leakage) It should be noted that if the CA signature chain is broken (such as the intermediate CA certificate is missing), the root CA is untrusted, the certificate has been revoked, or the domain name does not match, it indicates that the server identity is suspicious (it may be a phishing site or a man-in-the-middle attack node).

[0058] The above implementation deeply integrates the PKI system with the QUIC protocol stack, achieving for the first time a strong client-server identity verification mechanism at the transport layer. By parsing the cryptographic parameters in the QUIC handshake packet, the client dynamically builds a trust path based on a pre-configured certificate chain. This triple mechanism, combined with CA signature chain verification, revocation status checking, and domain name consistency matching, ensures the non-repudiation and authenticity of the server's identity.

[0059] Reference Figure 4As a further implementation of the identity authentication method, after determining that the server certificate is illegal, the method further includes: Step S301, terminate the QUIC connection establishment process; Specifically, the client immediately sends a CONNECTION_CLOSE frame (with error code TLS_CERTIFICATE_UNKNOWN) to forcibly close the QUIC connection. This prevents subsequent transmission of sensitive data (such as application-layer credentials) over the unauthenticated channel. It should be noted that QUIC's multiplexing feature requires that connections be terminated before all streams are established, preventing attackers from injecting malicious payloads using 0-RTT data.

[0060] Step S302: Return an authentication failure error code to the client application layer and record the server certificate fingerprint in the local blacklist.

[0061] This process returns an authentication failure error code (such as ERR_QUIC_CERT_AUTH_FAILED) to the application layer, triggering an application-level circuit breaker (e.g., disabling retries or switching to a backup node). The fingerprint of the illegal certificate is calculated and stored in a local blacklist. When establishing subsequent connections, the certificate fingerprint is prioritized against the blacklist, enabling rapid local blocking and reducing repeated verification overhead.

[0062] For example, if the client detects that the issuing CA of the server certificate is an unfamiliar organization (such as "Malicious CA"), it will add the certificate fingerprint to the blacklist. If the same certificate appears again in the future, the client can directly reject the connection without going through the full verification process.

[0063] In the above implementation, illegal certificates are immediately blocked and a fingerprint blacklist strategy is implemented, thereby building an active defense barrier and effectively curbing phishing attacks and man-in-the-middle threats.

[0064] Reference Figure 5 As a further embodiment of the identity authentication method, the identity authentication method further includes: Step S401: When transmitting data in the 1-RTT encryption space of the QUIC protocol, if a change in the client IP address is detected, the QUIC connection identifier remains unchanged; The QUIC protocol abstracts the network path through a connection identifier (CID) to handle client IP address changes. The CID is independent of the underlying IP address and port number. Even if the network path undergoes topological changes (such as NAT remapping or mobile network switching), the QUIC protocol stack only needs to maintain the CID, ensuring seamless migration between communicating parties.

[0065] Specifically, when the client's IP address changes (for example, switching from WiFi to a mobile network), traditional TCP connections rely on a five-tuple (source IP, source port, destination IP, destination port, protocol type) to uniquely identify the connection, while QUIC uses an explicitly defined CID as the unique identifier of the connection. After the client detects the IP address change (through operating system notification or active detection), it continues to use the original CID to send data packets. The server associates the connection context (such as encryption status, flow control window) with the CID rather than the IP address. At this point, the source IP address of the underlying UDP data packet has changed, but the QUIC protocol stack uses the CID to identify that the new and old data packets belong to the same logical connection, without the need to rebuild the connection or re-handshake.

[0066] Step S402: encrypt the data of the new IP path by reusing the 1-RTT session key; The QUIC protocol decouples keys from the network path through a layered key architecture, ensuring secure communication continuity after connection migration. Key derivation relies on random numbers and pre-master secrets exchanged during the handshake, which are independent of the underlying IP path. Therefore, regardless of network path changes, as long as the CID remains unchanged, the derived key remains valid.

[0067] When a new IP path packet arrives, the QUIC protocol stack uses the existing 1-RTT session key to decrypt the packet payload (application layer data) and encrypts the new path packet header (such as the packet number) with Header Protection (HP) to ensure that attackers cannot associate the new and old paths by sniffing the packets.

[0068] Step S403: Send a connection migration notification frame to the server.

[0069] Specifically, after the client switches to the new IP path, it actively sends a connection migration notification frame containing a PATH_CHALLENGE frame to the server. This frame carries a randomly generated non-repeating value (8-byte random number), triggering the server to perform path verification. After receiving the PATH_CHALLENGE frame, the server generates an address verification token (encrypted Nonce and timestamp, signed with a shared key such as address_key through HMAC-SHA256), and returns it to the client through a PATH_RESPONSE frame. The client must carry this token (embedded in a NEW_TOKEN frame) in subsequent data packets on the new path, and the server decrypts and verifies the validity of the token (HMAC verification, timeliness check). After the token verification is successful, the server confirms the client's control over the new IP path (not man-in-the-middle hijacking) and formally accepts the new path as a legitimate communication channel.

[0070] In the above implementation, the unification of network layer transparent migration and transport layer session persistence is achieved. In the scenario where the client IP address changes, the persistence of the QUIC connection identifier (CID) maintains the continuity of the logical session, and the reuse of 1-RTT session keys avoids the overhead of key renegotiation. The address verification token mechanism ensures the legitimacy and anti-attack capability of the new path through a cryptographic challenge-response model.

[0071] The embodiment of the present application also discloses a distributed node unified identity authentication system based on the QUIC protocol on the client side.

[0072] A distributed node unified identity authentication system based on the QUIC protocol, applied to the client, the identity authentication system includes: The client identity registration module is used to register the client domain identity through the certificate authority, obtain the client certificate, and pre-store the service client certificate chain; the client certificate contains the client domain identity and the client DH public key; A data packet transmission module, configured to generate a QUIC initial data packet based on the target server domain name identifier and the client certificate and send the packet to the server; wherein the QUIC initial data packet includes the target server domain name identifier, the client domain name identifier, and the client DH public key; The handshake packet receiving module is used to receive the QUIC handshake packet returned by the server; the QUIC handshake packet includes the server certificate and the server DH public key; The server certificate verification module is used to verify the legitimacy of the server certificate based on the server certificate chain. If it is valid, the pre-master key is calculated based on the client DH private key and the server DH public key. A session key generation module is used to derive a 1-RTT session key based on a pre-master key. The 1-RTT session key is derived from the pre-master key, a client random number, and a server random number using the HKDF algorithm. A signature verification message generation module is used to generate a signature verification message; the signature verification message includes a digital signature of the handshake data hash value; The sending module is used to send the client certificate and signature verification message to the server; The client data encryption transmission module is used to synchronize with the server using the 1-RTT session key to encrypt application layer data and transmit data to the server within the 1-RTT encryption space of the QUIC protocol.

[0073] The embodiment of the present application also discloses a distributed node unified identity authentication method based on the QUIC protocol on the server side.

[0074] Reference Figure 6, a distributed node unified identity authentication method based on the QUIC protocol, applied to the server, the identity authentication method includes: Step S501: register the server domain name identity through a certificate authority, obtain a server certificate, and pre-store a list of authorized client domain names; The server certificate includes the server domain name identifier and the server public key; Specifically, the server first registers its domain identity with a certificate authority (CA) and obtains a server certificate signed by the CA. The server certificate contains the server's domain identifier and the server's public key. The domain identifier is the server's unique identifier, while the public key is used for key exchange in encrypted communications. The server certificate verifies the server's identity and enables secure communication with the client using its public key. This certificate is issued by a CA within the public key infrastructure (PKI) system, ensuring its legitimacy and security.

[0075] The server also needs to pre-store a list of authorized client domain names. This list contains all valid, authorized client domain names. During the authentication process, the server uses this list to verify that the client is a trusted party. This way, when the server receives a client request, it can determine whether to allow the connection based on the authorized client domain name. This ensures that only clients that meet the authorization criteria can establish a connection with the server, eliminating the risks of unauthorized access and identity impersonation.

[0076] Step S502: Receive the QUIC initial data packet sent by the client, and parse to obtain the target server domain name identifier and the client domain name identifier; When a client initiates a connection request, it sends an initial data packet via the QUIC protocol. This packet contains the target server domain name identifier and the client domain name identifier. Upon receiving this initial data packet, the server first parses it to extract the server and client domain name information contained therein. The target server domain name identifier is used to ensure that the client is connecting to the intended server, while the client domain name identifier is used to identify the client.

[0077] During this step, the server needs to ensure that the target server's domain name identifier matches its own domain name to prevent man-in-the-middle attacks or mistargeting. The client's domain name identifier provides preliminary verification of the user's legitimacy (if not, the connection will be rejected) and provides a clue for subsequent authentication. The server uses this identifier to determine whether the client is on the authorized list and whether to continue the connection.

[0078] Step S503: Verify the QUIC initial data packet based on the authorized client domain name list. If the verification passes, generate the server DH public key and construct a QUIC handshake data packet to send to the client; wherein the QUIC handshake data packet includes the server certificate and the server DH public key; Once the server successfully resolves and extracts the client's domain name, it will verify that the client is authorized to access the service based on a pre-stored list of authorized client domain names. The server verifies that the client is a legitimate party by comparing the client's domain name with the entries in the authorization list. If verification is successful, the server allows the connection to proceed and generates the server's Diffie-Hellman (DH) public key, which is transmitted via the ServerHello message in the QUIC CRYPTO frame.

[0079] Specifically, the process of generating a DH public key is based on the Diffie-Hellman key exchange protocol, which enables the server and client to securely generate a shared key without directly exchanging keys. The server encapsulates the generated DH public key and the server's certificate into a QUIC handshake packet and sends it back to the client. Through this handshake packet, the server not only transmits its identity credentials (i.e., the server certificate) but also provides the public key information used for subsequent key negotiation. The key to this step is to use the server's certificate and DH public key to protect the subsequent key exchange process, ensuring secure communication between the client and server.

[0080] Step S504: Receive the client certificate and signature verification message sent by the client; wherein the signature verification message includes a digital signature of the handshake data hash value; After receiving the QUIC handshake packet from the server, the client responds to the server's request by sending its client certificate and signature verification message. The client certificate contains the client's public key and a digital signature issued by the CA proving its identity. The client also generates a signature verification message that digitally signs the hash of the previous handshake data. This signature verification message is generated by encrypting the handshake data with the client's private key, proving that the client possesses the corresponding private key and has not tampered with the handshake data.

[0081] After receiving the client's certificate and signature verification message, the server verifies the public key in the client's certificate to ensure its legitimacy. By verifying the digital signature, the server can ensure that the handshake data has not been tampered with during transmission, thereby confirming the legitimacy of the client's identity.

[0082] Step S505: Extract the public key from the client certificate and verify whether the digital signature is consistent with the handshake data hash value. If the signature verification is successful, calculate the pre-master key based on the server DH private key and the client DH public key, and derive the 1-RTT session key synchronized with the client. After verifying the client certificate, the server extracts the public key from the client certificate and uses it to verify the signature verification message sent by the client. By verifying the digital signature, the server ensures the integrity and authenticity of the data sent by the client. If the digital signature matches the handshake data hash value, the client's authentication is successful.

[0083] Once the client's identity is authenticated, the server uses its own DH private key and the client's DH public key to calculate a pre-master secret using the Diffie-Hellman protocol. The pre-master secret is a shared key from which subsequent session keys are derived. The server and client then use this pre-master secret to derive a 1-RTT session key using the HKDF algorithm (HMAC-based Key Derivation Function), ensuring that both parties use the same key for encryption during subsequent data transmission. This step generates a symmetric encryption key that protects subsequent communication data.

[0084] Step S506: Synchronize with the client to encrypt the application layer data using the 1-RTT session key, and transmit the data to the client in the 1-RTT encryption space of the QUIC protocol.

[0085] Once the 1-RTT session key is successfully derived, the client and server can use it to encrypt application-layer data. Within the QUIC protocol's 1-RTT encryption space, all application-layer data is encrypted, ensuring that only the communicating parties can decrypt and access it. The QUIC protocol's encryption not only provides data confidentiality but also ensures integrity and immutability during data transmission. This step completes post-authentication data protection, ensuring that the security of communication data is not compromised throughout the session.

[0086] In the above implementation, combined with the server certificate, client certificate, digital signature and Diffie-Hellman key exchange protocol, strong identity authentication and key negotiation are implemented in the connection establishment phase of the QUIC protocol. Through this identity authentication process, the server can accurately identify and verify the identity of the client, ensuring that the data transmission of subsequent communications is carried out under encryption protection, and effectively preventing security issues such as identity impersonation and data theft. Compared with traditional identity authentication mechanisms, this application provides a more secure, flexible and low-latency identity authentication solution, which is particularly suitable for unified identity authentication of large-scale Internet nodes.

[0087] Reference Figure 7 As an implementation of step S, the steps of extracting the public key from the client certificate and verifying whether the digital signature is consistent with the handshake data hash value include: Step S601, parsing the public key from the client certificate; Step S602: decrypt the digital signature using the client certificate public key to obtain a signature hash value; Specifically, during the handshake phase, the client uses the private key to sign the hash value of the handshake data (such as the SHA-256 digest). The signature algorithm is consistent with the certificate public key algorithm. For example, the ECDSA signature process is: randomly generate a temporary key pair (k, R), calculate the x coordinate of the elliptic curve point R .calculate (d is the client private key), and the final signature is a (r, s) tuple. Next, the client certificate public key is used to verify the legitimacy of the signature mathematical relationship. Taking ECDSA as an example, the signature verification process requires: reconstructing the temporary point R based on r and s, and verifying that it satisfies the curve equation; calculating and , verify whether the public key point Q satisfies (G is the base point of the curve). If the signature verification is successful, the integrity of the Hash value and the authenticity of the signature are determined.

[0088] Step S603, recalculate the handshake data hash value; Step S604: determine whether the signature hash value is equal to the handshake data hash value; if so, jump to step S605; if not, jump to step S606; Step S605, indicating that the signature verification is successful; Step S606: If the signature hash value is not equal to the handshake data hash value, it indicates that the signature verification has failed.

[0089] For example, if there is middleman tampering during the handshake process (such as modifying the Cipher Suite list of ClientHello), the hash value of the client signature is generated based on the original data, while the server calculates the tampered hash value, resulting in signature verification failure.

[0090] The above implementation deeply integrates the digital signature verification mechanism with the QUIC / TLS protocol stack, building an end-to-end strong authentication system for client identities. The server parses the X.509 certificate to obtain the public key, verifies the authenticity of the handshake data signature based on the mathematical principles of asymmetric encryption, and combines it with a collision-resistant hash algorithm to ensure data integrity.

[0091] Reference Figure 7 As a further implementation of the unified identity authentication method, after the signature verification fails, the method further includes: Step S607: Send a TLS Alert message carrying the error type; Specifically, the server constructs a fatal-level Alert message with the error type bad_certificate (corresponding to Alert 42 defined in the TLS 1.3 protocol). The Alert message is encrypted using the highest security level key available at the current stage (such as the HandshakeTraffic Secret) to prevent attackers from stealing the error type and performing protocol reverse engineering.

[0092] Step S608: Terminate the QUIC connection and record the client certificate fingerprint in the audit log.

[0093] Specifically, the server immediately sends a CONNECTION_CLOSE frame (with error code TLS_HANDSHAKE_FAILED), closes all active streams, and releases the connection state machine. According to RFC 9000, the termination process requires clearing the send buffer, discarding unacknowledged packets, and starting the quiet period timer (to prevent the leakage of resources in the half-closed state). The client certificate fingerprint is calculated using a hash digest algorithm (such as SHA-256) and stored in an encrypted audit log. The fingerprint record format includes a timestamp, client IP address, certificate serial number, and fingerprint value for later correlation analysis (such as troubleshooting multiple attack attempts against the same certificate).

[0094] In the above implementation, when signature verification fails, a three-tiered response strategy is implemented: encrypted alert messages notifying the error type, forced connection termination, and fingerprint auditing. This provides proactive security defense and post-event traceability. Furthermore, the integration of audit logs and blacklist mechanisms provides infrastructure support for analyzing abnormal behavior in distributed nodes, significantly improving the reliability and anti-APT attack capabilities of the Internet's unified identity authentication system.

[0095] The embodiment of the present application also discloses a distributed node unified identity authentication system based on the QUIC protocol on the server side.

[0096] A distributed node unified identity authentication system based on the QUIC protocol, applied to the server, the identity authentication system includes: The server identity registration module is used to register the server domain identity through the certificate authority, obtain the server certificate, and pre-store the list of authorized client domain names; the server certificate includes the server domain name identifier and the server public key; The data packet parsing module is used to receive the QUIC initial data packet sent by the client and parse it to obtain the target server domain name identifier and the client domain name identifier; The packet verification module is used to verify the QUIC initial packet based on the authorized client domain name list. If the verification passes, it generates the server DH public key and constructs a QUIC handshake packet to send to the client; the QUIC handshake packet includes the server certificate and the server DH public key; A receiving module is used to receive a client certificate and a signature verification message sent by the client; the signature verification message includes a digital signature of a hash value of the handshake data; The signature verification module is used to extract the public key from the client certificate and verify whether the digital signature is consistent with the handshake data hash value. If the signature verification passes, the pre-master secret is calculated based on the server DH private key and the client DH public key, and the 1-RTT session key synchronized with the client is derived; The server-side data encryption transmission module is used to synchronize with the client using the 1-RTT session key to encrypt application layer data and transmit data to the client within the 1-RTT encryption space of the QUIC protocol.

[0097] In practical applications, this application deeply integrates the QUIC protocol with the PKI certificate system to build a unified identity authentication mechanism for Internet nodes at the transport layer, fundamentally solving the security flaws and ecological fragmentation problems of traditional identity authentication solutions. Its core value is reflected in four dimensions: 1. On the security front, the solution relies on a strong verification mechanism based on digital signatures to achieve two-way identity authentication between the client and server during the QUIC connection establishment phase. Compared to the weak verification of usernames and passwords at the application layer (which are vulnerable to phishing attacks and brute force cracking), the certificate-based PKI system ensures non-repudiation of identity through asymmetric encryption. At the same time, leveraging the native end-to-end encryption capabilities of the QUIC protocol, it directly blocks risks such as data theft, man-in-the-middle hijacking, and IP spoofing at the transport layer, forming a full-link protection from identity authentication to data transmission. For example, attackers cannot forge client certificates to pass handshake verification, nor can they decrypt data packets in the 1-RTT encrypted space, significantly reducing the probability of privacy leakage and asset loss.

[0098] 2. In terms of user experience, the unified identity system eliminates the complexity of managing multiple accounts. Users no longer need to remember separate application-layer passwords or repeatedly log in to different services. When a device holds a domain name certificate issued by a CA, the QUIC protocol automatically completes identity authentication in the background when accessing any Internet service that supports this standard (for example, when a user accesses an e-commerce platform, the system uses the client_name="alice.user" certificate to achieve seamless login). This identity can also be used uniformly at the application layer for Internet service verification and association with the same legitimate user. This not only reduces user interruptions caused by forgotten passwords, but also reduces the average login time from several seconds in traditional solutions to within milliseconds of the QUIC handshake delay, significantly improving the smoothness of interaction.

[0099] 3. On the business operations level, this reduces costs and increases efficiency for service providers. Enterprises no longer need to develop and maintain independent identity authentication modules, saving R&D and security audit costs (e.g., eliminating the overhead of adapting protocols like OAuth and SAML). Unified, certificated identities improve the accuracy of cross-business user profiles and support personalized service optimization (e.g., analyzing user behavior chains based on global identity). Furthermore, security mechanisms embedded in the transport layer reduce customer complaints and after-sales pressures caused by account theft, indirectly minimizing the risk of business losses.

[0100] 4. At the industry ecosystem level, protocol-level identity standards break down application silos. User certificates become cross-platform credentials (e.g., logging into social, payment, and IoT applications using the same *.user domain), promoting service interconnection and compliant data sharing. This infrastructure-level innovation lays the foundation for converged scenarios (such as cross-enterprise single sign-on and distributed digital identity interconnection), driving the internet's evolution from a "closed service cluster" to an "open and trusted ecosystem."

[0101] Based on this, this application uses the QUIC protocol as a carrier to sink PKI certificate authentication to the transport layer, achieving highly secure, low-friction unified authentication with zero additional latency. Its technical effect is not only reflected in the strengthening of single-point security, but also, by reconstructing the foundation of Internet identity, systematically optimizing user experience, business efficiency, and industry collaboration capabilities.

[0102] A distributed node unified identity authentication system based on the QUIC protocol in an embodiment of the present application can implement any of the above-mentioned identity authentication methods, and the specific working processes of each module in the identity authentication system can refer to the corresponding processes in the above-mentioned method embodiments.

[0103] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a module is merely a logical functional division, and in actual implementation, other division methods may be used, such as combining or integrating multiple modules into another system, or ignoring or not implementing certain features.

[0104] It should be noted that, in the above embodiments, the description of each embodiment has different emphases. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0105] The above are all preferred embodiments of the present application and are not intended to limit the scope of protection of this application. Unless otherwise specified, any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features. In other words, unless otherwise specified, each feature is merely an example of a series of equivalent or similar features.

Claims

1. A distributed node unified identity authentication method based on the QUIC protocol, characterized in that: Applied to the client, the identity authentication method includes: Register the client domain name identity through a certificate authority, obtain a client certificate, and pre-store the service client certificate chain; wherein the client certificate includes the client domain name identifier and the client DH public key; Generate a QUIC initial data packet based on the target server domain name identifier and the client certificate and send it to the server; wherein the QUIC initial data packet includes the target server domain name identifier, the client domain name identifier and the client DH public key; Receive a QUIC handshake packet returned by the server; the QUIC handshake packet includes the server certificate and the server DH public key; Verify the legitimacy of the server certificate based on the server certificate chain. If it is valid, calculate the pre-master key based on the client DH private key and the server DH public key; Deriving a 1-RTT session key based on the pre-master key; wherein the 1-RTT session key is derived from the pre-master key, the client random number and the server random number using the HKDF algorithm; Generate a signature verification message and send the client certificate and signature verification message to the server; the signature verification message includes a digital signature of the handshake data hash value; Synchronously encrypt application layer data using the 1-RTT session key with the server, and transmit the data to the server within the 1-RTT encryption space of the QUIC protocol.

2. A distributed node unified identity authentication method based on the QUIC protocol according to claim 1, characterized in that: The step of verifying the legitimacy of the server certificate based on the server certificate chain includes: Parse the QUIC handshake packet and extract the server certificate and server DH public key; Verify whether the CA signature chain of the server certificate is complete based on the pre-stored server certificate chain, and check whether the domain name identifier of the server certificate is consistent with the target server domain name identifier; if so, determine that the server certificate is legal; if not, determine that the server certificate is illegal.

3. A distributed node unified identity authentication method based on the QUIC protocol according to claim 2, characterized in that: After the step of determining that the server certificate is illegal, the method further includes: Terminate the QUIC connection establishment process; Returns an authentication failure error code to the client application layer and records the server certificate fingerprint to the local blacklist.

4. A distributed node unified identity authentication method based on the QUIC protocol according to claim 1, characterized in that: The steps for calculating the pre-master secret key based on the client DH private key and the server DH public key include: The pre-master key is calculated based on the Diffie-Hellman key exchange algorithm. The calculation formula is: Pre-master secret key = DH_compute_key(K_ client_priv ,K_ server_pub ); Among them, K_ client_priv is the client DH private key, K_ server_pub The server DH public key.

5. A distributed node unified identity authentication method based on the QUIC protocol according to any one of claims 1 to 4, characterized in that: The identity authentication method further includes: When transmitting data within the 1-RTT encryption space of the QUIC protocol, if a change in the client IP address is detected, the QUIC connection identifier remains unchanged; Reusing the 1-RTT session key to encrypt data on the new IP path; Send a connection migration notification frame to the server.

6. A distributed node unified identity authentication method based on the QUIC protocol, characterized in that: Applied to the server, the identity authentication method includes: Register the server domain name identity through a certificate authority, obtain a server certificate, and pre-store a list of authorized client domain names; wherein the server certificate includes the server domain name identifier and the server public key; Receive the QUIC initial data packet sent by the client, and parse it to obtain the target server domain name identifier and the client domain name identifier; Verify the QUIC initial data packet based on the authorized client domain name list. If the verification passes, generate a server DH public key and construct a QUIC handshake data packet to send to the client; the QUIC handshake data packet includes the server certificate and the server DH public key; Receive a client certificate and a signature verification message sent by the client; the signature verification message includes a digital signature of a hash value of the handshake data; Extract the public key from the client certificate and verify whether the digital signature is consistent with the handshake data hash value. If the signature verification is successful, calculate the pre-master key based on the server DH private key and the client DH public key, and derive the 1-RTT session key synchronized with the client; Synchronously encrypt application layer data using the 1-RTT session key with the client, and transmit the data to the client within the 1-RTT encryption space of the QUIC protocol.

7. A distributed node unified identity authentication method based on the QUIC protocol according to claim 6, characterized in that: The steps of extracting the public key from the client certificate and verifying whether the digital signature is consistent with the handshake data hash value include: Parsing a public key from the client certificate; Decrypt the digital signature using the client certificate public key to obtain a signature hash value; Recalculate the handshake data hash value. If the signature hash value is equal to the handshake data hash value, the signature verification is successful. If the signature hash value is not equal to the handshake data hash value, it means that the signature verification has failed.

8. A distributed node unified identity authentication method based on the QUIC protocol according to claim 7, characterized in that: After the signature verification failed step, also include: Send a TLS Alert message containing the error type; Terminates the QUIC connection and records the client certificate fingerprint to the audit log.

9. A distributed node unified identity authentication system based on the QUIC protocol, characterized in that: Applied to the client, the identity authentication system includes: The client identity registration module is used to register the client domain name identity through the certificate authority, obtain the client certificate, and pre-store the service client certificate chain; wherein the client certificate includes the client domain name identifier and the client DH public key; A data packet transmission module, configured to generate a QUIC initial data packet based on the target server domain name identifier and the client certificate and send the QUIC initial data packet to the server; wherein the QUIC initial data packet includes the target server domain name identifier, the client domain name identifier, and the client DH public key; A handshake packet receiving module is used to receive a QUIC handshake packet returned by the server; the QUIC handshake packet includes a server certificate and a server DH public key; The server certificate verification module is used to verify the legitimacy of the server certificate based on the server certificate chain. If it is legitimate, it calculates the pre-master key based on the client DH private key and the server DH public key; A session key generation module, configured to derive a 1-RTT session key based on the pre-master key; wherein the 1-RTT session key is derived from the pre-master key, a client random number, and a server random number using the HKDF algorithm; A signature verification message generation module is used to generate a signature verification message; the signature verification message includes a digital signature of the handshake data hash value; The sending module is used to send the client certificate and signature verification message to the server; The client data encryption transmission module is used to synchronize with the server using the 1-RTT session key to encrypt application layer data and transmit data to the server within the 1-RTT encryption space of the QUIC protocol.

10. A distributed node unified identity authentication system based on the QUIC protocol, characterized in that: Applied to the server, the identity authentication system includes: A server identity registration module is used to register the server domain name identity through a certificate authority, obtain a server certificate, and pre-store a list of authorized client domain names; wherein the server certificate includes the server domain name identifier and the server public key; The data packet parsing module is used to receive the QUIC initial data packet sent by the client and parse it to obtain the target server domain name identifier and the client domain name identifier; A data packet verification module is configured to verify the QUIC initial data packet based on the authorized client domain name list. If the verification succeeds, the module generates a server DH public key and constructs a QUIC handshake data packet to send to the client; the QUIC handshake data packet includes a server certificate and a server DH public key. A receiving module, configured to receive a client certificate and a signature verification message sent by a client; the signature verification message includes a digital signature of a hash value of the handshake data; A signature verification module is used to extract the public key from the client certificate and verify whether the digital signature is consistent with the handshake data hash value. If the signature verification passes, the pre-master key is calculated based on the server DH private key and the client DH public key, and a 1-RTT session key synchronized with the client is derived; The server-side data encryption transmission module is used to synchronize with the client using the 1-RTT session key to encrypt application layer data and transmit data to the client within the 1-RTT encryption space of the QUIC protocol.

Images