A wireguard handshake method and system for enhancing anti-DoS capability and completing backward security

Abstract

The application discloses a WireGuard handshake method and system with enhanced anti-DoS capability and completed backward security, and relates to the technical field of communication network security. The method is that an initiator generates a group signature by using a group member private key on a signature original text containing a group identifier and an inner core field plaintext, and sends the group identifier and the group signature after embedding them in the plaintext header of an InitHello message; a responder receives and extracts the group identifier and the group signature, obtains a pre-configured group public key and a group revocation list, and calls a group signature verification algorithm to perform validity verification; if the verification is passed and the signer is not in the revocation list, the inner core field is parsed to perform handshake processing, and in the handshake process, the group public key is added to the key chain identity binding hash and the group signature is embedded in the hash chain; if the verification fails or the signer is in the revocation list, the handshake request packet is discarded and the handshake is terminated, so that the calculation type DoS attack surface can be fundamentally eliminated, and the backward security is completed through the cryptographic binding of the group public key and the group signature.

Description

Technical Field

[0001] This invention belongs to the field of communication network security technology, and particularly relates to a post-quantum secure virtual private network (VPN) handshake scheme based on the WireGuard protocol. Specifically, it relates to a WireGuard handshake method and system that enhances anti-DoS capability and completes backward security. Background Technology

[0002] In the open internet environment, security issues such as data eavesdropping, privacy leaks, and access restrictions persist. Virtual Private Networks (VPNs) have become a core technical solution to these problems by building encrypted tunnels between terminals and target networks. Their core value lies in three dimensions: data security protection in public network environments, privacy protection of users' real IP addresses and online behaviors, and cross-domain access support in compliant scenarios.

[0003] Among various VPN protocols, WireGuard stands out with its "simplicity equals security" design philosophy: its minimalist codebase significantly reduces the risk of security vulnerabilities, while advanced encryption primitives achieve a performance balance between high security and low latency / high throughput; its lightweight configuration and management process adapts to scenarios such as seamless roaming of mobile devices and deployment of low-power devices, with resource consumption far lower than traditional VPN protocols. Currently, WireGuard has been widely adopted by mainstream commercial VPN services, becoming a leading VPN solution in areas such as home remote access, enterprise mobile office, edge computing networking, and secure IoT access.

[0004] The rapid development of quantum computers poses a fundamental security threat to existing classical asymmetric encryption algorithms (such as RSA and ECC) based on the difficulties of large number factorization and discrete logarithms. Shor's quantum algorithm can break these algorithms in polynomial time, and these algorithms are the core foundation of the current internet security system. Once classical encryption algorithms are broken by quantum computers, information security in critical infrastructure sectors such as military communications, financial transactions, healthcare, energy, and transportation will face comprehensive risks. Therefore, the post-quantum migration of cryptographic systems is extremely urgent and of great national strategic significance. Post-quantum cryptography is a core technology for resisting quantum computing attacks and can ensure the security of encryption algorithms in a quantum computing environment. It has already been applied in multiple fields such as finance, government affairs, defense, and the Internet of Things. However, the large-scale deployment of post-quantum cryptography still faces challenges: the continuous iteration of quantum computing technology poses a continuous test to the security of post-quantum algorithms; the post-quantum migration of traditional protocols involves high technical transformation costs and compatibility risks; and the standardization and engineering implementation of related algorithms and protocols still need continuous improvement.

[0005] Focusing on post-quantum migration optimization of the WireGuard protocol, existing research papers, "A Tale of Two Worlds, a Formal Story of WireGuard Hybridization" and "Revisiting PQ WireGuard: A Comprehensive Security Analysis With a New Design Using Reinforced KEMs FullVersion," have proposed Hybrid-WireGuard protocol schemes. The former addresses the real-world risk of key leakage by deeply integrating authentication and key exchange processes to complete a hybrid protocol design; the latter optimizes the scheme by decoupling authentication and key exchange based on the ideal key distribution assumption. These two papers lay a core foundation for WireGuard's post-quantum migration, but still have some unresolved security flaws, specifically in the following two aspects (I) and (II).

[0006] (a) Backward security defects Backward security (also known as future security) is one of the core security attributes of communication protocols. Strictly defined, it means that when one party's long-term private key is leaked, even if an attacker obtains that key, they cannot decrypt the content of any new sessions established after the key leak, thus ensuring the continued security of future sessions. In contrast, forward security protects the security of historical sessions completed before the long-term private key was leaked, while backward security is the core security barrier for future sessions. For post-quantum VPN protocols, it is a key design feature to resist the persistent security risks caused by long-term key leaks.

[0007] Existing Hybrid-WireGuard and improved PQ-WireGuard schemes have not conducted systematic research and design on backward security of the protocols, resulting in serious backward security flaws in the protocols under quantum computing scenarios, specifically manifested as follows: (1) Strong long-term key dependency in key derivation: In the existing protocol's session key derivation chain, the long-term static private key of the responder (server) is the core root trust anchor, running through the entire process of KEM decapsulation, shared secret generation, and key chain initialization; when the responder's long-term post-quantum static private key and classical DH static private key are leaked, the attacker can use the leaked private key to perform legitimate KEM decapsulation and DH shared secret calculation on all newly initiated handshake sessions, completely restore the entire key derivation chain, and obtain the final session key; (2) Security boundary failure in quantum scenarios: The backward security guarantee of the existing scheme can only be established in classical computing scenarios and depends on the computational security of asymmetric algorithms; however, in quantum computing scenarios, attackers can use leaked long-term private keys to forge legitimate handshake messages in batches and hijack newly established sessions, rendering the original post-quantum security design of the protocol completely ineffective, which contradicts the core design goal of the protocol for post-quantum migration. (3) Lack of security isolation mechanism after key leakage: The existing solution does not design a session security isolation mechanism after long-term private key leakage. Once the long-term private key is leaked, all subsequent new sessions are not secure and cannot be restored through temporary key updates, session renegotiation, etc., and lacks emergency security capabilities to deal with key leakage events.

[0008] (ii) Core vulnerabilities of Denial of Service (DoS) attacks The DoS attack vulnerability of the existing Hybrid-WireGuard protocol stems from an execution order adjustment made by the protocol to achieve anonymity. This alters the native WireGuard's pre-security verification logic, resulting in a severely delayed verification of the handshake entry point's legitimacy, creating a high-overhead attack surface that can be exploited by attackers at low cost. This flaw has become a core bottleneck restricting Hybrid-WireGuard from theoretical verification to large-scale commercial deployment, as analyzed in detail below: (1) Core cause - Anonymity optimization leads to a complete reversal of the security verification logic sequence; The core anti-DoS design of the original WireGuard protocol lies in building a handshake processing sequence of "verification first, computation later": After receiving the InitHello handshake packet, the responder first derives the MAC verification key based on the static public keys of both parties to perform a pre-verification of message integrity. Only after the verification passes will subsequent high-computing-cost operations such as DH shared secret computation and AEAD decryption be performed; This design prevents attackers from constructing data packets that pass verification without possessing legitimate keys. All forged packets will be directly discarded at the entry point, and the server only needs to pay a very low-cost hash computation overhead, thus resisting computational DoS attacks from the root; In the Hybrid-WireGuard protocol design, in order to completely solve the problem of identity anonymity leakage, the R&D team replaced the MAC verification key derived from the public static public key with a key derived from the public static public key. The pre-shared key psk derivation between the communicating parties, while fundamentally preventing attackers from revealing their identity by enumerating public keys and achieving complete anonymity protection, also directly leads to the inability of MAC verification as a pre-step in the handshake process. The responder must first decrypt the static encrypted field in the InitHello message to obtain the initiator's identity identifier before matching the corresponding psk from the local database and completing the MAC verification. To decrypt the static field, the responder must sequentially complete a series of computationally expensive cryptographic operations, including classical DH shared secret computation, symmetric decryption of encrypted KEM ciphertext, post-quantum KEM decapsulation, key chain initialization and derivation, and AEAD decryption. This ultimately results in a fatal timing defect of "full-scale high-overhead computation first, followed by legitimacy verification," which is the core root cause of the Hybrid-WireGuard protocol's DoS attack surface. (2) Attack Feasibility - The attack threshold is extremely low, and the cost of attack and defense computing power is severely unbalanced. The computational DoS attack against Hybrid-WireGuard has an extremely low implementation threshold and extremely strong destructive power: the attacker does not need to have any private information. He only needs to construct forged InitHello handshake packets that meet the format requirements in batches according to the publicly available protocol format specifications. He can send them to the target server in batches through automated scripts, proxy pools or botnets. The technical threshold and implementation cost of the attack are almost negligible. From the perspective of computing power cost, there is an extreme asymmetry between the attack and defense: the responder needs to complete one X25519 curve DH scalar multiplication, one ChaCha20 symmetric decryption, one ML-KEM or Classic McEliece post-quantum KEM decapsulation, multiple HKDF key derivations and one ChaCha20 Poly1305 to process a single forged InitHello message. AEAD decryption takes an average of about 1.84ms to process a single message; while an attacker only needs to fill in random numbers and concatenate the basic format to construct a forged data packet, taking less than 1 microsecond to construct a single data packet. The difference in computing power cost between attack and defense exceeds 1800 times. Taking a typical 8-core x86 server as an example, its maximum capacity to process InitHello messages per second is about 4300. An attacker only needs an ordinary home computer to send more than 5000 forged data packets per second, completely consuming all the CPU computing power of the server. With the support of a botnet, attackers can easily send hundreds of thousands of forged packets per second, directly causing the server to be completely paralyzed and unable to respond to any legitimate user handshake requests. (3) The native protection mechanism is completely ineffective and lacks closed-loop processing capability; Hybrid-WireGuard only natively inherits WireGuard's CookieReply mechanism, which can only mitigate reflection and traffic-based DoS attacks, and is completely ineffective against computational DoS attacks in this scenario; the triggering of the CookieReply mechanism still requires the responder to receive and parse the data packet and complete the basic format verification, while the attacker's forged packet fully conforms to the protocol format requirements and will directly enter the complete handshake processing flow. This mechanism cannot intercept forged packets at the entry point, nor can it reduce the computing power consumption of the server; at the same time, traditional network layer protection methods such as IP blocking and traffic rate limiting cannot cope with distributed DDoS attacks based on botnets: attackers can bypass blocking by constantly changing IP addresses, while traffic rate limiting will simultaneously affect the access of legitimate users, making it impossible to achieve the desired results. The core protection objective is to "intercept malicious traffic and allow legitimate traffic." However, the native protocol also has two major derivative flaws: First, the attack source is untraceable. The native handshake message does not contain any verifiable initiator identity. Even if the server detects a DoS attack, it cannot locate the specific attack node from the malicious data packets, making it impossible to distinguish between legitimate users and malicious nodes. Therefore, it can only implement indiscriminate traffic control measures. Second, it lacks dynamic permission control capabilities. The native protocol's node permission management relies entirely on the update of static key pairs and pre-shared keys (PSKs). Once a malicious node is detected, the corresponding static key and PSK must be fully updated. This not only involves complex procedures and extremely high maintenance costs but also leads to the interruption of normal node operations. It cannot achieve real-time permission blocking of malicious nodes without affecting legitimate users, making it completely unsuitable for handling high-frequency attacks in large-scale deployment scenarios. (4) The risk of DoS attacks is further amplified in the post-quantum scenario; Hybrid-WireGuard, as a VPN protocol for the post-quantum era, is designed to resist the risk of encryption cracking brought about by quantum computing. However, the DoS protection defects of the original architecture will be further aggravated in the post-quantum scenario; On the one hand, the encapsulation operation of the post-quantum KEM algorithm has a much higher computational cost and memory usage than the classic X25519. In scenarios such as embedded systems, edge computing, and low-power IoT devices, the DH algorithm faces extremely limited computing resources. Even a small-scale packet forgery attack can completely paralyze the device. On the other hand, the parallel capabilities of quantum computing allow attackers to exponentially increase the efficiency of constructing forged data packets in batches and launching large-scale DDoS attacks. Meanwhile, the computational overhead of post-quantum cryptography on the server side cannot be reduced in sync, further exacerbating the imbalance between the attack and defense. Existing post-quantum cryptography research focuses primarily on the algorithm's resistance to quantum cracking, with insufficient attention paid to the DoS design of post-quantum protocols. This has resulted in significant security weaknesses in the anti-DoS capabilities of post-quantum security protocols like Hybrid-WireGuard, which is seriously contrary to the post-quantum security design goals of the protocols.

[0009] The two aforementioned defects severely restrict the development of hybrid systems. The process of moving from theoretical research to large-scale commercial deployment of the WireGuard protocol urgently requires the development of a method that can preserve the anonymity of the native protocol while maintaining the identity of the user. This new handshake scheme fundamentally enhances anti-DoS capabilities and supplements backward security, while leveraging the low latency advantages of RTT and the hybrid security boundary. Summary of the Invention

[0010] The purpose of this invention is to provide a WireGuard handshake method and system that enhances DoS protection and improves backward security, in order to solve the problems of existing Hybrid... The WireGuard protocol suffers from vulnerability to computational DoS attacks due to its delayed verification timing, and lacks backward security due to the possibility of future session keys being deduced caused by the leakage of long-term static private keys.

[0011] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, a WireGuard handshake method is provided to enhance DoS resistance and improve backward security. This method is executed interactively by the initiating and responding devices, including: The initiating device uses the private key of the group member obtained during the group registration phase to perform a signature generation operation on the plaintext containing the inner core field to be sent and the signature plaintext containing the group identifier, thereby generating a group signature. The initiating device embeds the group identifier and the group signature into the plaintext header of an InitHello message based on the Hybrid-WireGuard protocol and carrying the inner core field, so as to assemble a handshake request packet. The initiating device sends the handshake request packet to the responding device; The responding device receives the handshake request packet and extracts the group identifier and the group signature from the handshake request packet; The responding device obtains the pre-configured group public key and group revocation list based on the group identifier; The responding device invokes a group signature verification algorithm and, in conjunction with the group public key and the group revocation list, verifies the validity of the group signature. If the validity verification of the group signature passes and the signer who generated the group signature is not in the group revocation list, the inner core field is parsed to perform a handshake process based on the Hybrid-WireGuard protocol and with the initiating device. During the handshake process, the group public key is added to the identity binding hash of the key chain, and the group signature is embedded in the hash chain. If the validity verification of the group signature fails or the signer who generated the group signature exists in the group revocation list, the handshake request packet is discarded, and the handshake is terminated.

[0012] Based on the above-described invention, a method is provided that can preserve the anonymity of the original protocol, 1 A new handshake scheme enhances DoS resistance and supplements backward security while leveraging the low latency advantages of RTT and a hybrid security boundary. This scheme is executed interactively by the initiating and responding devices, including: the initiating device using the group member's private key to generate a group signature from the plaintext signature containing the group identifier and inner core field; and embedding the group identifier and group signature into a Hybrid-based... The WireGuard protocol's InitHello message is sent after the plaintext header; the responding device receives and extracts the group identifier and group signature, obtains the pre-configured group public key and group revocation list, and calls the group signature verification algorithm for validity verification; if the verification passes and the signer is not on the revocation list, the inner core field is parsed to perform handshake processing, and during the handshake process, the group public key is added to the key chain identity binding hash and the group signature is embedded in the hash chain; if the verification fails or the signer is on the revocation list, the handshake request packet is discarded and the handshake is terminated. This invention reconstructs the handshake sequence through pre-signature verification, fundamentally eliminating the computational DoS attack surface, while supplementing backward security through the cryptographic binding of the group public key and group signature, and fully preserving the anonymity of the original protocol. RTT low latency and hybrid security boundary.

[0013] Secondly, a WireGuard handshake method that enhances DoS protection and improves backward security is provided, executed by the responding device, including: Receive a handshake request packet sent by the initiating device, wherein the handshake request packet is an InitHello message based on the Hybrid-WireGuard protocol and carrying a group identifier field, a group signature field and an inner core field; Extract the group identifier and group signature from the handshake request packet; Obtain the pre-configured group public key and group revocation list based on the group identifier; The group signature verification algorithm is invoked, and the validity of the group signature is verified by combining the group public key and the group revocation list. If the validity verification of the group signature passes and the signer who generated the group signature is not in the group revocation list, then the inner core field is parsed to perform a handshake process based on the Hybrid-WireGuard protocol and with the initiating device. During the handshake process, the group public key is added to the identity binding hash of the key chain, and the group signature is embedded in the hash chain. If the validity verification of the group signature fails or the signer who generated the group signature exists in the group revocation list, the handshake request packet is discarded and the handshake is terminated.

[0014] In one possible design, the group signature employs a lattice-based post-quantum group signature based on the CRS model, and is generated and verified as follows: The initiating device uses the private key of the group member obtained during the group registration phase to perform a signature generation operation on the plaintext containing the inner core field and the signature plaintext of the group identifier to generate the group signature; The process by which the responding device verifies the group signature using the group public key does not require verification of the signer's identity information, so as to preserve the anonymity of the Hybrid-WireGuard protocol while achieving pre-validation through the validity verification.

[0015] In one possible design, the group public key is added to the identity binding hash of the key chain, including: In the nine-step key chain derivation process of the Hybrid-WireGuard protocol, the hash value of the group public key is used as part of the input parameter of the key derivation function in the fourth step, so that the calculation of the fourth key chain value depends on the group public key. The subsequent key derivation steps in the nine-step key chain derivation process are based on the fourth key chain value. Finally, a session key for encrypting data transmission is derived based on the ninth key chain value. This ensures that even if the classic static private key and the post-quantum static private key of the responder's device are leaked, an attacker who does not possess the legitimate group member's private key will still be unable to restore the key derivation chain to obtain the session key.

[0016] In one possible design, the group signature is embedded in the hash chain, including: In the nine-step hash chain derivation process of the Hybrid-WireGuard protocol, the group signature is used as part of the input parameter of the seventh-step hash function, so that the calculation of the seventh hash value depends on the context information of the group signature and the current handshake session. The subsequent hash generation steps in the nine-step hash chain derivation process are based on the seventh hash value, ultimately generating the final value of the responder's hash chain. This final value is used to compare with the final value of the initiator's hash chain obtained by the initiator based on the nine-step hash chain derivation process after being carried to the initiator's device by the RespHello message sent by the responder device. This verifies whether the group signature has been tampered with or replayed. If tampering or replay is detected, the initiator's device terminates the handshake and discards the derived session key.

[0017] In one possible design, the group identifier field and the group signature field are located before the message type field of the InitHello message, wherein the group identifier field is 4 bytes long, the group signature field is no more than 1000 bytes long, and the total length of the InitHello message is no more than 1270 bytes to meet the IPv6 network minimum MTU limit of 1280 bytes.

[0018] In one possible design, when the responder device is configured as a group administrator device and holds a group management private key, the method further includes: When an abnormal handshake behavior is detected, the group signature opening algorithm is invoked. The group management private key is used as input to extract and generate the identity public key corresponding to the group member with the signature from the group signature, so as to realize the attack source tracing. The identity public key is the hash value of the classic static public key and the post-quantum static public key of the initiating device.

[0019] In one possible design, when the group revocation list records the public keys of group members whose membership has been revoked, the validity of the group signature is verified, including: Determine whether the identity public key corresponding to the group member who generated the group signature exists in the group revocation list. If it exists, determine that the validity verification of the group signature has failed. The identity public key is the hash value of the classic static public key and the post-quantum static public key of the initiating device.

[0020] Thirdly, a WireGuard handshake system that enhances anti-DoS capability and completes backward security is provided, which is suitable for deployment in the responder's device and includes a handshake request receiving unit, a group information extraction unit, a configuration information acquisition unit, a signature validity verification unit, a verification success response unit, and a verification failure response unit. The handshake request receiving unit is used to receive a handshake request packet sent by the initiating device, wherein the handshake request packet is an InitHello message based on the Hybrid-WireGuard protocol and carrying a group identifier field, a group signature field and an inner core field. The group information extraction unit is communicatively connected to the handshake request receiving unit and is used to extract the group identifier and group signature from the handshake request packet. The configuration information acquisition unit is communicatively connected to the group information extraction unit and is used to obtain a pre-configured group public key and group revocation list based on the group identifier. The signature validity verification unit is communicatively connected to the group information extraction unit and the configuration information acquisition unit, respectively, and is used to call the group signature verification algorithm and, in conjunction with the group public key and the group revocation list, to verify the validity of the group signature. The verification success response unit is communicatively connected to the signature validity verification unit. When the validity verification of the group signature passes and the signer who generated the group signature is not in the group revocation list, it parses the inner core field to perform a handshake process based on the Hybrid-WireGuard protocol and with the initiating device. During the handshake process, it adds the group public key to the identity binding hash of the key chain and embeds the group signature into the hash chain. The verification failure response unit is communicatively connected to the signature validity verification unit, and is used to discard the handshake request packet and terminate the handshake when the validity verification of the group signature fails or the signer who generated the group signature exists in the group revocation list.

[0021] Fourthly, a WireGuard handshake system that enhances DoS protection and improves backward security is provided, including a first device and a second device; The first device is configured to perform method steps performed by the initiating device in the WireGuard handshake method as described in the first aspect or any possible design in the first aspect; The second device is configured to perform method steps performed by the responding device in the WireGuard handshake method as described in the first aspect or any possible design in the first aspect.

[0022] The beneficial effects of the above scheme are: (1) This invention provides a method that can preserve the anonymity of the original protocol, 1 A new handshake scheme enhances DoS resistance and supplements backward security while leveraging the low latency advantages of RTT and a hybrid security boundary. This scheme is executed interactively by the initiating and responding devices, including: the initiating device using the group member's private key to generate a group signature from the plaintext signature containing the group identifier and inner core field; and embedding the group identifier and group signature into a Hybrid-based... The WireGuard protocol's InitHello message is sent after the plaintext header; the responding device receives and extracts the group identifier and group signature, obtains the pre-configured group public key and group revocation list, and calls the group signature verification algorithm for validity verification; if the verification passes and the signer is not on the revocation list, the inner core field is parsed to perform handshake processing, and during the handshake process, the group public key is added to the key chain identity binding hash and the group signature is embedded in the hash chain; if the verification fails or the signer is on the revocation list, the handshake request packet is discarded and the handshake is terminated. This invention reconstructs the handshake sequence through pre-signature verification, fundamentally eliminating the computational DoS attack surface, while supplementing backward security through the cryptographic binding of the group public key and group signature, and fully preserving the anonymity of the original protocol. RTT low latency and hybrid security boundary; (2) It can fundamentally eliminate the computational denial-of-service attack surface and achieve the reversal of attack and defense computing power. That is, by embedding the group identifier and group signature into the plaintext header of the InitHello message, the handshake processing sequence is reconstructed, so that the responding device can extract and execute the group signature validity verification first without touching the encrypted part of the inner core field. Since the group signature verification only relies on lightweight hash operation and lattice mathematical operation, the verification time of a single message is controlled at the microsecond level, which is only one-thousandth of the time spent on post-quantum KEM decapsulation and Diffie-Hellman calculation. The responding device will only execute the handshake verification if the group signature verification is successful and the signer is not on the group revocation list. The Hybrid-WireGuard protocol employs high-overhead cryptographic operations such as classical Diffie-Hellman shared secret computation, post-quantum KEM decapsulation, key chain initialization, and AEAD decryption. If verification fails or the signer has been revoked, the handshake request packet is discarded without triggering any subsequent high-overhead computations. As a result, even if an attacker sends a batch of forged handshake packets conforming to the format specifications, the responding device only needs to pay a very low computational cost to complete the pre-interception, completely blocking the path of forged packets consuming CPU resources. This reverses the cost gap between attack and defense from a thousand-fold difference in the original protocol to a situation where the defender has the advantage, fundamentally eliminating the computational denial-of-service attack surface inherent in the Hybrid-WireGuard protocol. (3) It can completely supplement backward security and achieve secure isolation of future session keys after the long-term static private key is leaked. That is, it constructs an identity trust root independent of the long-term communication key through the group signature system, and irreversibly embeds the group public key as identity binding information during the key chain derivation process. Specifically, in the fourth step of the nine-step key chain derivation, the hash value of the group public key is used as the input parameter of the key derivation function KDF, so that the calculation of the fourth key chain value depends on the group public key. The derivation of subsequent key chain values ​​and the generation of the final session key are all based on the chain value containing this binding relationship. Thus, even if the response The classical static private key and the post-quantum static private key of the device are leaked. The attacker cannot pass the pre-signature verification because he does not have the private key of the legitimate group member. Moreover, because the key derivation chain contains the group public key binding relationship that the attacker cannot know, it is still impossible to restore the complete key derivation chain to obtain the session key for the newly established session after the leakage event. This achieves cryptographic isolation between the long-term communication private key and the future session key, completely fills the back security missing in the existing Hybrid-WireGuard protocol, and effectively resists the continuous security risks caused by long-term key leakage in quantum computing scenarios. (4) It can take into account both the verification of the legitimacy of the identity of the initiator and the protection of the anonymity of the initiator. That is, the group signature algorithm adopted has the anonymity of the signer and the non-linkability. The group signature generated by the initiator device using the private key of the group member can only prove that it belongs to the legitimate group member. During the verification process, the responder device only needs to publish the group public key to complete the validity verification. It does not need to obtain the specific identity information of the signer, and it is impossible to deduce the identity of the specific initiator device from the group signature, nor can it link different group signatures of the same member. Therefore, while achieving strong identity legitimacy access through the verification of the group signature, it fully retains the original identity anonymity design of the Hybrid-WireGuard protocol, solves the core contradiction in the existing scheme that "the verification of the identity will inevitably lead to the leakage of identity", and achieves a two-way balance between anonymity and identity authentication. (5) It can realize a closed-loop full lifecycle handling of attack source traceability and malicious node dynamic revocation. That is, by utilizing the traceability characteristics of the group signature algorithm, when the responding device holds the group management private key as the group administrator, it can call the group signature opening algorithm after detecting abnormal handshake behavior, and accurately extract the identity public key of the corresponding group member from the captured malicious group signature, so as to locate and collect evidence of the distributed denial-of-service attack source. At the same time, the responding device maintains the group revocation list and checks whether the signer exists in the revocation list during the group signature verification stage. If it exists, it directly determines that the verification fails and discards the handshake packet. The group administrator only needs to add the identity public key of the malicious member to the revocation list and synchronize it to each responding device. Without modifying the pre-shared key and the node static communication key pair, and without interrupting the normal business of legitimate users, it can realize real-time handshake blocking and permission banning of malicious nodes. The above mechanisms jointly construct a closed-loop full lifecycle handling of "attack detection - identity traceability - permission banning", which solves the operation and maintenance pain points of the original protocol attack source being untraceable and lacking dynamic permission control. (6) It is fully compatible with the native protocol architecture and hybrid security boundary, and can achieve smooth upgrades. That is, all modifications are incremental. Only the plaintext header of the group identifier and group signature fields of the InitHello message of the Hybrid-WireGuard protocol is extended. The RespHello message structure and generation logic are completely consistent with the native protocol without any modifications. The core key exchange logic of the native protocol, the hybrid security architecture of classical Diffie-Hellman and post-quantum KEM, the nine-step derivation process of key chain and hash chain, the ChaCha20Poly1305 AEAD encryption mechanism, and the anonymity repair design for KEM ciphertext are all completely retained without any changes. Therefore, the original hybrid security guarantee (that is, "as long as either classical DH or post-quantum KEM primitive is secure, the whole protocol is secure"), the ability to resist unknown key sharing attacks, forward security and strong key confidentiality and other core security attributes of the protocol are all fully inherited. The formal security proof of the native protocol can be fully reused without re-evaluation of security, which greatly reduces the technical transformation cost and compatibility risk of post-quantum migration. (7) It can meet the MTU limit of IPv6 network and has the advantage of plug-in deployment. That is, the length of the group identifier field embedded incrementally in the InitHello message is only 4 bytes, the length of the group signature after compression is no more than 1000 bytes, and the total length of the modified InitHello message is strictly controlled within 1270 bytes, which meets the limit of the minimum MTU of IPv6 network of 1280 bytes. There is no need to perform IP layer fragmentation transmission, and it is fully compatible with the UDP transmission model of the existing WireGuard protocol. At the same time, the selected lattice basis group signature algorithm is based on the error-learning difficulty problem on the lattice and shares the same security root with the ML-KEM post-quantum algorithm used by the native Hybrid-WireGuard protocol. It can be directly reused from the existing post-quantum cryptography library without introducing additional cryptographic dependencies. The group signature module adopts an independent plug-in design, which can be flexibly turned on or off according to business needs. After being turned on, it is bidirectionally compatible with the native protocol. There is no need to carry out large-scale transformation of the existing deployment architecture. The engineering integration cost is extremely low. It is suitable for large-scale commercial deployment scenarios such as home remote access, enterprise mobile office, edge computing networking and IoT security access, which is convenient for practical application and promotion. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1This is a flowchart illustrating the WireGuard handshake method for enhancing DoS protection and providing backward security, as provided in the embodiments of this application.

[0025] Figure 2 This is a schematic diagram of the structure of the first WireGuard handshake system that enhances anti-DoS capability and completes backward security, as provided in the embodiments of this application.

[0026] Figure 3 This is a schematic diagram of the second type of WireGuard handshake system that enhances anti-DoS capabilities and completes backward security, provided in an embodiment of this application. Detailed Implementation

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the accompanying drawings is only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these embodiments without creative effort. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0028] It should be understood that although the terms "first" and "second", etc., may be used herein to describe various objects, these objects should not be limited by these terms. These terms are only used to distinguish one object from another. For example, the first object may be referred to as the second object, and similarly, the second object may be referred to as the first object, without departing from the scope of the exemplary embodiments of the invention.

[0029] It should be understood that the term "and / or" that may appear in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, or A and B exist simultaneously. Another example is A, B and / or C, which can mean that any one of A, B, and C or any combination thereof exists. The term " / and" that may appear in this document describes another relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone or A and B exist simultaneously. In addition, the character " / " that may appear in this document generally indicates that the related objects before and after it are in an "or" relationship.

[0030] Example 1 like Figure 1As shown, the WireGuard handshake method for enhancing DoS protection and improving backward security provided in this embodiment can be executed interactively by the initiating device and the responding device, but is not limited to. The initiating device refers to a terminal device that wishes to establish an encrypted tunnel with the responding device to access network resources. Examples include, but are not limited to, personal computers, laptops, smartphones, tablets, IoT terminal devices, edge computing nodes, or home gateway devices with WireGuard client software deployed. The initiating device has pre-completed the group registration process, possesses a valid group identifier (gID), group public key (gpk), and group member private key (gsk_i), and is configured with its own classic static key pair (sc_i'). The responding device refers to a device deployed on the network side to respond to the handshake request of the initiating device and provide encrypted tunnel access services. For example, it may be, but is not limited to, a VPN server with WireGuard server software deployed, an enterprise access gateway, a cloud host instance, an edge computing service node, or a security gateway device. The responding device has completed the group creation process in advance, holds the group management private key (gmsk), the group public key (gpk), a complete list of group members and a group revocation list (R_list), and is configured with its own classic static key pair (sc_r', Sc_r) and post-quantum static key pair (spq_r', Spq_r).

[0031] Before implementation, a pre-configuration phase of group identities must be completed. This phase is an offline pre-configuration process before the handshake, with no online interaction overhead. It specifically includes group creation, group member registration, and group member revocation mechanisms. (1) Group creation: The device acting as the group administrator (usually the responder device) calls the group signature key generation algorithm to generate the group public key gpk and the group management private key gmsk; a unique group identifier gID is assigned, and the group member list and revocation list R_list are initialized; the administrator registers his own long-term identity public key lpk_r=HASH(Sc_r||Spq_r) as the first group member and generates the corresponding administrator member private key gsk_r; gID and gpk are made public to the whole network, and gmsk, member list and R_list are stored securely. (2) Group member registration: The legitimate initiating device generates its own classic DH (Diffie-Hellman key exchange protocol) static key pair (sc_i', Sc_i) and post-quantum KEM (Key Encapsulation Mechanism) static key pair (spq_i', Spq_i), calculates the member's long-term identity public key lpk_i=HASH(Sc_i||Spq_i), and submits lpk_i to the administrator for identity authentication; after the administrator's authentication is successful, the group signature member key generation algorithm is called to generate a group member private key gsk_i bound to lpk_i for the initiating device; the administrator adds lpk_i to the group member list and distributes gID, gpk, and gsk_i to the initiating device through a secure channel; the initiating device securely stores gID, gpk, and gsk_i locally to complete the group registration; (3) Group member revocation mechanism: The administrator confirms the member to be revoked (lpk_revoke), adds it to the group revocation list (R_list), and updates it to all handshake service nodes simultaneously; after the revocation is completed, the group signature generated by the member will be directly rejected at the handshake entry point without modifying the member's static communication key and pre-shared key, and will not affect the normal business of other legitimate users; The aforementioned group identity pre-configuration stage provides a trust foundation for group signature verification in the subsequent handshake process, and at the same time constructs an identity trust root independent of the long-term communication key, which is a core pre-process for realizing anti-DoS capability and backward security.

[0032] like Figure 1 As shown, the WireGuard handshake method includes, but is not limited to, the following stages S1 to S6.

[0033] S1. The initiating device uses the private key of the group member obtained during the group registration phase to perform a signature generation operation on the plaintext containing the inner core field to be sent and the signature plaintext containing the group identifier, thereby generating a group signature.

[0034] In step S1, the initiating device first generates a temporary key pair for this handshake. Specifically, referring to the Hybrid-WireGuard native protocol specification, the initiating device generates a 32-byte random session identifier sid_i, initializes protocol public constant tags lbl1, lbl2, and lbl3, and generates a classic temporary DH key pair (ec_i', Ec_i) and a post-quantum temporary KEM key pair (epq_i', Epq_i). Then, using the pre-configured post-quantum static public key Spq_r of the responding device, it performs a standard KEM encapsulation operation (KEM.Encaps) to generate the post-quantum key encapsulated ciphertext ct1 and the corresponding shared secret shk1. Simultaneously, a classic DH calculation is performed to generate the first classic shared secret dh_eisr = DH(ec_i', Sc_r). The first symmetric key is derived using the Key Derivation Function (KDF) KDF1. The ChaCha20 symmetric encryption algorithm (a stream cipher whose core component is a symmetric 20-round encryption function based on an initial state matrix) is used to encrypt ct1, resulting in the encrypted key-encapsulated ciphertext ct1enc, thus protecting the anonymity of the KEM ciphertext. Subsequently, the initiating device initializes its local key chain and hash chain, derives intermediate keys k3 and k4, and uses the ChaCha20Poly1305 AEAD (Authenticated Encryption with Associated Data) encryption algorithm to encrypt its own identity hash value HASH(Sc_i||Spq_i) and the current timestamp now(), respectively, obtaining the static field and the time field. The above fields, together with the type field, session identifier sid_i, classic ephemeral public key Ec_i, post-quantum ephemeral public key Epq_i, and encrypted ciphertext ct1enc, constitute the plaintext portion of the inner core fields.

[0035] After generating the inner core field, the initiating device performs a group signature generation operation. Specifically, the group signature uses a lattice-based post-quantum group signature algorithm based on the CRS (Common Reference String) model. The initiating device calls the group signature generation algorithm, using the group member private key gsk_i distributed by the group administrator during the group registration phase as the signature key, to sign the original signature M = gID||inner', which is composed of the group identifier gID and the plaintext part of the inner core field. Since the lattice-based post-quantum group signature is based on the assumption of the difficult problem of Module Learning With Errors (MLWE) on a lattice, its signature generation process includes generating a zero-knowledge proof that proves the signer belongs to the group based on the trapdoor sampling algorithm on the lattice, and outputting this zero-knowledge proof as the group signature σ. The maximum length of the group signature σ is controlled to be within 1000 bytes after compression. Due to the anonymity of the signer in the group signature algorithm, the signature σ can only prove that the signer belongs to the group, without revealing the specific identity information of the initiating device. Thus, in the subsequent pre-verification, both identity legitimacy proof and anonymity protection are taken into account.

[0036] S2. The initiating device embeds the group identifier and the group signature into the plaintext header of an InitHello message based on the Hybrid-WireGuard protocol and carrying the inner core field, so as to assemble a handshake request packet.

[0037] In step S2, the initiating device assembles a complete InitHello message (i.e., used to indicate "initializing and sending a greeting message") according to the agreed message format. Specifically, the group identifier field and the group signature field are located before the message type field of the InitHello message. The specific message structure, in transmission order, is as follows: a 4-byte group identifier gID, a group signature σ with a length not exceeding 1000 bytes, and an inner (i.e., internal object) core field (whose first byte is a 4-byte message type field). Placing the group identifier and group signature at the very beginning of the plaintext header is intended to enable the responding device, after receiving the data packet at the UDP (User Datagram Protocol) layer of the network protocol stack, to directly extract and complete the pre-verification of the group signature without touching the encrypted part in the inner core field. This is the structural basis for implementing the "verify first, calculate later" anti-DoS logic. Specifically, the total length of the entire InitHello message, including the group identifier and group signature, does not exceed 1270 bytes. This strictly adheres to the IPv6 (Internet Protocol Version 6, designed by the Internet Engineering Task Force to replace the widely used IPv4 protocol, whose most significant advantage is providing a nearly unlimited 128-bit address space, fundamentally solving the problem of IPv4 address resource exhaustion and laying the foundation for the "Internet of Everything") network minimum MTU (Maximum Transmission Unit) limit of 1280 bytes. Therefore, IP (Internet Protocol) layer fragmentation is unnecessary, and it is fully compatible with the existing UDP (User Datagram Protocol) transmission model of the WireGuard protocol. After assembly, the initiating device also needs to generate MAC (Message Authentication Code) verification values ​​m1 and m2 according to the native Hybrid-WireGuard rules, and append m1 and m2 to the message tail to obtain the final handshake request packet.

[0038] S3. The initiating device sends the handshake request packet to the responding device.

[0039] In step S3, the initiating device sends the assembled handshake request packet to the pre-configured responding device IP address and port (usually the WireGuard default port 51820) via the UDP protocol. Simultaneously, the initiating device continues to maintain the initialization state of the key chain and hash chain locally, preparing for receiving RespHello messages (i.e., response messages used to respond to InitHello messages) and completing session key derivation.

[0040] S4. The responding device receives the handshake request packet and extracts the group identifier and the group signature from the handshake request packet.

[0041] In step S4, after receiving the data packet on the UDP listening port, the responding device first performs a basic format check to confirm that the data packet is an InitHello message of the Hybrid-WireGuard protocol. Then, the responding device parses the 4-byte group identifier gID and the following group signature σ (whose length can be determined by the group signature's own format or read according to the agreed maximum length) sequentially from the plaintext header, and splits the remaining part of the message into the inner core field and MAC checksums m1 and m2. At this point, the responding device has not yet performed any decryption operation on the encrypted part in the inner core field; it has only completed the extraction of the plaintext header.

[0042] S5. The responding device obtains the pre-configured group public key and group revocation list based on the group identifier.

[0043] In step S5, the responding device uses the extracted group identifier gID to search for the corresponding group configuration in a locally pre-configured group information database. This database is established and maintained by the group administrator during the offline pre-configuration phase and contains at least the group public key gpk uniquely corresponding to gID and the group revocation list R_list. If gID does not exist or the corresponding group configuration is invalid, the responding device directly discards the handshake request packet and terminates the process without performing any subsequent cryptographic operations.

[0044] S6. The responding device invokes the group signature verification algorithm and, in conjunction with the group public key and the group revocation list, verifies the validity of the group signature, and then executes step S61 or step S62.

[0045] In step S6, the responding device executes the core pre-validation logic. Specifically, the responding device calls the lattice-based post-quantum group signature verification algorithm based on the CRS model. The input parameters include: the group public key gpk obtained in step S5, the group signature σ obtained in step S4, and the original signature M, which is formed by concatenating the group identifier gID and the plaintext part of the inner core field. The verification algorithm first verifies whether σ is a valid zero-knowledge proof through lattice-based mathematical operations, that is, verifies whether the signature was indeed generated by a member holding a valid group member's private key and whether the original signature has been tampered with. Secondly, when the group revocation list records the identity public key of a group member whose group membership has been revoked, the validity verification also includes: determining whether the identity public key corresponding to the group member who generated the group signature exists in the group revocation list R_list. If it exists, the validity verification of the group signature is determined to have failed. Here, the identity public key is the hash value of the initiating device's classical static public key and post-quantum static public key. Specifically, the revocation check sub-algorithm in the verification algorithm compares the member identification information implicit in the group signature σ with the identity public keys in the revocation list (i.e., the hash values ​​HASH(Sc||Spq) of each member's classical static public key and post-quantum static public key). If the comparison matches, the validity verification is directly deemed to have failed, regardless of the cryptographic verification result.

[0046] In step S6, specifically, after the validity verification is completed, if the group signature validity verification passes and the signer is not in the revocation list, the process proceeds to step S61; if the verification fails or the signer is in the revocation list, the process proceeds to step S62.

[0047] S61. If the validity verification of the group signature passes and the signer who generated the group signature is not in the group revocation list, then the inner core field is parsed to perform a handshake process based on the Hybrid-WireGuard protocol and with the initiating device, and during the handshake process, the group public key is added to the identity binding hash of the key chain, and the group signature is embedded in the hash chain.

[0048] In step S61, the responding device enters the complete Hybrid-WireGuard handshake process, which is fully compatible with the native protocol but adds key security binding operations related to the group signature system.

[0049] First, the responding device parses the inner core field, extracting fields such as type, sid_i, Ec_i, Epq_i, ct1enc, static, and time. The responding device then performs an X25519 DH computation using its own classical static private key sc_r' and the initiator's classical temporary public key Ec_i to obtain the first classical shared secret dh_eisr. It then derives the first symmetric key using the key derivation function KDF and decrypts ct1enc using ChaCha20 to obtain the original post-quantum key-encapsulated ciphertext ct1. Subsequently, the responding device performs a KEM decapsulation operation (KEM.Decaps) on ct1 using its own post-quantum static private key spq_r' to obtain the first post-quantum shared secret shk1.

[0050] Next, the responding device initializes the key chain and hash chain, following a nine-step derivation structure consistent with the native Hybrid-WireGuard protocol. In key chain derivation, the group public key is added to the identity binding hash of the key chain. Specifically, during the nine-step key chain derivation process, the hash value HASH(gpk) of the group public key is used as part of the input parameter of the fourth-step key derivation function HKDF, making the calculation formula for the fourth key chain value C4 (i.e., C4 in Table 1) C4=KDF2(C3,dh_sisr||HASH(gpk)) (i.e., C4=KDF2(C3,dh_sisr‖HASH(gpk)) in Table 1), meaning the calculation of the fourth key chain value depends on the group public key. Subsequent derivations of key chain values ​​from the fifth to the ninth steps are all based on the fourth key chain value containing the group public key binding relationship. Finally, the sending session key tk_i and receiving session key tk_r used for encrypting transmitted data are derived based on the ninth key chain value. By irreversibly embedding the group public key into the key derivation chain, even if the responder's classic static private key and post-quantum static private key are leaked in the future, attackers who do not possess legitimate group member private keys will still be unable to obtain the session key by failing the handshake pre-verification and because the key chain contains unknown group public key binding relationships. This completes the backward security missing in the original protocol.

[0051] To more clearly illustrate the specific process of the nine-step key chain derivation, Table 1 below shows the complete derivation steps, including the modifications made in this scheme: Table 1. Improvement Explanation of the Nine-Step Key Chain Derivation Process

[0052] In terms of hash chain derivation, the group signature is embedded in the hash chain. Specifically, during the nine-step hash chain derivation process, the group signature σ is used as part of the input parameter of the hash function in the seventh step, so that the calculation formula of the seventh hash value H7 (i.e., H7 in Table 2) is H7=HASH(H6||σ) (i.e., H7=HASH(H6‖σ) in Table 2). That is, the calculation of the seventh hash value depends on the context information of the group signature and the current handshake session. The subsequent eighth and ninth hash generation steps are based on the seventh hash value, and finally generate the final hash chain value H9 of the responder (i.e., H9 in Table 2). This final hash chain value of the responder will be implicitly carried during the generation of the MAC checksum of the RespHello message. After being transmitted to the initiating device, the initiating device compares the hash chain value derived locally to verify whether the group signature has been tampered with or replayed during transmission. If the verification fails, the handshake is terminated and the derived session key is discarded, thereby effectively preventing replay attacks on the group signature.

[0053] To more clearly illustrate the specific process of the nine-step derivation of the hash chain, Table 2 below provides the complete derivation steps, including the modifications made in this scheme: Table 2. Improvement Explanation of the Nine-Step Derivation Process of Hash Chain

[0054] After completing the initialization and derivation of the key chain and hash chain, the responding device uses the derived intermediate key k3 to decrypt the static field using ChaCha20Poly1305 AEAD to obtain the initiator's identity hash value HASH (Sc_i||Spq_i), and uses this to find the corresponding pre-shared key psk to verify the validity of MAC values ​​m1 and m2. Simultaneously, it uses the intermediate key k4 to decrypt the time field to verify the freshness of the timestamp to defend against replay attacks. After all verifications pass, the responding device generates a classic temporary DH key pair (ec_r', Ec_r), performs subsequent DH calculations and KEM encapsulation operations, constructs a RespHello message, and sends it to the initiating device. Finally, both parties complete bidirectional session key negotiation, and the handshake is successfully established.

[0055] Specifically, the construction process of the RespHello message is as follows: The responding device generates a 32-byte random session identifier sid_r and generates a classic temporary DH key pair (ec_r', Ec_r); using the initiating device's quantum temporary public key Epq_i, KEM.Encaps is executed to generate ciphertext ct2 and shared secret shk2; using the initiating device's quantum static public key Spq_i, KEM.Encaps is executed to generate ciphertext ct3 and shared secret shk3; DH calculation is performed to generate shared secret dh_ser, and the derived key pair ct3 is... Symmetric encryption yields ct3enc; the entire process of key chain and hash chain derivation is completed, and the empty field is encrypted using AEAD with the derived intermediate key to obtain the empty field; MAC values ​​m1 and m2 are generated according to the native protocol rules; the complete RespHello message is assembled, with the following structure: type (4B)||sid_r (32B)||sid_i (32B)||Ec_r (32B)||ct2 (768B)||ct3enc (156B)||empty (16B)||m1 (16B)||m2 (16B). The responding device sends the RespHello message to the initiating device and simultaneously generates the local final session key.

[0056] After receiving the RespHello message, the initiating device performs the following processing: parses the RespHello message and verifies the validity of MAC values ​​m1 and m2; extracts core fields such as Ec_r, ct2, and ct3enc, performs DH calculation and KEM decapsulation to obtain the corresponding shared secret; completes the full-process derivation of the key chain and hash chain to generate a local session key; during this process, the initiating device verifies the binding relationship between the group signature and the session context by comparing the final value of the locally derived hash chain. If the verification fails, the handshake is terminated and the derived session key is discarded, thereby ensuring the integrity of the handshake.

[0057] After the handshake is completed, both parties can use the derived sending session key tk_i and receiving session key tk_r to perform AEAD (Authenticated Encryption with Associated Data, a form of encryption that ensures data simultaneously has confidentiality, integrity and authentication) encrypted transmission, which is completely consistent with the native Hybrid-WireGuard without any modifications; the group signature is only used for pre-identification verification and trust root construction in the handshake phase, and does not affect the throughput, latency and compatibility in the data transmission phase, and can fully reuse the transport layer optimization capabilities of the native protocol.

[0058] Furthermore, throughout step S61, since the group signature verification step has already been completed in step S6 and the verification process does not require obtaining the signer's identity information, the responding device cannot know the specific identity of the initiating device before decrypting the static field, thus fully preserving the anonymity of the Hybrid-WireGuard protocol. Preferably, when the responding device is configured as a group administrator device and holds the group management private key gmsk, if abnormal handshake behavior (such as a large number of repeated failed handshake requests) is detected in subsequent communications, the responding device can call the group signature opening algorithm, using gmsk as input, to extract the public key lpk=HASH(Sc_i||Spq_i) corresponding to the group member who generated the signature from the group signature σ, thereby accurately tracing the attack source and achieving the location and evidence collection of the malicious initiating device.

[0059] S62. If the validity verification of the group signature fails or the signer who generated the group signature exists in the group revocation list, then the handshake request packet is discarded and the handshake is terminated.

[0060] In step S62, the responding device directly discards the received handshake request packet without performing any subsequent cryptographic operations such as classical DH calculations, post-quantum KEM decapsulation, key chain initialization, and AEAD decryption. Since the group signature verification algorithm only involves lightweight hash operations and simple lattice basis mathematical operations, the verification time for a single message is only in the microsecond range (approximately 0.02ms), far lower than the overhead of post-quantum KEM decapsulation and DH calculations. Therefore, even if an attacker sends a large number of forged handshake request packets at an extremely high frequency, the responding device only needs to expend very little computing power to complete the pre-verification and discard malicious packets. CPU (Central Processing Unit) resources will not be exhausted by high-overhead cryptographic operations, fundamentally eliminating the computational DoS attack surface. Simultaneously, due to the group revocation list check mechanism, handshake requests initiated by malicious nodes whose group membership has been revoked by the administrator will also be directly blocked at the entry point, achieving real-time dynamic access control without modifying the pre-shared key stored in the responding device or the static public key corresponding to that node, thus not affecting the normal handshake and communication of other legitimate group members.

[0061] Furthermore, this embodiment has the following advantages in engineering implementation: First, it is fully compatible with cryptographic primitives—the selected lattice basis group signature algorithm is based on the MLWE hard problem, and is compatible with the ML-KEM (Module-Lattice-based Key Encapsulation Mechanism) used in the native Hybrid-WireGuard protocol, which is based on the FIPS 203 standard developed by the National Institute of Standards and Technology (NIST). The officially released post-quantum cryptography key encapsulation mechanism in the standard shares the same post-quantum security root, allowing direct reuse of existing post-quantum cryptography libraries with extremely low engineering integration costs. Secondly, its plug-in design offers flexible deployment—the group signature module is an independent plug-in design that can be flexibly enabled or disabled according to business needs. Once enabled, it achieves bidirectional compatibility with the native protocol without requiring large-scale modifications to the existing deployment architecture. Thirdly, it is fully compatible with the native protocol architecture—only incremental fields are added to the InitHello message, while the RespHello message remains unchanged. The core key exchange logic, hybrid security architecture, key chain and hash chain derivation process, and AEAD encryption mechanism of the native protocol are all fully preserved, and all formal security proofs of the native protocol can be fully reused. Fourthly, it is adaptable to large-scale commercial deployment scenarios—the lightweight group member revocation mechanism does not require modification of the node's static key pair and pre-shared key, and does not interrupt the normal business of legitimate users, resulting in extremely low operating costs. Even in large-scale deployment scenarios with hundreds of thousands of clients, it can achieve fine-grained permission control of nodes.

[0062] To further illustrate the security of the handshake method provided in this embodiment against denial-of-service (DoS) attacks, the following section, in conjunction with the accompanying drawings and the game-based security proof framework, provides a formal demonstration of how this solution achieves anti-DoS characteristics through pre-signature verification.

[0063] (a) Definition of DoS Attack Resistance In the context of the enhanced Hybrid-WireGuard protocol provided in this embodiment (i.e., the aforementioned steps S1 to S6), the core definition of anti-DoS attack is: attackers cannot force the protocol responder device to perform high-overhead cryptographic operations by means such as forging handshake requests and replaying invalid handshake packets. These high-overhead cryptographic operations include, but are not limited to, classical Diffie-Hellman key exchange calculations, post-quantum key encapsulation mechanism decapsulation, and authentication encryption / decryption with associated data. Furthermore, attackers cannot exhaust the responder device's computing power and bandwidth resources, ensuring that the responder device can normally respond to the handshake requests and data transmission needs of legitimate group members. The core of the anti-DoS design in this embodiment lies in "pre-verification and low-cost filtering"—filtering invalid requests before all high-overhead operations through microsecond-level group signature validity verification. Therefore, the definition emphasizes "preventing attackers from triggering high-overhead operations," which is also the core enhancement point that distinguishes it from the native Hybrid-WireGuard protocol.

[0064] (ii) Game-based security proof against DoS attacks The core idea of ​​the proof lies in designing a series of indistinguishable games to reduce an attacker's DoS attack capability against the protocol to the cryptographically difficult assumption of the unforgeability of group signatures. If the group signature satisfies the unforgeability, then the attacker cannot forge a valid signature, cannot pass the pre-verification, and therefore cannot trigger the high-overhead operation of the responding device, thus the protocol satisfies the DoS resistance characteristic.

[0065] The core premise is that the group signature used in the protocol is a lattice-based post-quantum group signature based on the public reference string model. Under the quantum random oracle model, it satisfies the unforgeability requirement, meaning that an attacker cannot forge a group signature that can be verified by the group's public key in polynomial time unless they possess a legitimate group member's private key. At the same time, the group signature verification overhead is microsecond-level hash computation, which is far lower than the millisecond-level high-overhead operations such as Diffie-Hellman computation and decapsulation of post-quantum key encapsulation mechanisms.

[0066] (1) Definition of game sequence The following analysis, using the game sequence DoS0→DoS1→DoS2, progressively removes redundant factors from the real-world scenario, ultimately proving that the attacker's advantage is negligible: (1.1) Game DoS0: Real attack game, this game is consistent with the actual running scenario of the protocol, including: (1.1.1) Initialization phase: The challenger, as the group administrator, generates group parameters (group unique identifier gID, group public key gpk, group management private key gmsk), and initializes the group member list and group revocation list R_list; the challenger generates the classic Diffie-Hellman key pair and the post-quantum static key encapsulation mechanism key pair for the responder device, and registers the responder device as a legitimate group member; attacker A initiates a group member registration request, generates its own long-term key and submits its long-term identity public key to the challenger for authentication, and the challenger assigns A a legitimate group member private key gsk_A; the challenger publishes the globally accessible parameters gID, gpk, the responder's classic static public key and post-quantum static public key, and the group revocation list R_list.

[0067] (1.1.2) Attack Phase: Attacker A can send InitHello handshake requests to the responding device multiple times. These requests fall into two categories: (a) Legitimate requests: carrying a valid group signature σ_A generated by A using gsk_A, with other fields conforming to the protocol specifications; (b) Forged requests: carrying no group signature, a forged group signature σ_fake, a group signature of a revoked member, or altering the group identifier and signature binding information, etc. The responding device processes all requests according to the protocol logic described in this embodiment: first, it performs pre-verification, parsing the group identifier and group signature, verifying the validity of the group public key, the legitimacy of the group signature, and whether the signer is in the group revocation list; if the verification passes, it performs high-overhead operations and completes the subsequent handshake process; if the verification fails, it directly discards the request without performing any high-overhead operations. Attacker A's goal is to force the responding device to perform high-overhead operations a certain number of times, exhausting the server's resources, by sending forged requests, thus successfully launching a DoS attack.

[0068] (1.1.3) Advantage definition: The advantage of attacker A in successfully carrying out a DoS attack in Game DoS0 is Adv_DoS0(A)=Pr[A forces the responder to perform high-overhead operations ≥ threshold T by forging requests].

[0069] (1.2) Game DoS1: Modify the group signature verification rules. The only difference between this game and Game DoS0 is that the pre-verification logic of the responder's device remains unchanged, but verification is only allowed if the group signature σ is generated by a legitimate group member holding an unrevoked private key; if σ is a forged signature, even if it can be verified through the group public key, the verification will fail and the request will be discarded. The advantage definition Adv_DoS1(A) is the same as Game DoS0.

[0070] (1.2.1) Lemma 1: If the group signature satisfies the unforgeability under the quantum random oracle model, then the advantage difference between Adv_DoS0(A) and Adv_DoS1(A) is negligible. The proof is as follows: Assume there exists an attacker A who can make the advantage difference between the two non-negligible. Then a reduction algorithm B can be constructed to forge a valid group signature using A, thereby violating the unforgeability assumption of the group signature.

[0071] (1.3) Game DoS2: High-overhead operations are removed. The only difference between this game and Game DoS1 is that after the pre-verification is successful, the responding device does not perform any high-overhead operations, but only records the number of "verification successful" results. It does not perform Diffie-Hellman calculations or decapsulation operations such as the post-quantum key encapsulation mechanism. The advantage is defined as Adv_DoS2(A) as the probability that attacker A can make the responding device record the number of "verification successful" results reach the threshold T by forging requests.

[0072] (1.3.1) Lemma 2: The advantage difference between Adv_DoS1(A) and Adv_DoS2(A) is negligible. The proof is as follows: The only difference between GameDoS1 and Game DoS2 is whether a high-overhead operation is performed after successful verification. Whether attacker A can successfully force the responding device to perform a high-overhead operation depends entirely on whether it can pass the pre-verification. Therefore, the probability of A passing verification by forging requests is exactly the same in both games, and the advantage difference is negligible.

[0073] (2) Security Analysis of Game DoS2 In Game DoS2, for attacker A to reach the threshold T for the number of "verification passes," they must send a request carrying a legitimate group signature. A legitimate group signature can only be generated by a subject holding an unrevoked group member's private key. Since A only possesses their own legitimate group member private key, gsk_A, the request corresponding to the legitimate signature they generate is a "legitimate request" and is not considered a DoS attack. If A attempts to forge the signature, due to the unforgeability of group signatures, the forged signature will fail the pre-verification and cannot be recorded as "verification passed." Therefore, A cannot reach the threshold T for the number of "verification passes" in Game DoS2 by forging requests; that is, Adv_DoS2(A) is negligible.

[0074] (III) Conclusion on Countering DoS Attacks By reducing the game sequence DoS0→DoS1→DoS2, attacker A's total attack advantage satisfies: Adv_DoS(A)≤ |Adv_DoS0(A)-Adv_DoS1(A)|+|Adv_DoS1(A)-Adv_DoS2(A)|+Adv_DoS2(A). According to Lemmas 1 and 2, the advantage differences of the first two terms are both negligible, and Adv_DoS2(A) is negligible; therefore, Adv_DoS(A) is negligible. In summary, the enhanced Hybrid-WireGuard protocol described in this embodiment, through the design of "group signature pre-verification," satisfies the anti-DoS attack characteristics: attackers cannot trigger high-overhead operations on the responding device by forging requests, cannot exhaust server resources, and ensure the normal operation of the protocol.

[0075] Furthermore, in this scheme, the group signature verification only involves microsecond-level hash calculations, with an overhead of only one-thousandth of the decapsulation cost of the post-quantum key encapsulation mechanism. This avoids the risk of "verification itself becoming a target for DoS attacks" by not increasing the burden on the responding device due to pre-verification. Moreover, the group signature is only used for pre-verification and does not participate in session key derivation. Therefore, the anti-DoS enhancement does not affect the forward security, backward security, and hybrid security boundary of the protocol, and is fully compatible with the aforementioned security attributes.

[0076] In summary, the WireGuard handshake method provided in this embodiment has the following technical advantages: (1) This embodiment provides a method that can preserve the anonymity of the original protocol, 1 A new handshake scheme enhances DoS resistance and supplements backward security while leveraging the low latency advantages of RTT and a hybrid security boundary. This scheme is executed interactively by the initiating and responding devices, including: the initiating device using the group member's private key to generate a group signature from the plaintext signature containing the group identifier and inner core field; and embedding the group identifier and group signature into a Hybrid-based... The WireGuard protocol's InitHello message is sent after the plaintext header; the responding device receives and extracts the group identifier and group signature, obtains the pre-configured group public key and group revocation list, and calls the group signature verification algorithm for validity verification; if the verification passes and the signer is not on the revocation list, the inner core field is parsed to perform handshake processing, and during the handshake process, the group public key is added to the key chain identity binding hash and the group signature is embedded in the hash chain; if the verification fails or the signer is on the revocation list, the handshake request packet is discarded and the handshake is terminated. This invention reconstructs the handshake sequence through pre-signature verification, fundamentally eliminating the computational DoS attack surface, while supplementing backward security through the cryptographic binding of the group public key and group signature, and fully preserving the anonymity of the original protocol. RTT low latency and hybrid security boundary; (2) It can fundamentally eliminate the computational denial-of-service attack surface and achieve the reversal of attack and defense computing power. That is, by embedding the group identifier and group signature into the plaintext header of the InitHello message, the handshake processing sequence is reconstructed, so that the responding device can extract and execute the group signature validity verification first without touching the encrypted part of the inner core field. Since the group signature verification only relies on lightweight hash operation and lattice mathematical operation, the verification time of a single message is controlled at the microsecond level, which is only one-thousandth of the time spent on post-quantum KEM decapsulation and Diffie-Hellman calculation. The responding device will only execute the handshake verification if the group signature verification is successful and the signer is not on the group revocation list. The Hybrid-WireGuard protocol employs high-overhead cryptographic operations such as classical Diffie-Hellman shared secret computation, post-quantum KEM decapsulation, key chain initialization, and AEAD decryption. If verification fails or the signer has been revoked, the handshake request packet is discarded without triggering any subsequent high-overhead computations. As a result, even if an attacker sends a batch of forged handshake packets conforming to the format specifications, the responding device only needs to pay a very low computational cost to complete the pre-interception, completely blocking the path of forged packets consuming CPU resources. This reverses the cost gap between attack and defense from a thousand-fold difference in the original protocol to a situation where the defender has the advantage, fundamentally eliminating the computational denial-of-service attack surface inherent in the Hybrid-WireGuard protocol. (3) It can completely supplement backward security and achieve secure isolation of future session keys after the long-term static private key is leaked. That is, it constructs an identity trust root independent of the long-term communication key through the group signature system, and irreversibly embeds the group public key as identity binding information during the key chain derivation process. Specifically, in the fourth step of the nine-step key chain derivation, the hash value of the group public key is used as the input parameter of the key derivation function KDF, so that the calculation of the fourth key chain value depends on the group public key. The derivation of subsequent key chain values ​​and the generation of the final session key are all based on the chain value containing this binding relationship. Thus, even if the response The classical static private key and the post-quantum static private key of the device are leaked. The attacker cannot pass the pre-signature verification because he does not have the private key of the legitimate group member. Moreover, because the key derivation chain contains the group public key binding relationship that the attacker cannot know, it is still impossible to restore the complete key derivation chain to obtain the session key for the newly established session after the leakage event. This achieves cryptographic isolation between the long-term communication private key and the future session key, completely fills the back security missing in the existing Hybrid-WireGuard protocol, and effectively resists the continuous security risks caused by long-term key leakage in quantum computing scenarios. (4) It can take into account both the verification of the legitimacy of the identity of the initiator and the protection of the anonymity of the initiator. That is, the group signature algorithm adopted has the anonymity of the signer and the non-linkability. The group signature generated by the initiator device using the private key of the group member can only prove that it belongs to the legitimate group member. During the verification process, the responder device only needs to publish the group public key to complete the validity verification. It does not need to obtain the specific identity information of the signer, and it is impossible to deduce the identity of the specific initiator device from the group signature, nor can it link different group signatures of the same member. Therefore, while achieving strong identity legitimacy access through the verification of the group signature, it fully retains the original identity anonymity design of the Hybrid-WireGuard protocol, solves the core contradiction in the existing scheme that "the verification of the identity will inevitably lead to the leakage of identity", and achieves a two-way balance between anonymity and identity authentication. (5) It can realize a closed-loop full lifecycle handling of attack source traceability and malicious node dynamic revocation. That is, by utilizing the traceability characteristics of the group signature algorithm, when the responding device holds the group management private key as the group administrator, it can call the group signature opening algorithm after detecting abnormal handshake behavior, and accurately extract the identity public key of the corresponding group member from the captured malicious group signature, so as to locate and collect evidence of the distributed denial-of-service attack source. At the same time, the responding device maintains the group revocation list and checks whether the signer exists in the revocation list during the group signature verification stage. If it exists, it directly determines that the verification fails and discards the handshake packet. The group administrator only needs to add the identity public key of the malicious member to the revocation list and synchronize it to each responding device. Without modifying the pre-shared key and the node static communication key pair, and without interrupting the normal business of legitimate users, it can realize real-time handshake blocking and permission banning of malicious nodes. The above mechanisms jointly construct a closed-loop full lifecycle handling of "attack detection - identity traceability - permission banning", which solves the operation and maintenance pain points of the original protocol attack source being untraceable and lacking dynamic permission control. (6) It is fully compatible with the native protocol architecture and hybrid security boundary, and can achieve smooth upgrades. That is, all modifications are incremental. Only the plaintext header of the group identifier and group signature fields of the InitHello message of the Hybrid-WireGuard protocol is extended. The RespHello message structure and generation logic are completely consistent with the native protocol without any modifications. The core key exchange logic of the native protocol, the hybrid security architecture of classical Diffie-Hellman and post-quantum KEM, the nine-step derivation process of key chain and hash chain, the ChaCha20Poly1305 AEAD encryption mechanism, and the anonymity repair design for KEM ciphertext are all completely retained without any changes. Therefore, the original hybrid security guarantee (that is, "as long as either classical DH or post-quantum KEM primitive is secure, the whole protocol is secure"), the ability to resist unknown key sharing attacks, forward security and strong key confidentiality and other core security attributes of the protocol are all fully inherited. The formal security proof of the native protocol can be fully reused without re-evaluation of security, which greatly reduces the technical transformation cost and compatibility risk of post-quantum migration. (7) It can meet the MTU limit of IPv6 network and has the advantage of plug-in deployment. That is, the length of the group identifier field embedded incrementally in the InitHello message is only 4 bytes, the length of the group signature after compression is no more than 1000 bytes, and the total length of the modified InitHello message is strictly controlled within 1270 bytes, which meets the limit of the minimum MTU of IPv6 network of 1280 bytes. There is no need to perform IP layer fragmentation transmission, and it is fully compatible with the UDP transmission model of the existing WireGuard protocol. At the same time, the selected lattice basis group signature algorithm is based on the error-learning difficulty problem on the lattice and shares the same security root with the ML-KEM post-quantum algorithm used by the native Hybrid-WireGuard protocol. It can be directly reused from the existing post-quantum cryptography library without introducing additional cryptographic dependencies. The group signature module adopts an independent plug-in design, which can be flexibly turned on or off according to business needs. After being turned on, it is bidirectionally compatible with the native protocol. There is no need to carry out large-scale transformation of the existing deployment architecture. The engineering integration cost is extremely low. It is suitable for large-scale commercial deployment scenarios such as home remote access, enterprise mobile office, edge computing networking and IoT security access, which is convenient for practical application and promotion.

[0077] Example 2 Based on the technical solution of Embodiment 1, this embodiment also provides a virtual system for implementing the WireGuard handshake method described in Embodiment 1, such as... Figure 2 As shown, it is suitable for deployment in the responder's device and includes a handshake request receiving unit, a group information extraction unit, a configuration information acquisition unit, a signature validity verification unit, a verification success response unit, and a verification failure response unit. The handshake request receiving unit is used to receive a handshake request packet sent by the initiating device, wherein the handshake request packet is an InitHello message based on the Hybrid-WireGuard protocol and carrying a group identifier field, a group signature field and an inner core field. The group information extraction unit is communicatively connected to the handshake request receiving unit and is used to extract the group identifier and group signature from the handshake request packet. The configuration information acquisition unit is communicatively connected to the group information extraction unit and is used to obtain a pre-configured group public key and group revocation list based on the group identifier. The signature validity verification unit is communicatively connected to the group information extraction unit and the configuration information acquisition unit, respectively, and is used to call the group signature verification algorithm and, in conjunction with the group public key and the group revocation list, to verify the validity of the group signature. The verification success response unit is communicatively connected to the signature validity verification unit. When the validity verification of the group signature passes and the signer who generated the group signature is not in the group revocation list, it parses the inner core field to perform a handshake process based on the Hybrid-WireGuard protocol and with the initiating device. During the handshake process, it adds the group public key to the identity binding hash of the key chain and embeds the group signature into the hash chain. The verification failure response unit is communicatively connected to the signature validity verification unit, and is used to discard the handshake request packet and terminate the handshake when the validity verification of the group signature fails or the signer who generated the group signature exists in the group revocation list.

[0078] Other technical details and effects of this embodiment can be derived conventionally by referring to the technical details and effects of Embodiment 1, and will not be repeated here.

[0079] Example 3 Based on the technical solution of Embodiment 1, this embodiment also provides a physical system for implementing the WireGuard handshake method described in Embodiment 1, such as... Figure 3 As shown, it includes a first device and a second device; The first device is configured to perform method steps executed by the initiating device in the WireGuard handshake method as described in Embodiment 1; The second device is configured to perform method steps executed by the responding device in the WireGuard handshake method as described in Embodiment 1.

[0080] Other technical details and effects of this embodiment can be derived conventionally by referring to the technical details and effects of Embodiment 1, and will not be repeated here.

[0081] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A WireGuard handshake method that enhances DoS protection and improves backward security, characterized in that, Performed by the responder's device, including: Receive a handshake request packet sent by the initiating device, wherein the handshake request packet is an InitHello message based on the Hybrid-WireGuard protocol and carrying a group identifier field, a group signature field and an inner core field; Extract the group identifier and group signature from the handshake request packet; Obtain the pre-configured group public key and group revocation list based on the group identifier; The group signature verification algorithm is invoked, and the validity of the group signature is verified by combining the group public key and the group revocation list. If the validity verification of the group signature passes and the signer who generated the group signature is not in the group revocation list, then the inner core field is parsed to perform a handshake process based on the Hybrid-WireGuard protocol and with the initiating device. During the handshake process, the group public key is added to the identity binding hash of the key chain, and the group signature is embedded in the hash chain. If the validity verification of the group signature fails or the signer who generated the group signature exists in the group revocation list, the handshake request packet is discarded and the handshake is terminated.

2. The WireGuard handshake method as described in claim 1, characterized in that, The group signature adopts a lattice-based post-quantum group signature based on the CRS model, and is generated and verified in the following manner: The initiating device uses the private key of the group member obtained during the group registration phase to perform a signature generation operation on the plaintext containing the inner core field and the signature plaintext of the group identifier to generate the group signature; The process by which the responding device verifies the group signature using the group public key does not require verification of the signer's identity information, so as to preserve the anonymity of the Hybrid-WireGuard protocol while achieving pre-validation through the validity verification.

3. The WireGuard handshake method as described in claim 1, characterized in that, Adding the group public key to the identity binding hash of the key chain includes: In the nine-step key chain derivation process of the Hybrid-WireGuard protocol, the hash value of the group public key is used as part of the input parameter of the key derivation function in the fourth step, so that the calculation of the fourth key chain value depends on the group public key. The subsequent key derivation steps in the nine-step key chain derivation process are based on the fourth key chain value. Finally, a session key for encrypting data transmission is derived based on the ninth key chain value. This ensures that even if the classic static private key and the post-quantum static private key of the responder's device are leaked, an attacker who does not possess the legitimate group member's private key will still be unable to restore the key derivation chain to obtain the session key.

4. The WireGuard handshake method as described in claim 1, characterized in that, Embedding the group signature into the hash chain includes: In the nine-step hash chain derivation process of the Hybrid-WireGuard protocol, the group signature is used as part of the input parameter of the seventh-step hash function, so that the calculation of the seventh hash value depends on the context information of the group signature and the current handshake session. The subsequent hash generation steps in the nine-step hash chain derivation process are based on the seventh hash value, ultimately generating the final value of the responder's hash chain. This final value is used to compare with the final value of the initiator's hash chain obtained by the initiator based on the nine-step hash chain derivation process after being carried to the initiator's device by the RespHello message sent by the responder device. This verifies whether the group signature has been tampered with or replayed. If tampering or replay is detected, the initiator's device terminates the handshake and discards the derived session key.

5. The WireGuard handshake method as described in claim 1, characterized in that, The group identifier field and the group signature field are located before the message type field of the InitHello message. The group identifier field is 4 bytes long, the group signature field is no more than 1000 bytes long, and the total length of the InitHello message is no more than 1270 bytes to meet the IPv6 network minimum MTU limit of 1280 bytes.

6. The WireGuard handshake method as described in claim 1, characterized in that, When the responder device is configured as a group administrator device and holds a group management private key, the method further includes: When an abnormal handshake behavior is detected, the group signature opening algorithm is invoked. The group management private key is used as input to extract and generate the identity public key corresponding to the group member with the signature from the group signature, so as to realize the attack source tracing. The identity public key is the hash value of the classic static public key and the post-quantum static public key of the initiating device.

7. The WireGuard handshake method as described in claim 1, characterized in that, When the group revocation list contains the public keys of group members whose membership has been revoked, the validity of the group signature is verified, including: Determine whether the identity public key corresponding to the group member who generated the group signature exists in the group revocation list. If it exists, determine that the validity verification of the group signature has failed. The identity public key is the hash value of the classic static public key and the post-quantum static public key of the initiating device.

8. A WireGuard handshake method that enhances DoS protection and completes backward security, characterized in that, Executed interactively by the initiating and responding devices, including: The initiating device uses the private key of the group member obtained during the group registration phase to perform a signature generation operation on the plaintext containing the inner core field to be sent and the signature plaintext containing the group identifier, thereby generating a group signature. The initiating device embeds the group identifier and the group signature into the plaintext header of an InitHello message based on the Hybrid-WireGuard protocol and carrying the inner core field, so as to assemble a handshake request packet. The initiating device sends the handshake request packet to the responding device; The responding device receives the handshake request packet and extracts the group identifier and the group signature from the handshake request packet; The responding device obtains the pre-configured group public key and group revocation list based on the group identifier; The responding device invokes a group signature verification algorithm and, in conjunction with the group public key and the group revocation list, verifies the validity of the group signature. If the validity verification of the group signature passes and the signer who generated the group signature is not in the group revocation list, the inner core field is parsed to perform a handshake process based on the Hybrid-WireGuard protocol and with the initiating device. During the handshake process, the group public key is added to the identity binding hash of the key chain, and the group signature is embedded in the hash chain. If the validity verification of the group signature fails or the signer who generated the group signature exists in the group revocation list, the handshake request packet is discarded, and the handshake is terminated.

9. A WireGuard handshake system that enhances DoS protection and improves backward security, characterized in that, It is suitable for deployment in the responder's equipment and includes a handshake request receiving unit, a group information extraction unit, a configuration information acquisition unit, a signature validity verification unit, a verification success response unit, and a verification failure response unit; The handshake request receiving unit is used to receive a handshake request packet sent by the initiating device, wherein the handshake request packet is an InitHello message based on the Hybrid-WireGuard protocol and carrying a group identifier field, a group signature field and an inner core field. The group information extraction unit is communicatively connected to the handshake request receiving unit and is used to extract the group identifier and group signature from the handshake request packet. The configuration information acquisition unit is communicatively connected to the group information extraction unit and is used to obtain a pre-configured group public key and group revocation list based on the group identifier. The signature validity verification unit is communicatively connected to the group information extraction unit and the configuration information acquisition unit, respectively, and is used to call the group signature verification algorithm and, in conjunction with the group public key and the group revocation list, to verify the validity of the group signature. The verification success response unit is communicatively connected to the signature validity verification unit. When the validity verification of the group signature passes and the signer who generated the group signature is not in the group revocation list, it parses the inner core field to perform a handshake process based on the Hybrid-WireGuard protocol and with the initiating device. During the handshake process, it adds the group public key to the identity binding hash of the key chain and embeds the group signature into the hash chain. The verification failure response unit is communicatively connected to the signature validity verification unit, and is used to discard the handshake request packet and terminate the handshake when the validity verification of the group signature fails or the signer who generated the group signature exists in the group revocation list.

10. A WireGuard handshake system that enhances DoS protection and improves backward security, characterized in that, It includes a first device and a second device; The first device is configured to perform method steps executed by the initiating device in the WireGuard handshake method as described in claim 8; The second device is configured to perform method steps executed by the responding device in the WireGuard handshake method as described in claim 8.

Images