A distributed node unified identity authentication method and system based on a QUIC protocol

Abstract

The application relates to a distributed node unified identity authentication method and system based on a QUIC protocol, belongs to the technical field of network security, and is applied to a client. The identity authentication method comprises the following steps: registering a client domain name identity through a certificate authority, obtaining a client certificate, and prestoring a server certificate chain; generating a QUIC initial data packet according to a target server domain name identifier and the client certificate and sending the QUIC initial data packet to a server; receiving a QUIC handshake data packet returned by the server; verifying the legality of a server certificate based on the server certificate chain, and if the server certificate is legal, calculating a pre-master key according to a client DH private key and a 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 the server; and synchronously encrypting application layer data with the 1-RTT session key with the server, and transmitting data to the server in a 1-RTT encryption space of the QUIC protocol. The application ensures the reliability of node identity and the confidentiality of data.

Description

TECHNICAL FIELD

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

[0002] The Internet, as the core carrier of the global information infrastructure, is designed based on the premise of mutual trust between network nodes in the early stage of design. However, with the exponential expansion of the network scale and the massive access of heterogeneous devices, this design lacking a native identity verification mechanism gradually exposes serious security defects. Since the network transmission layer does not effectively verify the real identity of the communication node, malicious nodes can easily initiate man-in-the-middle attacks, data theft or service denial and other threats by forging their identities, resulting in identity impersonation problems becoming a systematic hidden danger restricting the development of Internet security.

[0003] The current Internet Protocol (IP) address, as the core identifier of the node, is essentially a mixture of identity attributes and network location attributes. Although the industry has been committed to decoupling the two attributes to build an independent identity system for many years, the actual progress has always been limited. The strong coupling of these two attributes causes the node identity to be unable to exist independently of the network topology. Once the node changes its location due to migration across networks, dynamic address allocation (such as the DHCP protocol) or network address translation (NAT), its identity identifier becomes invalid. To address this fundamental defect, application service providers are forced to build identity authentication mechanisms in upper-layer protocols such as HTTP, for example, account systems based on usernames / passwords, third-party social logins, etc. This decentralized solution has given rise to new structural contradictions: various applications form closed identity islands, and users need to maintain multiple independent authentication credentials. This not only significantly increases the operational burden, but also further amplifies security risks due to the uneven strength of authentication (such as weak password policies).

[0004] In the exploration of the technical path of unified identity identification, the industry has tried various schemes, but all have significant limitations. For example, directly using the IP address as the identity identifier cannot achieve persistent binding of the identity due to the dynamic allocation of addresses, and is vulnerable to IP spoofing attacks; embedding user identifiers at the data link layer (such as inserting a broadband account number into an Ethernet frame) requires modification of the underlying frame structure, resulting in wasted bandwidth and incompatibility with mobile Internet scenarios; the IP Authentication Header (AH) at the network layer can verify the integrity of data packets, but cannot solve the problem of identity trustworthiness, and is incompatible with widely deployed NAT devices. More complex solutions such as the Resource Public Key Infrastructure (RPKI) attempt to bind IP addresses through certificates, but are difficult to implement due to the inability to overcome address dynamics; and the Transport Layer Security protocol (such as ESP) provides encryption capabilities, but the processing overhead of its multi-layer protocol stack makes it difficult to meet the needs of high-concurrency and low-latency scenarios.

[0005] Currently, existing solutions are either limited by rigid constraints of protocol layers (such as TCP cannot carry client identity in the handshake phase), or subject to implementation complexity (such as RPKI needs to reconstruct the global routing system), and always fail to achieve complete separation of identity and location. Therefore, how to establish a decentralized, persistent and verifiable global node identity system under the premise of ensuring communication efficiency is a technical problem to be solved at present. SUMMARY

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

[0007] In a first aspect, the application provides a distributed node unified identity authentication method based on the QUIC protocol, which adopts the following technical scheme:

[0008] A distributed node unified identity authentication method based on the QUIC protocol, applied to a client, the identity authentication method comprising:

[0009] Registering the client domain name identity through a certificate authority, obtaining a client certificate, and pre-storing a server certificate chain; wherein the client certificate contains a client domain name identifier and a client DH public key;

[0010] Generating a QUIC initial data packet according to the target server domain name identifier and the client certificate and sending 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;

[0011] Receiving the QUIC handshake data packet returned by the server; the QUIC handshake data packet includes a server certificate and a server DH public key;

[0012] Verifying the legality of the server certificate based on the server certificate chain, and if it is legal, calculating a pre-master key according to the client DH private key and the server DH public key;

[0013] 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 through the HKDF algorithm;

[0014] Generating a signature verification message, and sending the client certificate and the signature verification message to the server; the signature verification message includes a digital signature of the handshake data hash value;

[0015] Synchronizing with the server to encrypt the application layer data using the 1-RTT session key, and transmitting data to the server in the 1-RTT encryption space of the QUIC protocol.

[0016] By adopting the above technical solution, in the connection establishment process of the QUIC protocol, the client and the server strictly verify the identity through the certificate and the key exchange, ensuring the security of subsequent communication. Compared with the traditional identity authentication method, the application introduces the digital certificate and the key exchange mechanism, providing higher security and lower communication delay, ensuring the reliability of node identity and the confidentiality of data, and solving the security problems such as identity impersonation and data tampering in the traditional authentication method. At the same time, since the QUIC protocol is implemented in the user mode, it has higher expansibility, which can effectively promote the popularization and application of Internet secure communication.

[0017] Optionally, the step of verifying the legality of the service end certificate based on the service end certificate chain comprises:

[0018] parsing the QUIC handshake packet to extract the service end certificate and the service end DH public key;

[0019] verifying whether the CA signature chain of the service end certificate is complete based on the pre-stored service end certificate chain, and checking whether the domain name identifier of the service end certificate is consistent with the target service end domain name identifier; if yes, it is determined that the service end certificate is legal; if not, it is determined that the service end certificate is illegal.

[0020] By adopting the above technical solution, the PKI system is deeply integrated with the QUIC protocol stack, and the strong verification mechanism of the client to the service end identity is first realized at the transport layer. The client parses the cryptographic parameters in the QUIC handshake packet, dynamically constructs a trust path based on the pre-set certificate chain, and combines the CA signature chain verification, revocation status check and domain name consistency matching three mechanisms to ensure the non-repudiation and authenticity of the service end identity.

[0021] Optionally, the step of determining that the service end certificate is illegal further comprises:

[0022] terminating the QUIC connection establishment process;

[0023] returning an identity authentication failure error code to the client application layer, and recording the service end certificate fingerprint to the local blacklist.

[0024] By adopting the above technical solution, the illegal certificate is blocked immediately, and the fingerprint blacklist strategy is executed, building an active defense barrier, effectively curbing the phishing attacks and man-in-the-middle threats.

[0025] Optionally, the step of calculating the pre-master key based on the client DH private key and the service end DH public key comprises:

[0026] calculating the pre-master key based on the Diffie-Hellman key exchange algorithm, and the calculation formula is:

[0027] Pre-master key = DH_compute_key(K client_priv , K server_pub );

[0028] Wherein, K client_priv is a client DH private key, K server_pub is a server DH public key.

[0029] Optionally, the identity authentication method further comprises:

[0030] When transmitting data in the 1-RTT encryption space of the QUIC protocol, if a client IP address change is detected, the QUIC connection identifier is kept unchanged;

[0031] Multiplexing the 1-RTT session key to encrypt data of the new IP path;

[0032] Sending a connection migration notification frame to the server.

[0033] By adopting the above technical solution, the network layer transparent migration and the transmission layer session continuity are unified. In the client IP address change scenario, the persistence of the QUIC connection identifier (CID) maintains the continuity of the logical session, the reuse of the 1-RTT session key avoids the overhead of key re-negotiation, and the address verification token mechanism ensures the legitimacy and attack resistance of the new path through the challenge-response model.

[0034] In a second aspect, the application provides a distributed node unified identity authentication method based on the QUIC protocol, which adopts the following technical solution:

[0035] A distributed node unified identity authentication method based on the QUIC protocol, applied to a server, the identity authentication method comprising:

[0036] Registering a server domain name identity through a certificate authority, obtaining a server certificate, and pre-storing an authorized client domain name list; wherein the server certificate comprises a server domain name identifier and a server public key;

[0037] Receiving a QUIC initial data packet sent by a client, and parsing to obtain a target server domain name identifier and a client domain name identifier;

[0038] Verifying the QUIC initial data packet based on the authorized client domain name list, if the verification is passed, generating a server DH public key, and constructing a QUIC handshake data packet and sending it to the client; the QUIC handshake data packet comprises a server certificate and a server DH public key;

[0039] Receiving a client certificate and a signature verification message sent by the client; the signature verification message comprises a digital signature of a handshake data hash value;

[0040] extracting the public key from the client certificate and verifying whether the digital signature is consistent with the handshake data hash value, if the signature verification is passed, calculating a pre-master key based on the server DH private key and the client DH public key, and deriving a 1-RTT session key synchronized with the client;

[0041] encrypting application layer data using the 1-RTT session key and transmitting data to the client in the 1-RTT encryption space of the QUIC protocol.

[0042] By adopting the above technical solution, strong identity authentication and key agreement are realized in the connection establishment stage of the QUIC protocol by combining the server certificate, the client certificate, the digital signature, and the Diffie-Hellman key exchange protocol. Through the identity authentication process, the server can accurately identify and verify the identity of the client, ensure that the data transmission in subsequent communication is carried out under encryption protection, and effectively prevent security problems such as identity impersonation and data theft. Compared with the traditional identity authentication mechanism, the present application provides a more secure, flexible and low-latency identity authentication scheme, which is especially suitable for unified identity authentication of large-scale Internet nodes.

[0043] Optionally, the step of extracting the public key from the client certificate and verifying whether the digital signature is consistent with the handshake data hash value comprises:

[0044] parsing the public key from the client certificate;

[0045] decrypting the digital signature using the client certificate public key to obtain a signature hash value;

[0046] recalculating the handshake data hash value, if the signature hash value is equal to the handshake data hash value, it indicates that the signature verification is passed;

[0047] if the signature hash value is not equal to the handshake data hash value, it indicates that the signature verification fails.

[0048] By adopting the above technical solution, the digital signature verification mechanism is deeply bound with the QUIC / TLS protocol stack, and an end-to-end strong verification system of the client identity is constructed. The server obtains the public key by parsing the X.509 certificate, verifies the authenticity of the handshake data signature based on the principle of asymmetric encryption mathematics, and ensures the data integrity by combining the anti-collision hash algorithm.

[0049] Optionally, after the step of signature verification failure, it further comprises:

[0050] sending a TLS Alert message carrying an error type;

[0051] terminating the QUIC connection and recording the client certificate fingerprint to the audit log.

[0052] By adopting the technical scheme, when the signature verification fails, a three-level response strategy of notifying an error type, forcibly terminating a connection and fingerprint auditing through an encrypted Alert message is adopted, active security defense and post-tracing capability are realized. In addition, the linkage of the audit log and the blacklist mechanism provides infrastructure support for abnormal behavior analysis of the distributed nodes, and the reliability and APT attack resistance of the Internet unified identity authentication system are significantly improved.

[0053] In a third aspect, the application provides a distributed node unified identity authentication system based on a QUIC protocol, which adopts the following technical scheme:

[0054] A distributed node unified identity authentication system based on a QUIC protocol is applied to a client, and the identity authentication system comprises:

[0055] A client identity registration module is configured to register a client domain name identity through a certificate authority, obtain a client certificate, and pre-store a server certificate chain; wherein the client certificate comprises a client domain name identifier and a client DH public key.

[0056] A data packet transmission module is configured to generate a QUIC initial data packet according to a target server domain name identifier and a client certificate and send the QUIC initial data packet to a server; wherein the QUIC initial data packet comprises a target server domain name identifier, a client domain name identifier and a client DH public key.

[0057] A handshake data packet receiving module is configured to receive a QUIC handshake data packet returned by the server; wherein the QUIC handshake data packet comprises a server certificate and a server DH public key.

[0058] A server certificate verification module is configured to verify the legality of the server certificate based on the server certificate chain, and if the server certificate is legal, calculate a pre-master key according to a client DH private key and a server DH public key.

[0059] A session key generation module is 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 through an HKDF algorithm.

[0060] A signature verification message generation module is configured to generate a signature verification message; wherein the signature verification message comprises a digital signature of a handshake data hash value.

[0061] A sending module is configured to send the client certificate and the signature verification message to the server.

[0062] The client data encryption transmission module is configured to encrypt application layer data using the 1-RTT session key in synchronization with the server, and transmit data to the server in the 1-RTT encryption space of the QUIC protocol.

[0063] In a fourth aspect, the application provides a distributed node unified identity authentication system based on a QUIC protocol, which adopts the following technical scheme.

[0064] The distributed node unified identity authentication system based on the QUIC protocol is applied to a server, and comprises:

[0065] The server identity registration module is configured to register a server domain name identity through a certificate authority, obtain a server certificate, and pre-store an authorized client domain name list, wherein the server certificate comprises a server domain name identifier and a server public key.

[0066] The data packet analysis module is configured to receive a QUIC initial data packet sent by a client, and analyze the QUIC initial data packet to obtain a target server domain name identifier and a client domain name identifier.

[0067] The data packet verification module is configured to verify the QUIC initial data packet based on the authorized client domain name list, generate a server DH public key if the verification is passed, and construct a QUIC handshake data packet and send the QUIC handshake data packet to the client, wherein the QUIC handshake data packet comprises the server certificate and the server DH public key.

[0068] The receiving module is configured to receive a client certificate and a signature verification message sent by the client, wherein the signature verification message comprises a digital signature of a handshake data hash value.

[0069] The signature verification module is configured to extract a public key from the client certificate, verify whether the digital signature is consistent with the handshake data hash value, calculate a pre-master key based on a server DH private key and a client DH public key if the signature verification is passed, and derive a 1-RTT session key in synchronization with the client.

[0070] The server data encryption transmission module is configured to encrypt application layer data using the 1-RTT session key in synchronization with the client, and transmit data to the client in the 1-RTT encryption space of the QUIC protocol. BRIEF DESCRIPTION OF DRAWINGS

[0071] Figure 1 FIG. 1 is a first flowchart of an identity authentication method according to an embodiment of the application.

[0072] Figure 2 FIG. 2 is a process demonstration diagram of the unified identity authentication based on the QUIC protocol according to an embodiment of the application.

[0073] Figure 3 is an information interaction demonstration diagram of one of the embodiments of the present application.

[0074] Figure 4 is a second flow diagram of an identity authentication method of one of the embodiments of the present application.

[0075] Figure 5 is a third flow diagram of an identity authentication method of one of the embodiments of the present application.

[0076] Figure 6 is a fourth flow diagram of an identity authentication method of one of the embodiments of the present application.

[0077] Figure 7 is a fifth flow diagram of an identity authentication method of one of the embodiments of the present application. DETAILED DESCRIPTION

[0078] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and should not be used to limit the present application. Figures 1-7

[0079] The embodiments of the present application disclose a distributed node unified identity authentication method based on a QUIC protocol on the client side.

[0080] With reference to Figure 1 , a distributed node unified identity authentication method based on a QUIC protocol is applied to a client, and the identity authentication method comprises the following steps.

[0081] In step S101, the domain name identity of the client is registered through a certificate authority, the client certificate is obtained, and the server certificate chain is pre-stored.

[0082] The client certificate contains the domain name identifier of the client and the Diffie-Hellman (DH) public key of the client.

[0083] Specifically, in the initial stage of the entire identity authentication process, the client first registers its domain name identity through a certificate authority (CA) and obtains the client certificate issued by the CA. The client certificate contains the domain name identifier of the client and the Diffie-Hellman (DH) public key corresponding to the client. Through the issuance of the certificate, the client obtains an identity certificate that can be publicly verified, ensuring the uniqueness and reliability of the identity.

[0084] ​In addition, the pre-stored service end certificate chain is for subsequent identity authentication. When the client receives the certificate returned by the service end, the legality of the service end certificate can be verified through the pre-stored service end certificate chain. The core purpose of this step is to ensure that the client can provide an identity authentication mechanism equal to the service end when connecting, and does not rely on traditional IP addresses or user name and password, but uses digital certificates for identity confirmation, which is crucial for preventing identity impersonation and improving overall network security.

[0085] In step S102, a QUIC initial data packet is generated according to the target service end domain name identifier and the client certificate and sent to the service end; wherein the QUIC initial data packet includes the target service end domain name identifier, the client domain name identifier and the client DH public key;

[0086] In the embodiment of the application, the target service end domain name identifier in the QUIC initial data packet is embedded in the QUIC initial data packet through a TLS extension, and the client domain name identifier is embedded in the QUIC initial data packet through a Transport Parameter parameter.

[0087] Specifically, after the client completes the certificate registration and storage, the client will generate an initial data packet of the QUIC protocol based on the client certificate it holds and the domain name identifier of the target service end, and send it to the service end. This data packet contains the domain name identifier and DH public key of the client. Through the initial data packet, the client not only transmits its own identity information to the service end, but also attaches the necessary information for key exchange, so that subsequent secure communication can be based on the public key exchange of both parties.

[0088] It can be understood that the design of this step takes advantage of the efficiency of the QUIC protocol to ensure that identity information can be exchanged in the first data packet at the beginning of connection, and will not affect the connection delay. In the connection establishment process of QUIC, in addition to the regular transmission control, security verification information can be embedded to ensure that the entire communication link is based on trusted identity from the beginning.

[0089] In step S103, a QUIC handshake data packet returned by the service end is received;

[0090] In step S103, a QUIC handshake data packet returned by the service end is received;

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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:

[0097] The pre-master key is calculated based on the Diffie-Hellman key exchange algorithm. The calculation formula is:

[0098] Pre-master secret key = DH_compute_key(K_ client_priv ,K_ server_pub );

[0099] Among them, K_ client_priv is the client DH private key, K_ server_pub The server DH public key.

[0100] At step S105, a 1-RTT session key is derived based on the pre-master key; wherein the 1-RTT session key is derived from the pre-master key, the client nonce and the server nonce by the HKDF algorithm;

[0101] Wherein, after the client and the server both have the pre-master key, the next step is to derive a 1-RTT session key from the pre-master key, the client and server nonces by the HKDF (HMAC-based Key Derivation Function) algorithm. HKDF is a key derivation function based on HMAC, which generates multiple keys using the pre-master key and additional input data. The 1-RTT session key will be used to encrypt subsequent data transmission.

[0102] Specifically, the derivation process of the 1-RTT session key ensures the randomness and unpredictability of the key, thereby improving the strength of encryption. Through this key derivation method, the client and the server can share a key for subsequent encrypted communication, while preventing the risk of man-in-the-middle attacks and replay attacks. The use of 1-RTT session key greatly improves the security of communication, avoiding the security vulnerabilities easily encountered in traditional communication protocols.

[0103] At step S106, a signature verification message is generated, and the client certificate and the signature verification message are sent to the server; the signature verification message includes a digital signature of the handshake data hash value;

[0104] Wherein, after the derivation of the 1-RTT session key, the client will generate a signature verification message and send it to the server. The signature verification message is the result of digitally signing the hash value of the previous handshake data. The client uses its own private key to sign the hash value, proving that it is a legitimate client and can decrypt and generate the signature verification message.

[0105] After the server receives the signature verification message from the client, it will use the client's public key to verify the signature. If the verification is successful, it confirms the legitimacy of the client's identity, and the entire identity authentication process is completed. Digital signature not only ensures the integrity and non-tamperability of data, but also proves that the data indeed comes from the client holding the private key, thereby enhancing the security of communication.

[0106] At step S107, the 1-RTT session key is used to encrypt application layer data synchronously with the server, and the data is transmitted to the server in the 1-RTT encryption space of the QUIC protocol.

[0107] Wherein, after the identity authentication and key exchange are completed, the client and the server will start to use the shared 1-RTT session key for encrypted communication in the 1-RTT encryption space. In the QUIC protocol, the 1-RTT encryption space is used to protect the security of the transmitted data, ensuring that the data will not be stolen or tampered with in subsequent communication. All data transmitted through the QUIC protocol will be encrypted by the 1-RTT session key, and the confidentiality and integrity of the data will be ensured during the communication process. Through this step, the entire communication process is comprehensively protected, and the data transmission is carried out under the double protection of identity verification and encryption, thereby greatly improving the security of network communication.

[0108] In the above embodiment, during the connection establishment process of the QUIC protocol, the client and the server strictly verify the identity through the certificate and key exchange, ensuring the security of subsequent communication. Compared with the traditional identity authentication method, the present application introduces the digital certificate and key exchange mechanism during the connection establishment, providing higher security and lower communication delay, ensuring the reliability of node identity and the confidentiality of data, and solving the security problems such as identity impersonation and data tampering in the traditional authentication method. At the same time, since the QUIC protocol is implemented in user mode and runs in a more universal transport layer, it has higher scalability and can effectively promote the popularization and application of Internet secure communication.

[0109] Referring to Figure 2 The process demonstration diagram of the unified identity authentication based on the QUIC protocol shown in the present application, wherein CRYPTO is the data frame carrying the TLS 1.3 message in QUIC; CH is the ClientHello message, which contains the client identity, server identity and DH key exchange information; SH is the ServerHello message, which contains the DH key exchange information and upgrades to a more secure Handshake space.

[0110] Referring to Figure 3 The information interaction demonstration diagram is shown, taking bob.user accessing bob.home as an example, to demonstrate the key information interaction, wherein the signature in the certificate verification is obtained by signing the previous TLS message with its own private key. In the present application, only when the node identity is verified, the connection is allowed to be established and the subsequent encrypted data transmission is carried out, thereby ensuring the authenticity of the identity of the communication parties at the source.

[0111] The above process disclosed by the embodiments of the present application is very natural in combination with the QUIC protocol, and can send the client domain name identity to the server in the first data packet of the connection establishment, for preliminary verification of the server. In the initial handshake process of the QUIC protocol, the message exchange of identity authentication is added, but the number of additional round trips is not increased, so that the influence on the connection establishment time is minimized on the premise of ensuring the security of identity authentication, and the communication efficiency is improved. Meanwhile, in the connection migration process of the QUIC protocol, when the network location of the node changes (such as switching from WiFi to mobile data network), the present application can re-verify the opposite node through the encrypted and secure connection migration of the QUIC protocol itself, ensure the continuity and security of the connection, and avoid the problems of identity being impersonated or communication being interrupted due to network switching. On the QUIC protocol, both stream reliable transmission and unreliable datagram transmission can be carried out, and all the transmissions are under the secure encryption transmission after the identity authentication of both parties, so as to meet various scenes.

[0112] On the contrary, TCP cannot put such client identity into the TCP three-way handshake, and can only rely on the TLS handshake after the TCP connection is established to convey messages, which has missed the best client identity verification opportunity. However, TCP can also play a similar role in the subsequent TLS handshake process by adding client_name into the custom TLS extension and placing it in the ClientHello message, which is also the solution of the present application based on the TCP and TLS transmission, but it is far from the elegance of the QUIC protocol. In addition, TCP is a system protocol stack, and TLS is a standard library, so it is difficult to implement the interface for establishing unified identity on them.

[0113] Referring to Figure 4 As an embodiment of step S104, the step of verifying the legality of the server certificate based on the server certificate chain comprises:

[0114] Step S201, parsing the QUIC handshake data packet to extract the server certificate and the server DH public key;

[0115] Specifically, when the client receives the QUIC handshake data packet returned by the server, the internal structure needs to be parsed to extract the key security parameters. The QUIC protocol encapsulates the TLS 1.3 handshake process in a CRYPTO frame, which contains the certificate chain (CERT message) and Diffie-Hellman (DH) public key (transmitted through the ServerHello message) of the server.

[0116] The service end DH public key is used for subsequent calculation of a pre-master secret, and the security thereof depends on the difficulty of solving an elliptic curve discrete logarithm problem (ECDLP), so that a man-in-the-middle cannot derive a private key from an intercepted public key. The service end certificate chain includes a service end entity certificate and an intermediate CA certificate, and forms a complete trust chain for verification by the client.

[0117] In step S202, it is determined whether the CA signature chain of the service end certificate is complete based on a pre-stored service end certificate chain, and whether the domain name identifier of the service end certificate is consistent with the target service end domain name identifier; if yes, the process jumps to step S203; if no, the process jumps to step S204.

[0118] In step S203, it is determined that the service end certificate is legal.

[0119] In step S204, it is determined that the service end certificate is illegal.

[0120] The client starts from the service end entity certificate of the service end certificate chain, and verifies the signatures of issuers level by level: the public key of the upper CA certificate is used to decrypt the digital signature of the current certificate, the hash value (such as SHA-256) of the certificate subject data is calculated, and it is determined whether the decryption result is consistent with the hash value. This process is repeated until the trust anchor (such as the root CA certificate) is linked to the client preset. If any level of signature verification fails or the certificate chain is broken, it is determined to be illegal. In addition, it can also be determined whether the certificate is actively revoked by the CA (such as a private key leakage scenario) through an online certificate status protocol (OCSP) or a certificate revocation list (CRL).

[0121] It should be noted that if the CA signature chain is broken (such as the intermediate CA certificate is missing), the root CA is not trusted, the certificate is revoked, or the domain name is not matched, it indicates that the service end identity is suspicious (may be a phishing site or a man-in-the-middle attack node).

[0122] In the above embodiment, the deep integration of the PKI system and the QUIC protocol stack realizes a strong verification mechanism of the client to the service end identity at the transport layer for the first time. The client dynamically constructs a trust path based on a preset certificate chain by analyzing the cryptographic parameters in the QUIC handshake packet, and combines three mechanisms of CA signature chain verification, revocation status checking, and domain name consistency matching to ensure the non-repudiation and authenticity of the service end identity.

[0123] With reference to Figure 4 As a further embodiment of the identity authentication method, after the step of determining that the service end certificate is illegal, the method further includes:

[0124] In step S301, the QUIC connection establishment process is terminated.

[0125] Specifically, the client immediately sends a CONNECTION_CLOSE frame (error code TLS_CERTIFICATE_UNKNOWN) to force the closure of the QUIC connection, which avoids the subsequent transmission of sensitive data (such as application layer credentials) through an unauthenticated channel. It should be noted that the multiplexing feature of QUIC requires that the connection must be terminated before all streams (Streams) are established, preventing attackers from injecting malicious payloads using 0-RTT data.

[0126] In step S302, an identity authentication failure error code is returned to the client application layer, and the server certificate fingerprint is recorded in the local blacklist.

[0127] Among them, the identity authentication failure error code (such as ERR_QUIC_CERT_AUTH_FAILED) is returned to the application layer, triggering application-level fusing (such as prohibiting retry or switching to a backup node). The fingerprint of the illegal certificate is calculated and stored in the local blacklist. During subsequent connection establishment, the certificate fingerprint blacklist is preferentially compared to achieve local rapid blocking and reduce repeated verification overhead.

[0128] For example, when the client detects that the issuing CA of the server certificate is an unfamiliar institution (such as "Malicious CA") that is not pre-installed, the certificate fingerprint is added to the blacklist. If the same certificate appears again, the client can directly reject the connection without performing the complete verification process.

[0129] In the above embodiments, illegal certificates are immediately blocked, and the fingerprint blacklist strategy is executed to build an active defense barrier, effectively curbing phishing attacks and man-in-the-middle threats.

[0130] Reference Figure 5 As a further embodiment of the identity authentication method, the identity authentication method further comprises:

[0131] In step S401, when transmitting data in the 1-RTT encryption space of the QUIC protocol, if it is detected that the client IP address is changed, the QUIC connection identifier is kept unchanged;

[0132] Among them, the QUIC protocol abstracts the network path through the connection identifier (Connection ID, CID) when dealing with the change of the client IP address. The CID is independent of the underlying IP address and port number. Even if the network path topology changes (such as NAT remapping, mobile network switching), the QUIC protocol stack only needs to keep the CID unchanged to make the communication parties migrate without feeling.

[0133] Specifically, when the client changes IP address (for example, switches from WiFi to mobile network), the traditional TCP connection relies on the five-tuple (source IP, source port, target IP, target port, protocol type) to uniquely identify the connection, while QUIC uses explicitly defined CID as the unique identifier of the connection. After detecting the IP address change (through operating system notification or active probing), the client continues to send data packets using the original CID, and the server associates the connection context (such as encryption state, flow control window) through CID rather than IP address. At this time, the source IP address of the underlying UDP packet has changed, but the QUIC protocol stack identifies that the new and old packets belong to the same logical connection through CID, without the need to rebuild the connection or rehandshake.

[0134] Step S402, multiplexing the 1-RTT session key to encrypt the data of the new IP path;

[0135] Among them, the QUIC protocol realizes the decoupling of key and network path through the key hierarchy architecture, and guarantees the security communication continuity after the connection migration. The key derivation process relies on the random number exchanged during the handshake and the pre-master key, which are independent of the underlying IP path. Therefore, as long as the CID does not change, the derived key is still valid regardless of the change of the network path.

[0136] When the new IP path packet arrives, the QUIC protocol stack decrypts the packet payload (application layer data) using the existing 1-RTT session key, and encrypts the new path packet header (such as Packet Number) using header protection (HP), ensuring that attackers cannot associate the new and old paths by sniffing packets.

[0137] Step S403, sending a connection migration notification frame to the server.

[0138] Specifically, after the client switches to the new IP path, it actively sends a connection migration notification frame containing the PATH_CHALLENGE frame to the server. This frame carries a randomly generated non-repetitive 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 using a shared key such as address_key through HMAC-SHA256), and returns it to the client through the PATH_RESPONSE frame. The client needs to carry this token (embedded in the NEW_TOKEN frame) in the subsequent data packets on the new path, and the server decrypts and verifies the validity of the token (HMAC check, timeliness check). After the token verification is passed, the server confirms the client's control over the new IP path (non-man-in-the-middle hijacking), and formally accepts the new path as a legal communication channel.

[0139] In the above embodiments, the unification of network layer transparent migration and transport layer session continuity is achieved. In the scenario of client IP address change, the persistence of QUIC connection identifier (CID) maintains the continuity of logical session, the reuse of 1-RTT session key avoids the overhead of key renegotiation, and the address verification token mechanism ensures the legitimacy and attack resistance of the new path through the challenge-response model of cryptography.

[0140] The application also discloses a distributed node unified identity authentication system based on the QUIC protocol.

[0141] The application also discloses a distributed node unified identity authentication system based on the QUIC protocol.

[0142] The client identity registration module is configured to register a client domain name identity through a certificate authority, acquire a client certificate, and pre-store a server certificate chain, wherein the client certificate comprises a client domain name identifier and a client DH public key.

[0143] The data packet transmission module is configured to generate a QUIC initial data packet according to a 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 comprises the target server domain name identifier, the client domain name identifier and the client DH public key.

[0144] The handshake data packet receiving module is configured to receive a QUIC handshake data packet returned by the server, wherein the QUIC handshake data packet comprises a server certificate and a server DH public key.

[0145] The server certificate verification module is configured to verify the legitimacy of the server certificate based on the server certificate chain, and if the server certificate is legitimate, calculate a pre-master key according to a client DH private key and the server DH public key.

[0146] The session key generation module is 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 through an HKDF algorithm.

[0147] The signature verification message generation module is configured to generate a signature verification message, wherein the signature verification message comprises a digital signature of a handshake data hash value.

[0148] The sending module is configured to send the client certificate and the signature verification message to the server.

[0149] The client data encryption transmission module is configured to encrypt application layer data by synchronously using the 1-RTT session key with the server, and transmit data to the server in a 1-RTT encryption space of the QUIC protocol.

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

[0151] With reference to Figure 6 The distributed node unified identity authentication method based on the QUIC protocol is applied to a server, and the identity authentication method comprises the following steps:

[0152] In step S501, the domain name identity of the server is registered through a certificate authority, the server certificate is obtained, and a list of authorized client domain names is pre-stored.

[0153] The server certificate comprises a server domain name identifier and a server public key.

[0154] Specifically, the server first registers the domain name identity thereof through a certificate authority (CA) and obtains the server certificate issued by the CA. The server certificate comprises the domain name identifier of the server and the public key of the server. The domain name identifier is the unique identity identifier of the server, and the public key is used for key exchange in encrypted communication. The function of the server certificate is to prove the identity of the server and enable the server to perform secure communication with the client through the public key. The certificate is issued by the CA in the public key infrastructure (PKI) system, and the legality and security thereof are ensured.

[0155] Meanwhile, the server needs to pre-store a list of authorized client domain names, and the list comprises all legal and authorized client domain names. In the identity authentication process, the server verifies whether the client is a trusted access party according to the list. In this way, when the server receives the request of the client, the server can determine whether to allow the connection according to the domain name of the authorized client. In this way, only the client that meets the authorization condition can establish a connection with the server, and the risk of unauthorized access and identity impersonation is avoided.

[0156] In step S502, a QUIC initial data packet sent by the client is received, and the target server domain name identifier and the client domain name identifier are obtained through analysis.

[0157] When the client initiates a connection request, an initial data packet is sent through the QUIC protocol. The data packet comprises the target server domain name identifier and the client domain name identifier. After receiving the initial data packet, the server first analyzes the initial data packet, and extracts the server and client domain name information contained in the initial data packet. The target server domain name identifier is used to ensure that the client indeed initiates the connection to the expected server, and the client domain name identifier is used to identify the identity of the client.

[0158] In this step, the server needs to ensure that the target server domain name identifier is consistent with its own domain name, in order to avoid man-in-the-middle attacks or target errors. The domain name identifier of the client can preliminarily verify whether it is a legitimate user (not a legitimate user is refused to connect), and provides a clue for subsequent identity verification. The server can find whether it is in the authorized list through the identifier, so as to decide whether to continue to establish connection with the client.

[0159] In step S503, the QUIC initial data packet is verified based on the authorized client domain name list, and if the verification is passed, the server DH public key is generated, and the QUIC handshake data packet is constructed and sent to the client; wherein the QUIC handshake data packet includes the server certificate and the server DH public key;

[0160] Wherein, once the server successfully parses and extracts the domain name identifier of the client, the server will verify whether the client has the right to access the current service based on the pre-stored authorized client domain name list. The server confirms whether the client is a legitimate access party by comparing the client domain name identifier with the entries in the authorized list. If the verification is passed, the server allows to continue the connection process, and generates the Diffie-Hellman (DH) public key of the server. The server DH public key is transmitted through the ServerHello message in the QUIC CRYPTO frame.

[0161] Specifically, the process of generating the DH public key is based on the Diffie-Hellman key exchange protocol, which can enable the server and the client to securely generate a shared key without directly exchanging the key. The server encapsulates the generated DH public key and the server certificate into the QUIC handshake data packet, and sends it back to the client. Through the handshake data packet, the server not only transmits its own identity certificate (i.e. the server certificate), but also provides the public key information for subsequent key agreement. The key of this step is to use the server certificate and the DH public key to protect the subsequent key exchange process, and to ensure the security of the communication between the client and the server.

[0162] In step S504, the client certificate and the signature verification message sent by the client are received; wherein the signature verification message includes a digital signature of the handshake data hash value.

[0163] Wherein, after receiving the QUIC handshake data packet returned by the server, the client will respond to the request of the server to send its own client certificate and signature verification message. The client certificate contains the public key of the client and the digital signature issued by the CA to prove the legitimacy of its identity. The client will also generate a signature verification message, which is a digital signature of the hash value 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 indeed has the corresponding private key and has not tampered with the handshake data.

[0164] After receiving the client's certificate and signature verification message, the server will verify the public key in the client certificate to ensure its identity is legitimate. 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.

[0165] 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 passed, 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;

[0166] Wherein, after verifying the client certificate, the server will extract the public key in the client certificate and use the public key to verify the signature verification message sent by the client. By verifying the digital signature, the server ensures the integrity and reliability of the data sent by the client. If the digital signature is consistent with the handshake data hash value, it indicates that the client's identity verification is successful.

[0167] Once the client's identity verification is passed, the server will use its own DH private key and the client-provided DH public key to calculate the pre-master key based on the Diffie-Hellman protocol. The pre-master key is a shared key, and the subsequent session key will be derived based on this pre-master key. Then, the server and the client will use this pre-master key to derive the 1-RTT session key through the HKDF algorithm (HMAC-based Key Derivation Function), ensuring that both parties use the same key for encryption in the subsequent data transmission process. The role of this step is to generate a symmetric encryption key to protect the subsequent communication data.

[0168] Step S506, synchronize with the client to use the 1-RTT session key to encrypt the application layer data, and transmit the data to the client in the 1-RTT encryption space of the QUIC protocol.

[0169] Once the 1-RTT session key is successfully derived, the client and the server can use the key to encrypt the data at the application layer. In the 1-RTT encryption space of the QUIC protocol, all application layer data is encrypted, and only the communication parties can decrypt and access the data. The encryption function of the QUIC protocol not only provides data confidentiality, but also ensures data integrity and non-repudiation during data transmission. This step completes the data protection after identity authentication, ensuring the security of communication data during the entire session process.

[0170] In the above embodiments, in combination with the server certificate, the client certificate, the digital signature, and the Diffie-Hellman key exchange protocol, strong identity authentication and key agreement are achieved in the connection establishment phase of the QUIC protocol. Through the identity authentication process, the server can accurately identify and verify the identity of the client, ensuring that subsequent data transmission in communication is carried out under encryption protection, effectively preventing security problems such as identity impersonation and data theft. Compared with traditional identity authentication mechanisms, the present application provides a more secure, flexible, and low-latency identity authentication scheme, especially suitable for unified identity authentication of large-scale Internet nodes.

[0171] Referring to Figure 7 , as an embodiment of step S, the step of extracting the public key from the client certificate and verifying whether the digital signature is consistent with the handshake data hash value includes:

[0172] Step S601, parsing the public key from the client certificate;

[0173] Step S602, decrypting the digital signature using the client certificate public key to obtain the signature hash value;

[0174] Specifically, in the handshake phase, the client signs the hash value (such as SHA-256 digest) of the handshake data using the private key, and 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) pair. Then, the client certificate public key is used to verify the legality of the signature mathematical relationship. For example, in the case of ECDSA, the signature verification process needs to: reconstruct the temporary point R according to r and s, verify that it satisfies the curve equation; calculate and , verify whether the public key point Q satisfies (G is the curve base point), and if the signature verification is successful, it is determined that the hash value is complete and the signature is authentic.

[0175] Step S603, recalculate the handshake data hash value;

[0176] Step S604, determine whether the signature hash value is equal to the handshake data hash value; if yes, jump to step S605; if no, jump to step S606;

[0177] Step S605, indicate that the signature verification is passed;

[0178] Step S606, if the signature hash value is not equal to the handshake data hash value, indicate that the signature verification fails.

[0179] Exemplarily, if there is a man-in-the-middle tampering (such as modifying the Cipher Suite list of ClientHello) in the handshake process, the hash value signed by the client is generated based on the original data, while the hash value calculated by the server is based on the tampered data, resulting in a failed signature verification.

[0180] In the above embodiment, the deep binding digital signature verification mechanism is combined with the QUIC / TLS protocol stack to build an end-to-end strong verification system of client identity. The server obtains the public key by analyzing the X.509 certificate, verifies the authenticity of the handshake data signature based on the asymmetric encryption mathematical principle, and combines the anti-collision hash algorithm to ensure the data integrity.

[0181] Reference Figure 7 As a further embodiment of the unified identity authentication method, after the step of signature verification failure, further comprising:

[0182] Step S607, send a TLS Alert message carrying an error type;

[0183] Specifically, the server constructs a fatal level Alert message, and the error type is bad_certificate (corresponding to Alert 42 defined in the TLS 1.3 protocol). The Alert message is encrypted using the highest security level key of the current stage (such as HandshakeTraffic Secret), preventing attackers from stealing the error type for protocol reverse analysis.

[0184] Step S608, terminate the QUIC connection and record the client certificate fingerprint to the audit log.

[0185] Specifically, the server immediately sends a CONNECTION_CLOSE frame (error code TLS_HANDSHAKE_FAILED) to close all active streams and release the connection state machine. According to the RFC 9000 specification, the termination process needs to clear the send buffer, discard unacknowledged packets, and start a silence timer (to prevent resource leakage in the half-closed state). The client certificate fingerprint is calculated by a hash digest algorithm (such as SHA-256) and stored in an encrypted audit log. The fingerprint record format includes a timestamp, client IP, certificate serial number, and fingerprint value, which can be used for later correlation analysis (such as investigating multiple attack attempts by the same certificate).

[0186] In the above embodiments, when the signature fails, a three-level response strategy of notifying the error type through an encrypted Alert message, forcibly terminating the connection, and fingerprinting audit is implemented to achieve active security defense and post-tracing capability. In addition, the linkage of the audit log and the blacklist mechanism provides infrastructure support for abnormal behavior analysis of distributed nodes, significantly improving the reliability and APT attack resistance of the Internet unified identity authentication system.

[0187] The embodiments of the present application also disclose a distributed node unified identity authentication system based on a QUIC protocol on the server side.

[0188] A distributed node unified identity authentication system based on a QUIC protocol, applied to a server, the identity authentication system comprising:

[0189] A server identity registration module, configured to register a 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 comprises a server domain name identifier and a server public key;

[0190] A data packet analysis module, configured to receive a QUIC initial data packet sent by a client, and analyze to obtain a target server domain name identifier and a client domain name identifier;

[0191] A data packet verification module, configured to verify the QUIC initial data packet based on the list of authorized client domain names, generate a server DH public key if the verification is passed, and construct a QUIC handshake data packet comprising the server certificate and the server DH public key and send to the client;

[0192] A receiving module, configured to receive a client certificate and a signature verification message sent by the client; the signature verification message comprises a digital signature of a handshake data hash value;

[0193] a signature verification module configured to extract a 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 passed, calculate a pre-master key based on a server DH private key and the client DH public key, and derive a 1-RTT session key synchronized with the client;

[0194] a server data encryption transmission module configured to encrypt application layer data using the 1-RTT session key synchronously with the client, and transmit data to the client in a 1-RTT encryption space of the QUIC protocol.

[0195] In practical applications, the application integrates the QUIC protocol and the PKI certificate system in depth, and constructs a unified identity authentication mechanism for Internet nodes at the transport layer, which fundamentally solves the security defects and ecological fragmentation of traditional identity verification schemes. The core value is reflected in four dimensions:

[0196] 1. At the security level, the scheme relies on the strong verification mechanism of digital signature to realize bidirectional identity authentication of the client and the server at the QUIC connection establishment stage. Compared with the weak verification of application layer username and password (vulnerable to phishing attacks and brute force attacks), the PKI system based on certificate ensures the non-repudiation of identity through asymmetric encryption; at the same time, with the help of the QUIC protocol native end-to-end encryption capability, it directly blocks the risks of data stealing, 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, an attacker cannot fake a client certificate to pass the handshake verification, nor can he decrypt the 1-RTT encrypted space data packet, which significantly reduces the probability of privacy leakage and asset loss.

[0197] 2. At the user experience level, the unified identity system ends the complexity of multi-account management. Users do not need to remember scattered application layer passwords, nor do they need to log in repeatedly to different services - when the device holds the domain name certificate issued by the CA, when accessing any Internet service supporting this standard, the QUIC protocol automatically completes the identity verification in the background (for example, when a user accesses an e-commerce platform, the system realizes a non-intrusive login through the client_name="alice.user" certificate), and this identity can be used uniformly for application layer, which is used for Internet service verification and is associated with the same legal user's identity. This not only reduces the operation interruption caused by password forgetting, but also compresses the average login time from several seconds in traditional schemes to milliseconds of QUIC handshake delay, greatly improving the smoothness of interaction.

[0198] 3. Business operation level, cost reduction and efficiency improvement for service providers. Enterprises do not need to develop and maintain identity authentication modules independently, saving R&D and security audit costs (such as eliminating protocol adaptation overheads such as OAuth, SAML, etc.). The unified certified identity improves the accuracy of cross-business user profiling, supporting personalized service optimization (such as analyzing user behavior chains based on global identity identification). At the same time, the security mechanism embedded in the transmission layer reduces the complaints and after-sales pressure caused by account theft, indirectly reducing the risk of business loss.

[0199] 4. Industry ecology level, protocol-level identity standards break application silos. User certificates become cross-platform access credentials (such as logging into social, payment, and Internet of Things applications with the same *.user domain name), promoting service interconnection and data compliance sharing. This infrastructure-level innovation lays the foundation for fusion scenarios (such as cross-enterprise single sign-on and distributed digital identity interconnection), and promotes the evolution of the Internet from "closed service clusters" to "open and trustworthy ecosystems".

[0200] Based on this, the present application uses the QUIC protocol as a carrier to sink the PKI certificate identity verification to the transmission layer, realizing high security and low friction unified authentication with zero additional delay cost. Its technical effect not only embodies the strengthening of single-point security, but also reconstructs the Internet identity base, systematically optimizing user experience, business efficiency, and industry synergy capabilities.

[0201] The distributed node unified identity authentication system based on the QUIC protocol in the embodiments of the present application can implement any of the above identity authentication methods, and the specific working process of each module in the identity authentication system can refer to the corresponding process in the above method embodiments.

[0202] In several embodiments provided by the present application, it should be understood that the provided method and system can be implemented by other means. For example, the system embodiments described above are only illustrative; for example, the division of a certain module is only a logical function division, and actual implementation can have another division manner, for example, multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0203] It should be noted that in the above embodiments, the description of each embodiment has its emphasis, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0204] The above are the preferred embodiments of the present application, and are not intended to limit the protection scope of the present application. Any feature disclosed in the specification (including the abstract and drawings) can be replaced by other equivalent or similar features, unless specifically described. That is, each feature is only an example of a series of equivalent or similar features, unless specifically described.

Claims

1. A method for unified identity authentication of distributed nodes based on a QUIC protocol, characterized in that, The identity authentication method applied to the client comprises: Registering a client domain name identity through a certificate authority, obtaining a client certificate, and pre-storing a server certificate chain; wherein the client certificate contains a client domain name identifier and a client DH public key; Generating a QUIC initial data packet according to a target server domain name identifier and the client certificate and sending it to the server; wherein the QUIC initial data packet comprises the target server domain name identifier, the client domain name identifier, and the client DH public key; Receiving a QUIC handshake data packet returned by the server; the QUIC handshake data packet comprises a server certificate and a server DH public key; Verifying the legality of the server certificate based on the server certificate chain, and if it is legal, calculating a pre-master key according to a 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, a client random number, and a server random number through an HKDF algorithm; Generating a signature verification message, and sending the client certificate and the signature verification message to the server; the signature verification message comprises a digital signature of a handshake data hash value; Synchronizing with the server to encrypt application layer data using the 1-RTT session key, and transmitting data to the server in a 1-RTT encryption space of the QUIC protocol. 2.The method of claim 1, wherein, The step of verifying the legality of the server certificate based on the server certificate chain comprises: Parsing the QUIC handshake data packet to extract the server certificate and the server DH public key; Verifying whether the CA signature chain of the server certificate is complete based on the pre-stored server certificate chain, and checking whether the domain name identifier of the server certificate is consistent with the target server domain name identifier; if yes, it is determined that the server certificate is legal; if no, it is determined that the server certificate is not legal. 3.The method of claim 2, wherein, After the step of determining that the server certificate is not legal, it further comprises: Terminating the QUIC connection establishment process; Returning an identity authentication failure error code to the client application layer, and recording the server certificate fingerprint to a local blacklist.

4. The method of claim 1, wherein the method is based on a QUIC protocol. The step of calculating the pre-master key according to the client DH private key and the server DH public key comprises: Calculating the pre-master key based on the Diffie-Hellman key exchange algorithm, and the calculation formula is: Pre-master key = DH_compute_key(K client_priv ,K server_pub ); where K client_priv is the client DH private key, K server_pub is the server DH public key.

5. The method of claim 1 to 4, wherein, The identity authentication method further comprises: When transmitting data in the 1-RTT encryption space of the QUIC protocol, if a client IP address change is detected, the QUIC connection identifier is kept unchanged; Multiplexing the 1-RTT session key to encrypt data of a new IP path; Sending a connection migration notification frame to the server.

6. A method for unified identity authentication of distributed nodes based on a QUIC protocol, characterized in that, The identity authentication method applied to the server comprises: Registering a server domain name identity through a certificate authority, obtaining a server certificate, and pre-storing a list of authorized client domain names; wherein the server certificate comprises a server domain name identifier and a server public key; Receiving a QUIC initial data packet sent by the client, and parsing to obtain a target server domain name identifier and a client domain name identifier; Verifying the QUIC initial packet based on the authorized client domain name list, if the verification is passed, generating a server DH public key, and constructing a QUIC handshake packet and sending the QUIC handshake packet to the client; the QUIC handshake packet comprises a server certificate and the server DH public key; Receiving a client certificate and a signature verification message sent by the client; the signature verification message comprises a digital signature of a handshake data hash value; Extracting a public key from the client certificate and verifying whether the digital signature is consistent with the handshake data hash value, if the signature verification is passed, calculating a pre-master key based on a server DH private key and a client DH public key, and deriving a 1-RTT session key synchronized with the client; Synchronously encrypting application layer data using the 1-RTT session key with the client, and transmitting data to the client in a 1-RTT encryption space of the QUIC protocol.

7. The method of claim 6, wherein the method is based on a QUIC protocol. The step of extracting a public key from the client certificate and verifying whether the digital signature is consistent with the handshake data hash value comprises: Parsing the public key from the client certificate; Decrypting the digital signature using the client certificate public key to obtain a signature hash value; Recalculating the handshake data hash value, if the signature hash value is equal to the handshake data hash value, it indicates that the signature verification is passed; If the signature hash value is not equal to the handshake data hash value, it indicates that the signature verification fails. 8.The method of claim 7, wherein, After the step of the signature verification fails, further comprising: Sending a TLS Alert message carrying an error type; Terminating the QUIC connection and recording a client certificate fingerprint to an audit log. 9.A distributed node uniform identity authentication system based on a QUIC protocol, characterized in that, Applied to a client, the identity authentication system comprises: A client identity registration module configured to register a client domain name identity through a certificate authority, obtain a client certificate, and pre-store a server certificate chain; wherein the client certificate comprises a client domain name identifier and a client DH public key; A data packet transmission module configured to generate a QUIC initial packet according to a target server domain name identifier and the client certificate, and send the QUIC initial packet to a server; wherein the QUIC initial packet comprises the target server domain name identifier, the client domain name identifier, and the client DH public key; A handshake data packet receiving module configured to receive a QUIC handshake packet returned by the server; the QUIC handshake packet comprises a server certificate and a server DH public key; A server certificate verification module configured to verify the legality of the server certificate based on the server certificate chain, if the server certificate is legal, calculating a pre-master key according to a 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 through an HKDF algorithm; A signature verification message generation module configured to generate a signature verification message; the signature verification message comprises a digital signature of a handshake data hash value; A sending module configured to send the client certificate and the signature verification message to the server; The client data encryption transmission module is configured to encrypt application layer data using the 1-RTT session key synchronously with the server and transmit data to the server in the 1-RTT encryption space of the QUIC protocol. 10.A system for unified identity authentication of distributed nodes based on a QUIC protocol, characterized in that, The identity authentication system applied to the server comprises: The server identity registration module is configured to register a server domain name identity through a certificate authority, obtain a server certificate, and pre-store an authorized client domain name list; wherein the server certificate comprises a server domain name identifier and a server public key; The data packet analysis module is configured to receive a QUIC initial data packet sent by the client, and analyze the target server domain name identifier and the client domain name identifier; The data packet verification module is configured to verify the QUIC initial data packet based on the authorized client domain name list, generate a server DH public key if the verification is passed, and construct a QUIC handshake data packet and send the QUIC handshake data packet to the client; the QUIC handshake data packet comprises the server certificate and the server DH public key; The receiving module is configured to receive a client certificate and a signature verification message sent by the client; the signature verification message comprises a digital signature of a handshake data hash value; The signature verification module is configured to extract a public key from the client certificate and verify whether the digital signature is consistent with the handshake data hash value, calculate a pre-master key based on a server DH private key and a client DH public key if the signature verification is passed, and derive a 1-RTT session key synchronously with the client; The server data encryption transmission module is configured to encrypt application layer data using the 1-RTT session key synchronously with the client and transmit data to the client in the 1-RTT encryption space of the QUIC protocol.

Images