Disclosure of Invention
Based on the method, the application provides a distributed node unified identity authentication method and a system based on the QUIC protocol.
In a first aspect, the present application provides a distributed node unified identity authentication method based on the QUIC protocol, which adopts the following technical scheme:
a distributed node unified identity authentication method based on QUIC protocol is applied to a client, and the identity authentication method comprises the following steps:
Registering a client domain name identity through a certificate authority, acquiring a client certificate, and pre-storing a server certificate chain, wherein the client certificate comprises a client domain name identifier and a client DH public key;
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, 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 a server, wherein the QUIC handshake data packet comprises a server certificate and a server DH public key;
verifying the validity of the server certificate based on the server certificate chain, and if the validity is legal, calculating a premaster secret key according to a client DH private key and a server DH public key;
Deriving a 1-RTT session key based on the premaster secret key, wherein the 1-RTT session key is derived from the premaster secret key, the client random number and the server random number through HKDF algorithm;
Generating a signature verification message, and sending a client certificate and the signature verification message to a server, wherein the signature verification message comprises a digital signature of a handshake data hash value;
And encrypting the application layer data by using the 1-RTT session key synchronously with the server, and transmitting the data to the server in a 1-RTT encryption space of the QUIC protocol.
By adopting the technical scheme, in the connection establishment process of the QUIC protocol, the client and the server strictly verify identities through certificate and key exchange, so that the safety of subsequent communication is ensured. Compared with the traditional identity authentication method, the method and the device provide higher security and lower communication delay by introducing the digital certificate and the key exchange mechanism, ensure the reliability of the node identity and the confidentiality of data, and solve the security problems of identity impersonation, data tampering and the like in the traditional authentication method. Meanwhile, the QUIC protocol is realized in a user mode, so that the system has higher expansibility, and can effectively promote popularization and application of Internet secure communication.
Optionally, the step of verifying the validity of the server certificate based on the server certificate chain includes:
Analyzing the QUIC handshake data packet, and extracting a server certificate and a server DH public key;
Verifying whether a CA signature chain of the server side certificate is complete based on the prestored server side certificate chain, checking whether a domain name identifier of the server side certificate is consistent with a target server side domain name identifier, if so, determining that the server side certificate is legal, and if not, determining that the server side certificate is illegal.
By adopting the technical scheme, the PKI system and the QUIC protocol stack are deeply integrated, and a strong authentication mechanism of the client to the identity of the server is realized for the first time in a transmission layer. The client dynamically builds a trust path based on a preset certificate chain by analyzing the cryptography parameters in the QUIC handshake packet, and ensures the non-repudiation and authenticity of the identity of the server by combining a triple mechanism of CA signature chain verification, revocation status checking and domain name consistency matching.
Optionally, after the step of determining that the server-side certificate is not legal, the method further includes:
terminating the QUIC connection establishment flow;
and returning an identity authentication failure error code to the client application layer, and recording the certificate fingerprint of the server to a local blacklist.
By adopting the technical scheme, the illegal certificates are blocked in time, and the fingerprint blacklist strategy is executed, so that an active defense barrier is constructed, and the fishing attack and the man-in-the-middle threat are effectively restrained.
Optionally, the step of calculating the premaster secret key according to the client DH private key and the server DH public key includes:
the premaster secret is calculated based on a Diffie-Hellman secret key exchange algorithm, and the calculation formula is as follows:
Premaster secret=dh_computer a_key (k_client_priv,K_server_pub);
wherein, k_client_priv is the client DH private key, and k_server_pub is the server DH public key.
Optionally, the identity authentication method further includes:
When data is transmitted in a 1-RTT encryption space of the QUIC protocol, if the change of the IP address of the client is detected, the QUIC connection identifier is kept unchanged;
multiplexing the 1-RTT session key to encrypt data of a new IP path;
and sending a connection migration notification frame to the server.
By adopting the technical scheme, the unification of transparent migration of the network layer and session persistence of the transmission layer is realized. In the client IP address changing scene, persistence of QUIC Connection Identifier (CID) maintains continuity of logic session, multiplexing 1-RTT session key avoids cost of key renegotiation, and address verification token mechanism ensures validity and anti-attack capability of new path through cryptology challenge-response model.
In a second aspect, the present application provides a distributed node unified identity authentication method based on the QUIC protocol, which adopts the following technical scheme:
A distributed node unified identity authentication method based on QUIC protocol is applied to a server, and the identity authentication method comprises the following steps:
registering a server domain name identity through a certificate authority, acquiring 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;
Receiving a QUIC initial data packet sent by a client, and analyzing to obtain a target server domain name identifier and a client domain name identifier;
Verifying the QUIC initial data packet based on the authorized client domain name list, if the verification is passed, generating a service end DH public key, and constructing a QUIC handshake data packet and sending the QUIC handshake data packet to the client, wherein the QUIC handshake data packet comprises a service end certificate and the service end DH public key;
Receiving a client certificate and a signature verification message sent by a client, wherein 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 premaster secret key based on a server DH private key and a client DH public key, and deriving a 1-RTT session key synchronous with the client;
and encrypting the application layer data by using the 1-RTT session key synchronously with the client, and transmitting the data to the client in the 1-RTT encryption space of the QUIC protocol.
By adopting the technical scheme, the body-building authentication and key negotiation are realized in the connection establishment stage of the QUIC protocol by combining the server side certificate, the client side 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 of subsequent communication is carried out under encryption protection, and effectively prevent the security problems of identity impersonation, data theft and the like. Compared with the traditional identity authentication mechanism, the application provides a safer, flexible and low-delay identity authentication scheme, and is particularly suitable for unified identity authentication of large-scale Internet nodes.
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:
Parsing a public key from the client certificate;
Decrypting the digital signature by using the public key of the client certificate to obtain a signature hash value;
Re-calculating a handshake data hash value, and if the signature hash value is equal to the handshake data hash value, indicating that the signature verification is passed;
And if the signature hash value is not equal to the handshake data hash value, indicating that signature verification fails.
By adopting the technical scheme, the end-to-end strong verification system of the client identity is constructed by deeply binding the digital signature verification mechanism and the QUIC/TLS protocol stack. The server acquires 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 ensures the data integrity by combining with the anti-collision hash algorithm.
Optionally, after the step of signature verification failure, the method further includes:
Sending a TLS Alert message carrying an error type;
The QUIC connection is terminated and the client certificate fingerprint is recorded to the audit log.
By adopting the technical scheme, when the verification fails, the three-level response strategy of encrypting the Alert message to announce the error type, forcibly terminating the connection and conducting fingerprint audit is adopted, so that the active security defense and the post-traceability are realized. In addition, the audit log is linked with the blacklist mechanism, so that infrastructure support is provided for the analysis of abnormal behaviors of the distributed nodes, and the reliability and APT attack resistance of the Internet unified identity authentication system are obviously improved.
In a third aspect, the present application provides a distributed node unified identity authentication system based on the QUIC protocol, which adopts the following technical scheme:
A distributed node unified identity authentication system based on a QUIC protocol, applied to a client, the identity authentication system comprising:
The client identity registration module is used for registering the client domain name identity through a certificate authority, acquiring a client certificate and pre-storing a server certificate chain, wherein the client certificate comprises a client domain name identifier and a client DH public key;
the data packet transmission module is used for generating a QUIC initial data packet according to the target server domain name identifier and the client certificate and transmitting 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;
The device comprises a handshake data packet receiving module, a handshake data packet receiving module and a data processing module, wherein the handshake data packet receiving module is used for receiving a QUIC handshake data packet returned by a server, and the QUIC handshake data packet comprises a server certificate and a server DH public key;
The server side certificate verification module is used for verifying the validity of the server side certificate based on the server side certificate chain, and if the server side certificate chain is legal, the premaster secret key is calculated according to the client side DH private key and the server side DH public key;
the session key generation module is used for deriving a 1-RTT session key based on the premaster key, wherein the 1-RTT session key is derived from the premaster key, the client random number and the server random number through HKDF algorithm;
The signature verification message generation module is used for generating a signature verification message, wherein the signature verification message comprises a digital signature of a handshake data hash value;
the sending module is used for sending the client certificate and the signature verification message to the server;
And the client data encryption transmission module is used for synchronously encrypting the application layer data by using the 1-RTT session key with the server and transmitting the data to the server in the 1-RTT encryption space of the QUIC protocol.
In a fourth aspect, the present application provides a distributed node unified identity authentication system based on the QUIC protocol, which adopts the following technical scheme:
a distributed node unified identity authentication system based on a QUIC protocol, which is applied to a server, the identity authentication system comprising:
The server identity registration module is used for registering the domain name identity of the server through a certificate authority, acquiring 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;
the data packet analysis module is used for receiving the QUIC initial data packet sent by the client and analyzing to obtain the domain name identifier of the target server and the domain name identifier of the client;
The data packet verification module is used for verifying the QUIC initial data packet based on the authorized client domain name list, and generating a server DH public key and constructing a QUIC handshake data packet and sending the QUIC handshake data packet to the client if the verification is passed;
the receiving module is used for receiving a client certificate and a signature verification message sent by a client, wherein the signature verification message comprises a digital signature of a handshake data hash value;
The signature verification module is used for 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 premaster secret key based on a server DH private key and a client DH public key, and deriving a 1-RTT session secret key synchronous with the client;
And the server-side data encryption transmission module is used for synchronously encrypting the application layer data by using the 1-RTT session key with the client-side and transmitting the data to the client-side in the 1-RTT encryption space of the QUIC protocol.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings, fig. 1 to 7 and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
The embodiment of the application discloses a distributed node unified identity authentication method based on a QUIC protocol based on a client side.
Referring to fig. 1, a distributed node unified identity authentication method based on the QUIC protocol is applied to a client, and the identity authentication method includes:
step S101, registering the domain name identity of a client through a certificate authority, acquiring a client certificate, and pre-storing a server certificate chain;
the client certificate comprises a client domain name identifier and a client DH public key;
specifically, in the initial stage of the entire identity authentication process, a client first registers its domain name identity through a Certificate Authority (CA), and obtains a client certificate issued by the CA. The client certificate contains the domain name identifier of the client and the corresponding Diffie-Hellman (DH) public key. Through the issuance of the certificate, the client obtains an identity certificate which can be publicly verified, and the uniqueness and reliability of the identity are ensured.
In addition, the pre-stored server certificate chain is prepared for subsequent authentication work. When the client receives the certificate returned by the server, the validity of the server certificate can be verified through a pre-stored server certificate chain. The core purpose of this step is to ensure that the client can provide an identity authentication mechanism equal to that of the server when connected, and does not rely on the traditional IP address or user name password, but performs identity confirmation through a digital certificate, which is important for preventing identity impersonation and improving the overall network security.
Step S102, generating a QUIC initial data packet according to a target server domain name identifier and a client certificate and sending the QUIC initial data packet to a server, wherein the QUIC initial data packet comprises the target server domain name identifier, the client domain name identifier and a client DH public key;
in the embodiment of the application, the domain name identifier of the target server in the QUIC initial data packet is embedded into the QUIC initial data packet through TLS expansion, and the domain name identifier of the client is embedded into the QUIC initial data packet through Transport Parameter parameters.
Specifically, after the client finishes certificate registration and storage, the client generates an initial data packet of the QUIC protocol based on the client certificate held by the client and the domain name identifier of the target server, and sends the initial data packet to the server. The data packet contains the domain name identifier and DH public key of the client, and through the initial data packet, the client not only transmits own identity information to the server, but also carries necessary information of key exchange, so that subsequent secure communication can be carried out based on the public key exchange of the two parties.
It will be appreciated that the design of this step exploits the high efficiency of the QUIC protocol to ensure that identity information can be exchanged just the first packet in the early phase of the connection and without affecting the delay of the connection. In the connection establishment process of the QUIC, besides the conventional transmission control, security verification information can be embedded, so that the whole communication link is ensured to be established on the basis of a trusted identity from the beginning.
Step S103, 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;
Specifically, when the server receives the initial data packet sent by the client, it responds to a QUIC handshake data packet, which includes the certificate of the server and the DH public key of the server. The core task of the handshake packet is that the server proves its identity by its certificate and provides public key information for subsequent key exchange. The public key in the server certificate is signed by the CA, so that the validity of the identity of the server can be proved.
It will be appreciated that after the client receives the handshake packet of the server, the validity of the server certificate will be verified to ensure that the identity provided by the server is trusted. The verification process typically includes verifying, by a certificate chain, whether the digital certificate of the server is valid, issued by a trusted CA, and whether the identity of the server matches an expected one. The process ensures that the identities of both parties are correctly confirmed, and lays a foundation for subsequent key negotiation and encrypted transmission.
Step S104, verifying the validity of the server certificate based on the server certificate chain, if the server certificate is legal, calculating a premaster secret key according to the client DH private key and the server DH public key;
Specifically, after verifying the validity of the certificate of the server, if the certificate is valid, the client calculates a premaster secret key by using the DH private key of the client and the DH public key of the server. The premaster secret is the basis for two-party key agreement, which provides the core key for subsequent encryption operations. The process relies on the Diffie-Hellman key exchange protocol which allows both parties to generate a shared secret key with their respective public and private keys without the need to transfer the key itself during communication.
In this way, the client and the server are able to securely generate the shared key without directly transmitting the key, which is critical to ensuring the security of subsequent communications. The calculation of the premaster secret key is based on the identity verification of the server, so that only the legally verified server can participate in the secret key exchange process.
In the embodiment of the application, the step of calculating the premaster secret key according to the client DH private key and the server DH public key comprises the following steps:
the premaster secret is calculated based on a Diffie-Hellman secret key exchange algorithm, and the calculation formula is as follows:
Premaster secret=dh_computer a_key (k_client_priv,K_server_pub);
wherein, k_client_priv is the client DH private key, and k_server_pub is the server DH public key.
Step S105, deriving a 1-RTT session key based on the premaster secret key, wherein the 1-RTT session key is derived from the premaster secret key, the client random number and the server random number through HKDF algorithm;
Wherein, after the client and the server both have the premaster secret, the next step is to derive the 1-RTT session key from the premaster secret, the random numbers of the client and the server through HKDF (HMAC-based Key Derivation Function) algorithm. HKDF is an HMAC-based key derivation function that uses a premaster secret and additional input data to generate multiple keys. The 1-RTT session key will be used to encrypt subsequent data transmissions.
In particular, the 1-RTT session key derivation process ensures randomness and unpredictability of the key, thereby increasing the strength of encryption. By means of the key derivation mode, the client and the server can share a key for subsequent encrypted communication, and risks of man-in-the-middle attacks and replay attacks are prevented. The use of the 1-RTT session key also greatly improves the security of communications, avoiding security vulnerabilities that are easily encountered in conventional communication protocols.
Step S106, generating a signature verification message, and sending the client certificate and the signature verification message to the server, wherein the signature verification message comprises a digital signature of a handshake data hash value;
After the 1-RTT session key derivation is completed, the client generates a signature verification message, and sends the signature verification message 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 own private key, proving itself to be a legitimate client, and being able to decrypt and generate the signature verification message.
And after receiving the signature verification message of the client, the server verifies the signature by using the public key of the client. If the verification is passed, the identity of the client is confirmed to be legal, and the whole identity authentication flow is completed. The digital signature not only can ensure the integrity and the non-tamper property of the data, but also can prove that the data is truly sourced from the client terminal with the private key, thereby enhancing the security of communication.
Step S107, the application layer data is encrypted by using the 1-RTT session key synchronously with the server, and the data is transmitted to the server in the 1-RTT encryption space of the QUIC protocol.
After the identity authentication and the key exchange are completed, the client and the server start to carry out encrypted communication in the 1-RTT encrypted space by using the 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 data is not stolen or tampered with in subsequent communications. All data transmitted through the QUIC protocol are encrypted by the 1-RTT session key, and confidentiality and integrity of the data are guaranteed in the communication process. Through the step, the whole communication process is comprehensively protected, and the data transmission is performed under the dual guarantee of identity authentication and encryption, so that the safety of network communication is greatly improved.
In the above embodiment, during the connection establishment process of the QUIC protocol, the client and the server strictly verify the identity through certificate and key exchange, so as to ensure the security of subsequent communication. Compared with the traditional identity authentication method, the application provides higher security and lower communication delay by introducing the digital certificate and the key exchange mechanism when the connection is established, ensures the reliability of the node identity and the confidentiality of data, and solves the security problems of identity impersonation, data tampering and the like in the traditional authentication method. Meanwhile, the QUIC protocol is realized in a user mode and operates in a more general transmission layer, so that the QUIC protocol has higher expansibility and can effectively promote popularization and application of Internet secure communication.
Referring to fig. 2, a process illustration of unified identity authentication based on the QUIC protocol according to the present application is shown, wherein CRYPTO is a data frame carrying TLS 1.3 messages in QUIC, CH is a ClientHello message with client identity, server identity and DH key exchange information, SH is a ServerHello message, and DH key exchange information is included, and the process is updated to a safer secure classified Handshake space.
Referring to fig. 3, an information interaction diagram is shown, taking bob.user access bob.home as an example, to demonstrate key information interaction therein, wherein the signature in the certificate verification is obtained by signing the previous TLS message with its own private key. In the application, only after the authentication of the node passes, the connection is allowed to be established and the subsequent encrypted data transmission is carried out, so that the authenticity of the identities of the two communication parties is ensured at the source.
The above-mentioned process disclosed in the embodiment of the application is very natural in combination with the QUIC protocol, and can send the domain name identity of the client to the server in the first data packet for establishing connection, so as to perform preliminary verification on the server. In the initial handshake process of the QUIC protocol, the message exchange of the identity authentication is increased, but no additional round trip communication times are increased, so that the influence on the connection establishment time is reduced to the greatest extent on the premise of ensuring the security of the identity authentication, and the communication efficiency is improved. Meanwhile, in the connection migration process of the QUIC protocol, when the network position of the node changes (such as switching from WiFi to a mobile data network), the application can re-verify the other node by the encryption security connection migration of the QUIC protocol, ensure the continuity and the security of the connection, and avoid the problems of fraudulent use of identity or communication interruption and the like caused by network switching. On the QUIC protocol, the streaming reliable transmission and unreliable datagram transmission can be carried out, and various scenes are satisfied under the safe encryption transmission after the identity authentication of both parties.
In contrast to TCP, such a client identity cannot be plugged into the TCP three-way handshake, but only depends on the TLS handshake after the TCP connection is established to convey the message, and the best client identity verification opportunity has been missed. However, TCP can also perform a similar function by adding a client_name to a custom TLS extension in the subsequent TLS handshake process, and the solution of the present application based on TLS transmission over TCP is not very elegant, and in addition, TCP is a system protocol stack, TLS is a standard library, and it is difficult to implement by changing an interface for establishing a uniform identity on the TLS.
Referring to fig. 4, as an embodiment of step S104, the step of verifying the validity of the server certificate based on the server certificate chain includes:
step S201, analyzing QUIC handshake data packet, extracting a server certificate and a server DH public key;
Specifically, when the client receives the quitc handshake packet returned by the server, the internal structure of the quitc handshake packet needs to be parsed to extract the key security parameters. The QUIC protocol encapsulates the TLS1.3 handshake procedure in a CRYPTO frame that contains the certificate chain of the server (CERT message) and the Diffie-Hellman (DH) public key (delivered by ServerHello message).
The server DH public key is used for calculating a premaster secret key (Pre-MASTER SECRET) later, the security of the server DH public key depends on the difficulty of Elliptic Curve Discrete Logarithm Problem (ECDLP), and the fact that a middle person cannot derive a private key through the intercepted public key is ensured. The server side certificate chain comprises a server side entity certificate and an intermediate CA certificate, and forms a complete trust chain for verification of the client side.
Step S202, verifying whether a CA signature chain of a server side certificate is complete based on a prestored server side certificate chain, and checking whether a domain name identifier of the server side certificate is consistent with a target server side domain name identifier, if so, jumping to step S203, and if not, jumping to step S204;
Step S203, determining that the certificate of the server is legal;
step S204, determining that the server certificate is illegal.
The client starts from a server entity certificate of a server certificate chain, verifies the signature of an issuer step by step, namely, decrypts the digital signature of the current certificate by using a public key of an upper CA certificate, calculates a hash value (such as SHA-256) of certificate main body data, and compares whether a decryption result is consistent with the hash value. This process is repeated until a preset Trust Anchor (Trust Anchor) of the client (e.g., root CA certificate) is linked. If any one of the primary signature verification fails or the certificate chain breaks, the illegal judgment is carried out. In addition, whether the certificate is actively revoked by the CA (e.g. private key leakage scenario) can also be queried through Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL)
It should be noted that if the CA signature chain breaks (such as the middle CA certificate is missing), the root CA is not trusted, the certificate is revoked or the domain name is not matched, the identity of the server is suspicious (possibly a phishing site or a middle man attack node).
In the above embodiment, the deep integration of the PKI system and the quit protocol stack first achieves a strong authentication mechanism of the client to the server identity in the transport layer. The client dynamically builds a trust path based on a preset certificate chain by analyzing the cryptography parameters in the QUIC handshake packet, and ensures the non-repudiation and authenticity of the identity of the server by combining a triple mechanism of CA signature chain verification, revocation status checking and domain name consistency matching.
Referring to fig. 4, as a further embodiment of the identity authentication method, after the step of determining that the server certificate is not legal, the method further includes:
step S301, terminating the QUIC connection establishment flow;
specifically, the client immediately sends a connect_close frame (error code tls_notification_unlock) forcing the quitc CONNECTION to CLOSE, which avoids subsequent sensitive data (e.g., application layer credentials) from being transmitted over the unauthorized channel. The multiplexing nature of QUIC requires that the connection must be terminated before all streams (streams) are established, preventing an attacker from injecting malicious payload with 0-RTT data.
Step S302, an identity authentication failure error code is returned to the client application layer, and a server certificate fingerprint is recorded to a local blacklist.
Wherein an authentication failure error code (e.g., err_quench_cert_auth_failed) is returned to the application layer, triggering application level fusing (e.g., disabling retries or switching standby nodes). And calculating the fingerprint of the illegal certificate, and storing the fingerprint in a local blacklist. When the subsequent connection is established, the certificate fingerprint blacklist is preferentially compared, so that local quick blocking is realized, and the repeated verification expenditure is reduced.
Illustratively, when the client detects that the issuing CA of the server certificate is an unprepared stranger (e.g., "Malicious CA"), the certificate fingerprint is blacklisted. If the same certificate appears again later, the client can directly reject the connection without executing a complete verification process.
In the embodiment, the illegal certificates are blocked in time, and the fingerprint blacklist strategy is executed, so that an active defense barrier is constructed, and the phishing attack and the man-in-the-middle threat are effectively restrained.
Referring to fig. 5, as a further embodiment of the identity authentication method, the identity authentication method further includes:
Step S401, when data is transmitted in the 1-RTT encryption space of the QUIC protocol, if the change of the IP address of the client is detected, the QUIC connection identifier is kept unchanged;
Wherein the qic protocol abstracts the network path by Connection ID (CID) when coping with client IP address change. The CID is independent of the underlying IP address and port number, and even if the network path undergoes topology changes (e.g., NAT remapping, mobile network switching), the QUIC protocol stack only needs to keep the CID unchanged to enable both parties to migrate without sense.
Specifically, when a client makes an IP address change (e.g., switches from WiFi to mobile network), the traditional TCP connection relies on the five-tuple (source IP, source port, destination IP, destination port, protocol type) to uniquely identify the connection, while the qic uses the explicitly defined CID as the unique identifier of the connection. After detecting the change of the IP address (notified by the operating system or actively detected), the client continues to send the data packet by using the original CID, and the server associates the connection context (such as encryption state and flow control window) by CID instead of the IP address. At this time, the source IP address of the underlying UDP packet has been changed, but the qic protocol stack recognizes that the new and old packets belong to the same logical connection through CID, and there is no need to reestablish connection or re-handshake.
Step S402, multiplexing 1-RTT session key to encrypt data of new IP path;
the QUIC protocol realizes decoupling of the key and the network path through the key layering architecture, and guarantees the safety communication persistence after connection migration. The key derivation process relies on the random number and premaster secret exchanged during the handshake, both independent of the underlying IP path. Thus, regardless of the network path change, the derived key is still valid as long as the CID is unchanged.
When a new IP path Packet arrives, the quit protocol stack uses the existing 1-RTT session key to decrypt the Packet payload (application layer data), and performs Header Protection (HP) encryption on the header (e.g., packet Number) of the new path Packet, so as to ensure that an attacker cannot associate the new path with the old path by sniffing the Packet.
Step S403, a connection migration notification frame is sent to the server.
Specifically, after the client switches to the new IP PATH, the client actively sends a connection migration notification frame including a path_challenge frame to the server. The frame carries a randomly generated non-repeated value (8-byte random number) which triggers the server to perform path verification. After receiving the path_challenge frame, the server generates an address verification token (encrypted Nonce and timestamp, signed by HMAC-SHA256 using a shared key such as address_key), and returns to the client through the path_response frame. The client needs to carry the TOKEN (embedded with NEW TOKEN frame) in the subsequent data packet of the NEW path, and the server decrypts the validity (HMAC check, timeliness check) of the verification TOKEN. After the token passes the verification, the server confirms the control right (hijack of non-intermediate person) of the client to the new IP path, and formally accepts the new path as a legal communication channel.
In the above embodiment, unification of transparent migration of the network layer and session persistence of the transport layer is achieved, persistence of the QUIC Connection Identifier (CID) maintains continuity of the logical session in the client IP address change scene, multiplexing of the 1-RTT session key avoids the overhead of key renegotiation, and the address verification token mechanism ensures validity and anti-attack capability of the new path through the cryptology challenge-response model.
The embodiment of the application also discloses a distributed node unified identity authentication system based on the QUIC protocol based on the client side.
A distributed node unified identity authentication system based on QUIC protocol is applied to a client, and the identity authentication system comprises:
the client identity registration module is used for registering the domain name identity of the client through a certificate authority, acquiring a client certificate and pre-storing a server certificate chain, wherein the client certificate comprises a client domain name identifier and a client DH public key;
The data packet transmission module is used for 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, wherein the QUIC initial data packet comprises the target server domain name identifier, the client domain name identifier and the client DH public key;
the device comprises a handshake data packet receiving module, a handshake data packet receiving module and a data processing module, wherein the handshake data packet receiving module is used for receiving a QUIC handshake data packet returned by a server side, and the QUIC handshake data packet comprises a server side certificate and a server side DH public key;
The server side certificate verification module is used for verifying the validity of the server side certificate based on the server side certificate chain, and if the server side certificate chain is legal, the premaster secret key is calculated according to the client side DH private key and the server side DH public key;
The session key generation module is used for deriving a 1-RTT session key based on the premaster key, wherein the 1-RTT session key is derived from the premaster key, the client random number and the server random number through HKDF algorithm;
The signature verification message generation module is used for generating a signature verification message, wherein the signature verification message comprises a digital signature of a handshake data hash value;
the sending module is used for sending the client certificate and the signature verification message to the server;
And the client data encryption transmission module is used for encrypting the application layer data by using the 1-RTT session key synchronously with the server and transmitting the data to the server in the 1-RTT encryption space of the QUIC protocol.
The embodiment of the application also discloses a distributed node unified identity authentication method based on the QUIC protocol based on the server side.
Referring to fig. 6, a distributed node unified identity authentication method based on the QUIC protocol is applied to a server, and the identity authentication method includes:
Step S501, registering the domain name identity of a server through a certificate authority, acquiring a server certificate, and pre-storing an authorized client domain name list;
The server side certificate comprises a server side domain name identifier and a server side public key;
specifically, the server first registers its domain name identity through a Certificate Authority (CA), and obtains a server certificate issued by the CA. The server certificate contains 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 encrypting the key exchange process in communication. The function of the server certificate is to prove the identity of the server and enable secure communication with the client via its public key. This certificate is issued by a CA in the Public Key Infrastructure (PKI) architecture, ensuring its legitimacy and security.
Meanwhile, the server needs to prestore a list of authorized client domain names, and the list contains all legal authorized client domain names. During the authentication process, the server verifies whether the client is a trusted access party according to the list. In this way, the server can determine whether to allow connection according to the domain name of the authorized client when receiving the request of the client. Therefore, only the client conforming to the authorization condition can establish connection with the server, and the risks of unauthorized access and identity impersonation are avoided.
Step S502, receiving a QUIC initial data packet sent by a client, and analyzing to obtain a target server domain name identifier and a client domain name identifier;
When the client initiates a connection request, an initial data packet is sent through the QUIC protocol. The data packet includes a target server domain name identifier and a client domain name identifier. After receiving the initial data packet, the server first analyzes the initial data packet and extracts the domain name information of the server and the client contained in the initial data packet. The target server domain name identifier is used to ensure that the client is actually initiating the connection to the intended server, and the client domain name identifier is used to identify the identity of the client.
In this step, the server needs to ensure that the target server domain name identifier is consistent with its own domain name, so as to avoid man-in-the-middle attacks or target errors. The domain name identifier of the client can initially verify whether the user is legal or not (connection is refused if the user is not legal), and provide clues for subsequent identity verification, and the server can search whether the user is in the authorized list or not through the identifier, so that whether connection with the client is continuously established is determined.
Step S503, verifying the QUIC initial data packet based on the authorized client domain name list, if the verification is passed, generating a service end DH public key, and constructing a QUIC handshake data packet and sending the QUIC handshake data packet to the client, wherein the QUIC handshake data packet comprises a service end certificate and the service end DH public key;
Wherein, once the server end successfully resolves and extracts the domain name identification of the client end, the server end will verify whether the client end 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 identification with entries in the authorization list. If the verification is passed, the server side allows the connection process to be continued, and generates a Diffie-Hellman (DH) public key of the server side, and the DH public key of the server side is transmitted through a ServerHello message in a QUIC CRYPTO frame.
Specifically, the process of generating the DH public key is based on the Diffie-Hellman key exchange protocol, which enables the server and the client to securely generate a shared key without directly exchanging the key. And the server encapsulates the generated DH public key and the certificate of the server into a QUIC handshake data packet and sends the QUIC handshake data packet back to the client. Through the handshake data packet, the server not only delivers its own identity credentials (i.e., server certificates), but also provides public key information for subsequent key negotiations. The key of the step is to protect the subsequent key exchange process by using the certificate of the server side and the DH public key, so as to ensure the communication security between the client side and the server side.
Step S504, receiving a client certificate and a signature verification message sent by a client, wherein the signature verification message comprises a digital signature of a handshake data hash value;
After receiving the QUIC handshake data packet returned by the server, the client responds to the request of the server and sends the client certificate and signature verification message. The client certificate contains the public key of the client and a digital signature issued by the CA for proving that the identity of the client is legal. The client also generates a signature verification message, the content of which is to digitally sign the hash value of the previous handshake data. The signature verification message is generated after the client encrypts the handshake data by using the private key thereof, and proves that the client really has the corresponding private key and does not tamper with the handshake data.
After receiving the certificate and signature verification message of the client, the server verifies the public key in the client certificate to ensure that the identity of the client certificate is legal. By verifying the digital signature, the server can ensure that the handshake data is not tampered in the transmission process, thereby confirming the legitimacy of the identity of the client.
Step S505, extracting public key from client certificate and verifying whether the digital signature is consistent with the hash value of handshake data, if the signature verification is passed, calculating premaster secret key based on server DH private key and client DH public key, and deriving 1-RTT session secret key synchronous with client;
After verifying the client certificate, the server side extracts the public key from the client certificate, and uses 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 hash value of the handshake data, the authentication of the client is successful.
Once the client authentication passes, the server calculates the premaster secret based on Diffie-Hellman protocol using its DH private key and the DH public key provided by the client. The premaster secret is a shared secret on which subsequent session keys are derived. The server and client then derive the 1-RTT session key using this premaster secret via the HKDF algorithm (HMAC-based Key Derivation Function), ensuring that both parties use the same key for encryption during subsequent data transmissions. The effect of this step is to generate a symmetric encryption key for protecting subsequent communication data.
Step S506, the application layer data is encrypted by using the 1-RTT session key synchronously with the client, and the data is transmitted to the client in the 1-RTT encryption space of the QUIC protocol.
Wherein, once the 1-RTT session key is successfully derived, the client and the server can use the key to encrypt the data of the application layer. In the 1-RTT encryption space of the QUIC protocol, all application layer data is encrypted and it is guaranteed that only both parties can decrypt and access the data. The encryption function of the QUIC protocol not only provides confidentiality of the data, but also ensures integrity and non-tamper-ability during data transmission. The step completes the data protection after the identity authentication, and ensures that the safety of communication data is not threatened in the whole session process.
In the above embodiment, the body-building authentication and key negotiation are implemented in the connection establishment phase of the QUIC protocol in combination with the server side certificate, the client side 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 of subsequent communication is carried out under encryption protection, and effectively prevent the security problems of identity impersonation, data theft and the like. Compared with the traditional identity authentication mechanism, the application provides a safer, flexible and low-delay identity authentication scheme, and is particularly suitable for unified identity authentication of large-scale Internet nodes.
Referring to fig. 7, as an embodiment 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, resolving a public key from a client certificate;
step S602, decrypting the digital signature by using the public key of the client certificate to obtain a signature hash value;
Specifically, in the handshake phase, the client signs the hash value (e.g., SHA-256 digest) of the handshake data using the private key, the signature algorithm is consistent with the certificate public key algorithm, e.g., ECDSA signature process includes randomly generating a temporary key pair (k, R), and calculating the x-coordinate of elliptic curve point R. Calculation of(D is the client private key) and the final signature is (r, s) doublet. Then, the public key of the client certificate is used for verifying the validity of the mathematical relationship of the signature, taking ECDSA as an example, the signing verification process needs to reconstruct a temporary point R according to R and s, verify that the temporary point R meets a curve equation, calculateAnd (3) withVerifying whether public key point Q satisfiesAnd (G is a curve base point), and judging the integrity of the Hash value and the authenticity of the signature after the signature verification is successful.
Step S603, recalculating the hash value of the handshake data;
step S604, judging whether the signature hash value is equal to the handshake data hash value, if so, jumping to step S605, otherwise, jumping to step S606;
step S605, representing that the signature verification passes;
in step S606, if the signature hash value is not equal to the handshake data hash value, it indicates that the signature verification fails.
For example, if there is middle man tampering (e.g. modifying the Cipher Suite list of ClientHello) in the handshake process, the hash value of the client signature is generated based on the original data, and the server calculates the tampered hash value, which results in failure of signature verification.
In the above embodiment, the deep binding digital signature verification mechanism and the QUIC/TLS protocol stack construct an end-to-end strong verification system for the identity of the client. The server acquires 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 ensures the data integrity by combining with the anti-collision hash algorithm.
Referring to fig. 7, as a further embodiment of the unified identity authentication method, after the step of signature verification failure, the method further includes:
Step S607, a TLS Alert message is sent to carry an error type;
Specifically, the server constructs fatal-level Alert message with an error type of bad_notification (corresponding to Alert 42 defined by TLS 1.3 protocol). The Alert message is encrypted (e.g., HANDSHAKE TRAFFIC SECRET) using the highest security level key of the current stage, preventing an attacker from stealing the error type for protocol reverse analysis.
Step S608, terminate the QUIC connection and record the client certificate fingerprint to the audit log.
Specifically, the server immediately sends a connection_close frame (error code tls_ HANDSHAKE _failed), CLOSEs all active streamand releases the CONNECTION state machine. According to the RFC 9000 specification, the termination procedure requires that the transmit buffer be emptied, unacknowledged packets be discarded, and a quiet period timer be started (to prevent half-closed state resources from leaking). Client certificate fingerprints are computed by a hash digest algorithm (e.g., SHA-256) and stored in a cryptographic audit log. The fingerprint record format includes a timestamp, a client IP, a certificate serial number, and a fingerprint value for later association analysis (e.g., multiple attack attempts to check the same certificate).
In the embodiment, when the verification fails, the three-level response strategy of encrypting the Alert message to announce the error type, forcibly terminating the connection and conducting fingerprint audit is adopted to realize the active security defense and the post-traceability. In addition, the audit log is linked with the blacklist mechanism, so that infrastructure support is provided for the analysis of abnormal behaviors of the distributed nodes, and the reliability and APT attack resistance of the Internet unified identity authentication system are obviously improved.
The embodiment of the application also discloses a distributed node unified identity authentication system based on the QUIC protocol based on the server side.
A distributed node unified identity authentication system based on QUIC protocol is applied to a server, and the identity authentication system comprises:
The server identity registration module is used for registering the domain name identity of the server through a certificate authority, acquiring 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;
the data packet analysis module is used for receiving the QUIC initial data packet sent by the client and analyzing to obtain the domain name identifier of the target server and the domain name identifier of the client;
the data packet verification module is used for verifying the QUIC initial data packet based on the authorized client domain name list, and if the verification is passed, generating a service end DH public key and constructing a QUIC handshake data packet to be sent to the client;
the receiving module is used for receiving a client certificate and a signature verification message sent by a client, wherein the signature verification message comprises a digital signature of a handshake data hash value;
The signature verification module is used for extracting a public key from the client certificate and verifying whether the digital signature is consistent with the hash value of the handshake data, if the signature verification is passed, calculating a premaster secret key based on a server DH private key and the client DH public key, and deriving a 1-RTT session secret key synchronous with the client;
And the server-side data encryption transmission module is used for encrypting the application layer data by using the 1-RTT session key synchronously with the client-side and transmitting the data to the client-side in the 1-RTT encryption space of the QUIC protocol.
In practical application, the application constructs a unified identity authentication mechanism of the internet node on a transmission layer by deeply integrating the QUIC protocol and the PKI certificate system, thereby fundamentally solving the problems of safety defect and ecological rupture of the traditional identity authentication scheme. The core value of the method is represented in four dimensions:
1. In the security layer, the scheme relies on a strong verification mechanism of a digital signature to realize bidirectional identity authentication of a client and a server in the QUIC connection establishment stage. Compared with weak verification (easy to be attacked by phishing and violent cracking) of the user name and password of an application layer, the PKI system based on the certificate ensures the non-repudiation of the identity through asymmetric encryption, and meanwhile, the risks of data theft, man-in-the-middle hijacking, IP counterfeiting and the like are directly blocked at a transmission layer by means of the original end-to-end encryption capability of the QUIC protocol, so that the full-link protection from identity authentication to data transmission is formed. For example, an attacker cannot forge a client certificate to pass handshake verification, and cannot decrypt a data packet of the 1-RTT encryption space, so that privacy disclosure and asset loss probability are remarkably reduced.
2. The unified identity system terminates the complexity of multi-account management at the user experience level. The user does not need to memorize the scattered application layer passwords and repeatedly log in different services, namely when the equipment has a domain name certificate issued by CA and accesses any internet service supporting the standard, the QUIC protocol automatically completes identity verification in the background (for example, when the user accesses the electric Shang Ping stations, the system realizes noninductive login through a client_name= "alice. User" certificate), and the identity can be uniformly used by the application layer and is used for internet service verification and is associated with the identity of the same legal user. The method not only reduces the operation interruption caused by forgetting the password of the user, but also compresses the average login time from a few seconds of the traditional scheme to the QUIC handshake millisecond delay, thereby greatly improving the interaction fluency.
3. And the business operation level reduces the cost and increases the efficiency for the service provider. The enterprise does not need to independently develop and maintain an identity authentication module, so that the research, development and security audit cost is saved (such as protocol adaptation cost of OAuth, SAML and the like is saved), the uniform certification identity enables the portrait accuracy of cross-service users to be improved, and personalized service optimization is supported (such as user behavior chain analysis based on global identity). Meanwhile, the embedded security mechanism in the transmission layer reduces customer complaints and after-sales pressure caused by account theft, and indirectly reduces the risk of service loss.
4. The industrial ecological level and the protocol level identity standard break the application island. The user credentials become cross-platform pass credentials (e.g., login to social, payment, internet of things applications with the same user domain name), facilitating service interconnection and data compliance sharing. The infrastructure-level innovation lays a foundation for a fusion scene (such as cross-enterprise single sign-on and distributed digital identity interconnection) and promotes the evolution of the Internet from a closed service cluster to an open trusted ecology.
Based on the method, the QUIC protocol is used as a carrier, the PKI certificate authentication is sunk to the transmission layer, and the high-safety and low-friction unified authentication is realized at zero extra delay cost. The method has the technical effects that the method is not only embodied as single-point security reinforcement, but also systematically optimizes user experience, business efficiency and industry collaborative capability by reconstructing an internet identity base.
The distributed node unified identity authentication system based on the QUIC protocol can realize any one of the identity authentication methods, and the specific working process of each module in the identity authentication system can refer to the corresponding process in the method embodiment.
In several embodiments provided by the present application, it should be understood that the methods and systems provided may be implemented in other ways. For example, the system embodiments described above are merely illustrative, e.g., the partitioning of a module is merely a logical function partitioning, and there may be additional partitioning in actual implementation, e.g., multiple modules may be combined or integrated into another system, or some features may be omitted, or not performed.
In the foregoing embodiments, the descriptions of the embodiments are focused on, and for those portions of one embodiment that are not described in detail, reference may be made to the related descriptions of other embodiments.
The foregoing description of the preferred embodiments of the application is not intended to limit the scope of the application in any way, including the abstract and drawings, in which case any feature disclosed in this specification (including abstract and drawings) may be replaced by alternative features serving the same, equivalent purpose, unless expressly stated otherwise. That is, each feature is one example only of a generic series of equivalent or similar features, unless expressly stated otherwise.