A zero handshake high security tunnel forwarding system and method for narrowband satellite link and readable storage medium

Abstract

The application provides a zero handshake high security tunnel forwarding system and method for a narrowband satellite link and a readable storage medium, which comprises a terminal device and a transit gateway device, the terminal device and the transit gateway device are connected in communication through a narrowband satellite link; the terminal device comprises a key generation unit, a random number calculation unit, a load encryption unit and a message assembling and sending unit connected in sequence; the transit gateway device comprises a message analysis and decryption unit, an authentication check unit, a mapping management unit and a service forwarding unit connected in sequence, the message assembling and sending unit and the message analysis and decryption unit are connected in communication, and through a short identity and zero handshake key negotiation mechanism, the application realizes high security, rapid access and seamless roaming while limiting the tunnel header overhead.

Description

Technical Field

[0001] This invention relates to satellite communication terminals and relay server equipment, belonging to the field of satellite communication and network communication technology, and particularly to a zero-handshake high-security tunnel forwarding system, method and readable storage medium for narrowband satellite links. Background Technology

[0002] With the rapid development of satellite communication technology, integrating satellite links into heterogeneous network architectures and utilizing narrowband satellite link forwarding to achieve data communication in remote areas or weakly connected scenarios has become an important means of ensuring network reliability in scenarios such as low-altitude economy, unmanned swarms, and earthquake relief. Currently, typical narrowband satellite communication systems include: GEO-based narrowband satellite systems, such as Tiantong-1, Inmarsat IsatPhone, and Thuraya; and LEO-based narrowband IoT IP satellite communication systems, such as ORBCOMM and Globalstar.

[0003] The aforementioned narrowband satellite links share high similarities in communication performance and network architecture: First, the data rate is in the range of 2.4-9.6 kbps, and the latency is significantly higher than that of terrestrial networks; second, user terminals cannot communicate directly with each other, and data must be relayed to the ground gateway station via satellite, and then the gateway station accesses the terrestrial public network for relay; third, the gateway station, as the data center node of the satellite communication system, undertakes the responsibility of distributing and collecting satellite communication service data, and realizes the translation between the internal address and external address of users in the constellation network through NAT (Network Address Translation).

[0004] In a typical network communication scenario involving narrowband satellite links for forwarding, the satellite link segment can be simplified into the following network model: Figure 1 As shown: Figure 1 The main nodes include: host A, satellite terminal A, satellite network segment (including IP Internet satellite, operator ground gateway station and other network elements), public network relay server with fixed IP, satellite terminal B, and host B.

[0005] In the above model, hosts A and B are end nodes or intermediate nodes on the multi-hop routing forwarding path of communication services. The hosts are unaware of the satellite network (and cannot deploy special technologies to cope with the characteristics of the satellite network); while satellite terminals A and B, as network nodes on par with the hosts, assume the role of edge routers. Since satellite terminals are usually hidden behind the complex local area network or multiple layers of CGNAT of satellite operators, they cannot directly route to each other. Therefore, they must rely on relay servers located on the public terrestrial network with fixed IP addresses to achieve end-to-end (i.e., host A to host B) data relay and NAT traversal.

[0006] However, under the extreme physical constraints of narrowband satellite links—such as extremely low bandwidth (e.g., 9.6kbps for Tiantong-1 satellite), high latency (second-level RTT), and high packet loss and reconnection rates—existing network tunneling and networking technologies exhibit the following insurmountable technical defects in this model: (1) The overhead of the multi-layer nested tunnel scheme for the routing information carrying problem is too high. In this model, the public network relay server acts only as a relay node because the satellite link bandwidth, constrained by the usage scenario, cannot participate in dynamic routing calculations between other network nodes (such as OSPF), as running dynamic routing protocols on extremely low-bandwidth satellite links would incur unacceptable signaling overhead. In this case, the source and destination IP addresses of inner packets (e.g., packets from host A to host B) are unknown private network addresses to the public network server.

[0007] To ensure that public network servers know how to accurately deliver data packets from terminal A to terminal B, traditional solutions typically employ a nested Layer 2 / 3 tunnel architecture. For example, an external WireGuard or IPsec tunnel is used to solve the public network penetration problem, while an internal GRE, VXLAN, or L2TP tunnel is nested to carry next-hop MAC / IP routing information for path forwarding. This two- or even three-layer tunnel architecture leads to extremely high packet header bloat. A standard IPv4 header (20 bytes) + UDP (8 bytes) + WireGuard (32 bytes) + GRE (8 bytes) + inner IP (20 bytes) easily exceeds 80 bytes. On narrowband satellite links where MTU is severely limited and bandwidth is extremely precious, pure tunnel overhead exceeding 80 bytes results in extremely low payload rates, and may even prevent the transmission of small packet services (such as IoT control signaling).

[0008] (2) The heartbeat keep-alive strategy for dynamic NAT traversal and roaming recovery issues has excessive overhead. In order to save public IP resources, satellite operators usually implement aggressive CGNAT (carrier-grade NAT) strategies, which makes the public IP and UDP port of satellite terminals very prone to aging and drifting; and when satellite terminals redial or reconnect after disconnection, the terminal IP and NAT mapping information will also change.

[0009] While modern VPN protocols (such as WireGuard) solve the basic NAT traversal problem using UDP hole punching and support some connection roaming capabilities, their mechanisms incur excessive overhead in satellite scenarios. First, to prevent NAT mappings from being cleared by carrier gateways, traditional tunnels rely on high-frequency keep-alive (heartbeat) messages, which is a huge waste on pay-per-use or extremely low-bandwidth satellite links. Second, when a terminal experiences NAT drift, the public server in the WireGuard solution must rely on a complex cryptographic decryption process to re-identify the terminal and restore the connection, lacking a lightweight state recovery mechanism that reuses business data streams.

[0010] (3) The tunnel protocol handshake and encryption overhead are too high to address the security issues of public network transmission. One-way latency in satellite communication links can reach hundreds of milliseconds or even seconds, and the links are extremely unstable. Each time a terminal unexpectedly loses connection and reconnects, data transmission must be restored as quickly as possible. Furthermore, the relay servers of IP internet satellite systems must be deployed with static public IP addresses and exposed to a complex terrestrial public network environment, making them highly vulnerable to malicious attacks. Communication packets are also at risk of being eavesdropped on and intercepted. Therefore, reliable encryption measures must be implemented to ensure the security of the communication process and the server.

[0011] Traditional IPsec (IKEv2) or TLS-based tunnels (such as OpenVPN) require multiple rounds (more than 2 RTTs) of key exchange and authentication handshakes to establish a secure connection. In satellite networks, this means that establishing a single connection can take several to tens of seconds, severely disrupting the real-time performance of communication and the continuity of services. If a 0-RTT scheme is used to generate registration messages with statically pre-configured node information to reduce handshake overhead, the messages may be intercepted due to their predictable patterns, leading to attacks that interfere with the registration and online process of legitimate satellite terminals. Current technologies lack a lightweight protection mechanism that can perform pre-authentication and prevent replay attacks with extremely low overhead under zero-handshake conditions.

[0012] In summary, existing tunneling and networking technologies cannot simultaneously meet the requirements of "complex multi-hop path routing and forwarding" and "dynamic NAT traversal and attack prevention" while compressing the tunnel protocol header overhead and handshake overhead to a range suitable for narrowband satellite physical links.

[0013] Therefore, it is necessary to study a zero-handshake, high-security tunnel forwarding system, method, and readable storage medium for narrowband satellite links to address the shortcomings of existing technologies and solve or mitigate one or more of the aforementioned problems. Summary of the Invention

[0014] In view of this, the present invention provides a zero-handshake high-security tunnel forwarding system, method and readable storage medium for narrowband satellite links, which aims to solve the problems of huge header overhead, time-consuming handshake negotiation and roaming disconnection in existing tunneling protocols under low bandwidth, high latency and dynamic NAT environment of satellite. The present invention achieves high-security high-speed access and seamless roaming by using short identity identifier and zero-handshake key negotiation mechanism to maximally compress tunnel header overhead.

[0015] On the one hand, the present invention provides a zero-handshake high-security tunnel forwarding system for narrowband satellite links, including a terminal device and a relay gateway device, wherein the terminal device and the relay gateway device are connected for communication via a narrowband satellite link; The terminal device includes a key generation unit, a random number calculation unit, a payload encryption unit, and a message assembly and transmission unit connected in sequence. The relay gateway device includes a message parsing and decryption unit, an authentication and verification unit, a mapping management unit, and a service forwarding unit connected in sequence. The message assembly and sending unit communicates with the message parsing and decryption unit. The key generation unit adopts a zero-handshake key derivation mechanism and does not perform handshake interaction with the relay gateway device. The payload encryption unit is used to encrypt the device identity identifier to obtain the ciphertext payload; The message assembly and sending unit adopts a plaintext double-label microtunnel encapsulation mechanism to generate and send microtunnel messages with a total tunnel protocol overhead of no more than 16 bytes. The message parsing and decryption unit is used to receive and decrypt messages; The authentication and verification unit is used to complete the device identity authentication and verification. The mapping management unit is used to establish and maintain tunnel mapping relationships; The service forwarding unit adopts the NAT traversal mechanism.

[0016] In addition to the aspects and any possible implementations described above, a further implementation is provided, wherein the zero-handshake key derivation mechanism of the key generation unit generates a symmetric session key and a basic random number by unidirectionally deriving from a locally generated temporary private key and a pre-set public key of the relay gateway device through an elliptic curve key exchange algorithm, specifically including: Obtain the session state identifier and a temporary asymmetric key pair, wherein the temporary asymmetric key pair includes a temporary private key and a temporary public key; Retrieve the public key of the locally pre-stored relay gateway device; An elliptic curve key exchange algorithm is used, which combines the user's own temporary private key with the public key of the relay gateway device to calculate and generate a symmetric session key and a basic random number.

[0017] In addition to the aspects and any possible implementations described above, a further implementation is provided in which the random number calculation unit employs an implicit nonce mechanism, as detailed below: Obtain the absolute serial number maintained locally in real time; Extract the low-order bits of the absolute sequence number as a local sequence number; The high-order bits of the absolute sequence number are padded with zeros to generate an extended sequence number with the same length as the base random number. Perform a bitwise XOR operation on the extended sequence number and the basic random number to obtain a one-time random number that dynamically changes with the message sequence number without incurring additional transmission overhead.

[0018] In addition to the aspects and any possible implementations described above, a further implementation is provided in which the payload encryption unit works in conjunction with the message assembly and sending unit, specifically for: The payload encryption unit performs symmetric encryption on the physical identity and device configuration information according to the symmetric session key and the one-time random number, generates an initial ciphertext payload and a standard authentication tag, truncates and simplifies the standard authentication tag to obtain a truncated authentication tag, appends the truncated authentication tag to the end of the initial ciphertext payload, and integrates them to obtain a complete ciphertext payload. The plaintext dual-label microtunnel encapsulation mechanism of the message assembly and sending unit is used to concatenate the session state identifier, the target short identity identifier, and the local sequence number into an 8-byte plaintext tunnel header, and concatenate the ciphertext payload with the truncated authentication label to generate a microtunnel message with a total tunnel protocol overhead of no more than 16 bytes and send it. The message assembly and sending unit concatenates the session state identifier, the target physical identity identifier, and the local sequence number to generate a plaintext tunnel header, configures the temporary public key as the plaintext payload, and concatenates and assembles the first message in a fixed order of outer network protocol header, plaintext tunnel header, plaintext payload, and ciphertext payload. The first message is then sent to the relay gateway device via a narrowband satellite wireless link. The target physical identity identifier is a gateway-specific addressing identifier preset by the relay gateway device.

[0019] In addition to the aspects and any possible implementations described above, a further implementation is provided in which the message parsing and decryption unit and the authentication and verification unit work together to complete message decryption and identity authentication, specifically for: The receiving terminal device sends the first message and initializes the corresponding local absolute sequence number for the received session state identifier; The complete absolute sequence number is reconstructed by combining the local sequence number carried in the message with the local absolute sequence number. A bitwise XOR operation is then performed on the complete absolute sequence number and the basic random number to restore the one-time random number. The symmetric session key and the one-time random number are used to decrypt and verify the integrity of the encrypted payload. After the decryption verification is successful, the physical identity identifier of the terminal device is extracted from the decrypted data. Verify whether the physical identity is registered in the preset identity whitelist. If the verification passes, the device authentication is deemed legitimate.

[0020] As described above and in any possible implementation, a further implementation is provided, wherein the mapping management unit is specifically used for: Extract the outer source network protocol address and outer source user datagram protocol port number from the first message and combine them as the outer network address information; In the local memory cache, a six-tuple mapping record is established, which includes the terminal device physical identity identifier, session state identifier, outer source network protocol address, outer source user datagram protocol port number, symmetric session key, and sequence number. Based on the symmetric session key, an acknowledgment message carrying the physical identity of the terminal device is encapsulated and sent back to the terminal device to complete the tunnel link initialization confirmation.

[0021] In addition to the aspects and any possible implementations described above, a further implementation is provided in which the NAT traversal mechanism of the service forwarding unit dynamically overwrites the network address parameters in the mapping record based on the latest outer network address information of the service packet after the decryption verification is passed, thereby achieving NAT traversal without re-handshake and seamless roaming recovery, and completing the tunnel forwarding of the service packet. Specifically, it includes: Receive service messages uploaded by terminal devices and extract the session state identifier and current local sequence number carried in the messages; The corresponding six-tuple mapping record is retrieved using the session state identifier, and the matching symmetric session key and basic random number are obtained. The current one-time random number is calculated in real time by combining the current local sequence number with the basic random number, and the encrypted payload of the service message is decrypted and verified based on the symmetric session key and the current one-time random number. If the decryption verification passes, the current outer network address information of the business message is extracted, and the network address parameters in the mapping record are dynamically updated based on the latest outer network address information.

[0022] As described above and in any possible implementation, a further implementation is provided in which the service forwarding unit is also configured to: Extract the physical identity identifier of the peer device to be communicated from the decrypted business message; Based on the physical identity of the peer device, query the target outer network address information and the target symmetric session key bound in the mapping record; The decrypted business data is re-encrypted using the target symmetric session key to generate re-encrypted business data. Based on the target outer network address information and the re-encrypted service data, a standardized forwarding message is generated and accurately sent to the corresponding terminal device to complete the service tunnel forwarding.

[0023] Based on the aspects described above and any possible implementation, a zero-handshake high-security tunnel forwarding method for narrowband satellite links is further provided to implement a zero-handshake high-security tunnel forwarding system for narrowband satellite links, comprising the following steps: S1. Obtain the session state identifier and a temporary asymmetric key pair, wherein the temporary asymmetric key pair includes a temporary private key and a temporary public key; S2. Determine the symmetric session key and the basic random number based on the temporary private key and the preset relay device public key; S3. Determine a one-time random number based on the local sequence number and the basic random number; S4. Encrypt the physical identity identifier using the symmetric session key and the one-time random number to obtain the ciphertext payload; S5. Assemble a first message based on the session state identifier, target physical identity identifier, local sequence number, temporary public key and ciphertext payload, and send the first message to the relay end; S6. Receive the first message, parse the symmetric session key and the basic random number according to the temporary public key and the local private key, calculate a one-time random number according to the local sequence number and the basic random number, and decrypt the ciphertext payload through the symmetric session key and the one-time random number to obtain the physical identity identifier of the communication terminal; S7. Establish a corresponding mapping relationship based on the physical identity identifier of the communication terminal, the session state identifier, the outer network address information of the first message, the symmetric session key and the sequence number; S8. Receive uploaded service messages; S9. Based on the established mapping relationship, complete the tunnel forwarding of the service message.

[0024] In addition to the aspects and any possible implementations described above, a further implementation is provided: a readable storage medium storing a computer-executable program that, when executed by a processor, implements all the steps of the zero-handshake high-security tunneling forwarding method for narrowband satellite links.

[0025] Compared with the prior art, the present invention can achieve the following technical effects: 1) Eliminate the overhead of dynamic routing protocols to achieve lightweight satellite link public network routing relay. To address the pain point that public network relay servers participating in routing calculations in heterogeneous networks via satellite links can cause massive signaling storms, this invention designs an independent plaintext short ID in its micro-packet header. Without parsing inner IP data or running any dynamic routing protocols such as BGP / OSPF, the server can perform multi-hop target addressing and key lookup solely based on the short ID, playing the role of an efficient and stateless "virtual switch" and adapting to satellite link heterogeneous network interconnection scenarios with multiple nodes and multi-hop topologies. 2) Completely eliminate protocol handshake delay, achieving ultra-fast network access with 0-RTT. To address the issues of high latency and frequent disconnections in one-way satellite links, this invention designs a "first packet registration blind transmission" mechanism based on ECDH one-way key derivation. The terminal does not need to conduct multiple rounds of handshake negotiation with the gateway. Instead, it instantly generates a temporary session state and sends an encrypted first packet locally. This reduces the access latency of the secure tunnel from multiple RTTs (round-trip time, taking several to tens of seconds) in traditional solutions to 0-RTT (theoretical physical minimum), greatly ensuring the continuity and real-time performance of satellite mobile services. 3) Innovative follow-up keep-alive mechanism to achieve zero-overhead NAT traversal and seamless roaming recovery. To address the "IP / port drift" problem caused by frequent cross-beam switching in satellite communication and aging CGNAT (Network Address Translation) protocols used by operators, this invention abandons the traditional approach of relying on high-frequency heartbeat packets to maintain state in tunnels. Instead, by constructing and dynamically maintaining a six-tuple (based on sessionID addressing) on ​​the server side, the server automatically overwrites the routing state with the latest outer IP and port of the packet each time a service packet is successfully decrypted. This "follow-up update" mechanism allows terminals to instantly resume bidirectional communication without re-initiating any handshake signaling when network roaming occurs, as long as the first subsequent service packet is delivered, achieving true "seamless roaming." 4) Breaking through the overhead bottleneck of traditional encrypted tunnel protocols, achieving micro-tunnel encapsulation with extremely low overhead. To address the overhead disaster (typically over 32 bytes) caused by multi-layered nesting, large Nonce (random number), and complete MAC (authentication label) when carrying multi-hop routing information in traditional secure tunnels (such as IPsec and WireGuard), this invention innovatively proposes a "plaintext dual-label based on physical identity and secure session decoupling" and an "implicit Nonce and truncated MAC combination" mechanism. While ensuring anti-tampering and anti-replay security strength, the additional overhead of the entire tunnel protocol is compressed to a maximum of 16 bytes (8-byte plaintext header + 8-byte trailer). Compared with existing technologies, on narrowband satellite links at the 5kbps level, this method reduces the tunnel protocol header overhead by more than 50%, freeing up extremely scarce satellite bandwidth resources.

[0026] 5) Fast status indexing and pre-authentication effectively resist DoS attacks. To address the risks of malicious probing and CPU exhaustion attacks on the exposed surface of public servers, this invention places the session ID (session index) and local sequence number in the plaintext header. The relay server can intercept replay attack packets by looking up tables and verifying sequence numbers without performing high-overhead public key decryption operations. Combined with the silent drop mechanism in case of a miss, attackers cannot obtain any feedback, thus achieving a high level of public network protection in zero-handshake scenarios.

[0027] Of course, any product implementing this invention does not necessarily need to achieve all of the technical effects described above at the same time. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments 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.

[0029] Figure 1 This is a simplified network model diagram of a satellite link segment as described in the background section of this invention; Figure 2 This is a general logic diagram of a zero-handshake high-security tunnel forwarding method for narrowband satellite links provided in one embodiment of the present invention; Figure 3 This is a diagram of the registration and heartbeat message format provided in one embodiment of the present invention; Figure 4 This is a service forwarding message format diagram provided in one embodiment of the present invention; Figure 5This is a flowchart of a zero-handshake (0-RTT) terminal access process based on ECDH provided in one embodiment of the present invention; Figure 6 This is a server-side authentication, state machine establishment, and six-tuple management diagram provided in one embodiment of the present invention. Detailed Implementation

[0030] To better understand the technical solution of the present invention, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0031] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0032] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0033] This invention provides a zero-handshake, high-security tunnel forwarding system and method for narrowband satellite links. This method establishes a secure tunnel connection between the communication device and the relay device through a temporary key negotiation mechanism and a one-time dynamic random number generation technique, achieving privacy protection of the physical identity of the communication device and secure forwarding of service data. The invention will now be described in detail with reference to specific embodiments.

[0034] The zero-handshake high-security tunnel forwarding system for narrowband satellite links includes a terminal device and a relay gateway device, wherein the terminal device and the relay gateway device are connected via a narrowband satellite link. The terminal device includes a key generation unit, a random number calculation unit, a payload encryption unit, and a message assembly and transmission unit connected in sequence. The relay gateway device includes a message parsing and decryption unit, an authentication and verification unit, a mapping management unit, and a service forwarding unit connected in sequence. The message assembly and sending unit communicates with the message parsing and decryption unit. The key generation unit adopts a zero-handshake key derivation mechanism and does not perform handshake interaction with the relay gateway device. The payload encryption unit is used to encrypt the device identity identifier to obtain the ciphertext payload; The message assembly and sending unit adopts a plaintext double-label microtunnel encapsulation mechanism to generate and send microtunnel messages with a total tunnel protocol overhead of no more than 16 bytes. The message parsing and decryption unit is used to receive and decrypt messages; The authentication and verification unit is used to complete the device identity authentication and verification. The mapping management unit is used to establish and maintain tunnel mapping relationships; The service forwarding unit adopts the NAT traversal mechanism.

[0035] The zero-handshake key derivation mechanism of the key generation unit generates a symmetric session key and a basic random number by using a locally generated temporary private key and a pre-set public key of the relay gateway device through an elliptic curve key exchange algorithm. Specifically, it includes: Obtain the session state identifier and a temporary asymmetric key pair, wherein the temporary asymmetric key pair includes a temporary private key and a temporary public key; Retrieve the public key of the locally pre-stored relay gateway device; An elliptic curve key exchange algorithm is used, which combines the user's own temporary private key with the public key of the relay gateway device to calculate and generate a symmetric session key and a basic random number.

[0036] The random number calculation unit adopts an implicit nonce mechanism, as detailed below: Obtain the absolute serial number maintained locally in real time; Extract the low-order bits of the absolute sequence number as a local sequence number; The high-order bits of the absolute sequence number are padded with zeros to generate an extended sequence number with the same length as the base random number. Perform a bitwise XOR operation on the extended sequence number and the basic random number to obtain a one-time random number that dynamically changes with the message sequence number without incurring additional transmission overhead.

[0037] The payload encryption unit works in conjunction with the message assembly and transmission unit, specifically for: The payload encryption unit performs symmetric encryption on the physical identity and device configuration information according to the symmetric session key and the one-time random number, generates an initial ciphertext payload and a standard authentication tag, truncates and simplifies the standard authentication tag to obtain a truncated authentication tag, appends the truncated authentication tag to the end of the initial ciphertext payload, and integrates them to obtain a complete ciphertext payload. The plaintext dual-label microtunnel encapsulation mechanism of the message assembly and sending unit is used to concatenate the session state identifier, the target short identity identifier, and the local sequence number into an 8-byte plaintext tunnel header, and concatenate the ciphertext payload with the truncated authentication label to generate a microtunnel message with a total tunnel protocol overhead of no more than 16 bytes and send it. The message assembly and sending unit concatenates the session state identifier, the target physical identity identifier, and the local sequence number to generate a plaintext tunnel header, configures the temporary public key as the plaintext payload, and concatenates and assembles the first message in a fixed order of outer network protocol header, plaintext tunnel header, plaintext payload, and ciphertext payload. The first message is then sent to the relay gateway device via a narrowband satellite wireless link. The target physical identity identifier is a gateway-specific addressing identifier preset by the relay gateway device.

[0038] The message parsing and decryption unit and the authentication and verification unit work together to complete message decryption and identity authentication, specifically for: The receiving terminal device sends the first message and initializes the corresponding local absolute sequence number for the received session state identifier; The complete absolute sequence number is reconstructed by combining the local sequence number carried in the message with the local absolute sequence number. A bitwise XOR operation is then performed on the complete absolute sequence number and the basic random number to restore the one-time random number. The symmetric session key and the one-time random number are used to decrypt and verify the integrity of the encrypted payload. After the decryption verification is successful, the physical identity identifier of the terminal device is extracted from the decrypted data. Verify whether the physical identity is registered in the preset identity whitelist. If the verification passes, the device authentication is deemed legitimate.

[0039] The mapping management unit is specifically used for: Extract the outer source network protocol address and outer source user datagram protocol port number from the first message and combine them as the outer network address information; In the local memory cache, a six-tuple mapping record is established, which includes the terminal device physical identity identifier, session state identifier, outer source network protocol address, outer source user datagram protocol port number, symmetric session key, and sequence number. Based on the symmetric session key, an acknowledgment message carrying the physical identity of the terminal device is encapsulated and sent back to the terminal device to complete the tunnel link initialization confirmation.

[0040] The following NAT traversal mechanism of the service forwarding unit dynamically overwrites the network address parameters in the mapping record based on the latest outer network address information of the service packet after the decryption verification is successful, so as to achieve following NAT traversal and seamless roaming recovery without re-handshaking, and complete the tunnel forwarding of the service packet. Specifically, it includes: Receive service messages uploaded by terminal devices and extract the session state identifier and current local sequence number carried in the messages; The corresponding six-tuple mapping record is retrieved using the session state identifier, and the matching symmetric session key and basic random number are obtained. The current one-time random number is calculated in real time by combining the current local sequence number with the basic random number, and the encrypted payload of the service message is decrypted and verified based on the symmetric session key and the current one-time random number. If the decryption verification passes, the current outer network address information of the business message is extracted, and the network address parameters in the mapping record are dynamically updated based on the latest outer network address information.

[0041] The service forwarding unit is also used for: Extract the physical identity identifier of the peer device to be communicated from the decrypted business message; Based on the physical identity of the peer device, query the target outer network address information and the target symmetric session key bound in the mapping record; The decrypted business data is re-encrypted using the target symmetric session key to generate re-encrypted business data. Based on the target outer network address information and the re-encrypted service data, a standardized forwarding message is generated and accurately sent to the corresponding terminal device to complete the service tunnel forwarding.

[0042] The zero-handshake, high-security tunnel forwarding method for narrowband satellite links includes the following steps: Step S1: The first communication device obtains a session state identifier and a temporary asymmetric key pair, wherein the temporary asymmetric key pair includes a temporary private key and a temporary public key.

[0043] In this embodiment, before initiating a tunnel establishment request, the first communication device needs to generate temporary key material for this session. The session state identifier is a unique identifier used to distinguish different communication sessions. This identifier remains unchanged throughout the entire session lifecycle and is used by the relay device to quickly locate session context information. The generation of the session state identifier can be implemented in several ways. In one implementation, the first communication device can generate the session state identifier based on a combination of the current timestamp and an internal device counter. By concatenating the low-order bits of the millisecond-level timestamp with the incrementing counter, the uniqueness of the session state identifier within the device's local scope is ensured. In another implementation, the first communication device can also generate a fixed-length random byte sequence as the session state identifier using a pseudo-random number generator. The length of this random byte sequence is typically eight or sixteen bytes, ensuring global uniqueness in a statistical sense. Once the session state identifier is generated, the first communication device associates and stores it with the relevant parameters of this session, establishing a local session context record.

[0044] The generation of temporary asymmetric key pairs is the core operation of this step. Temporary asymmetric key pairs are generated using elliptic curve cryptography (ECC). Compared to traditional public-key cryptography algorithms, ECC offers shorter key lengths and higher computational efficiency for the same security strength. When generating temporary asymmetric key pairs, the first communication device first selects predefined elliptic curve parameters, including the coefficients of the curve equation, the coordinates of the base point, and the order of the curve. In one implementation, the first communication device can use a 256-bit elliptic curve, which provides the equivalent security strength of a 128-bit symmetric key while maintaining a high key generation speed. The first communication device generates a random integer within the order of the curve using a secure random number generator as a temporary private key. This random integer must meet cryptographic security requirements to ensure its unpredictability. After generating the temporary private key, the first communication device uses elliptic curve dot multiplication to perform a scalar multiplication of the base point and the temporary private key, obtaining a point on the elliptic curve as the temporary public key. The temporary public key is typically stored in a compressed format, retaining only the sign bits of the x and y coordinates of the point, which reduces the public key length by approximately half.

[0045] Temporary asymmetric key pairs are single-use; a completely new key pair is generated each time a session is established, and the temporary private key is destroyed immediately after the session ends. This temporary key mechanism enables forward confidentiality. Even if an attacker obtains the device's long-term key material at some point in the future, they will not be able to decrypt the data transmitted in historical sessions. After generating the temporary asymmetric key pair, the first communication device stores the temporary private key in a protected memory area and sets access control to prevent unauthorized reading by other processes or modules. The temporary public key is then sent as part of the plaintext payload to the relay device in subsequent steps for the key negotiation process. The generation process of temporary asymmetric key pairs is usually completed within milliseconds and does not significantly affect the response performance of the communication device.

[0046] Step S2: The first communication device determines the symmetric session key and the basic random number based on the temporary private key and the preset relay device public key.

[0047] In this step, the first communication device uses its own generated temporary private key and the pre-acquired public key of the relay device to derive the shared key material through an elliptic curve key exchange algorithm. The relay device's public key is its long-term public key, generated and publicly released during deployment. All communication devices needing to establish a secure tunnel with this relay device must pre-acquire and store this public key. The distribution of the relay device's public key can be achieved in various ways. In one implementation, the public key can be pre-installed in the firmware at the device's factory, with a secure boot mechanism ensuring its integrity. In another implementation, the communication device can also obtain the relay device's public key through an out-of-band authentication channel upon first network access, for example, by scanning a QR code containing the public key information or downloading a public key certificate from a trusted key distribution server. When storing the relay device's public key, the first communication device also saves the fingerprint information of the public key for subsequent verification of its validity.

[0048] The core principle of elliptic curve key exchange (ECS) algorithms lies in leveraging the difficulty of the discrete logarithm problem on elliptic curves, enabling communicating parties to derive the same shared key without directly exchanging keys. The first communicating device uses its temporary private key to perform a scalar multiplication operation on the elliptic curve points corresponding to the relay device's public key, obtaining an intermediate point whose x-coordinate contains the original material of the shared key. Due to the commutativity of elliptic curve point multiplication, the relay device uses its long-term private key to perform the same scalar multiplication operation on the first communicating device's temporary public key, also obtaining the same intermediate point. The x-coordinate of this intermediate point is a large integer, typically 32 bytes long. Directly using this integer as key material poses a security risk because it may contain statistical biases or have a format that does not meet key usage requirements.

[0049] To convert the midpoint x-coordinate into cryptographically acceptable key material, the first communication device needs to perform key derivation processing on this x-coordinate. The key derivation process employs a hash-based key derivation function, which can expand input data of arbitrary length into a key output of a specified length while ensuring that the output key material has good randomness and uniform distribution characteristics. In one implementation, the first communication device can use a standard key derivation function that accepts the midpoint x-coordinate as input key material and can accept additional contextual information as derivation parameters, such as session state identifiers and protocol version numbers. Internally, the key derivation function uses a cryptographic hash algorithm for multiple rounds of iterative computation. In each round, the output of the previous round is mixed with a counter value until a sufficiently long key material is generated.

[0050] The symmetric session key is the first few bytes extracted from the derived key material. This key is used for symmetric encryption of subsequent business data. The symmetric session key is typically 32 bytes long, corresponding to a 256-bit key strength, which is resistant to all currently known cryptanalysis attacks. The basic random number is the last few bytes extracted from the derived key material. This random number is combined with the sequence number in subsequent steps to generate a one-time random number to enhance the security of encryption operations. The basic random number is the same length as the symmetric session key, also 32 bytes. By using the output of the key derivation function in segments, multiple independent cryptographic parameters can be derived from a single shared key material, improving the utilization efficiency of the key material.

[0051] In practical applications, the first communication device optimizes the key derivation process. Since elliptic curve multiplication and key derivation functions have high computational complexity, the first communication device can utilize hardware acceleration modules or cryptographic coprocessors to speed up these operations. On communication devices equipped with hardware encryption engines, the key derivation process can be completed in sub-millisecond time, without affecting the user-perceived connection establishment latency. After deriving the symmetric session key and basic random number, the first communication device immediately stores these key materials in a secure memory area and clears intermediate calculation results to prevent key materials from remaining in memory and being maliciously read. The symmetric session key and basic random number remain unchanged throughout the entire session lifecycle and are only securely destroyed when the session terminates.

[0052] Step S21: The first communication device obtains the pre-stored public key of the relay device.

[0053] Before performing key negotiation, the first communication device needs to read the relay device's public key from its local storage medium. The storage location of the relay device's public key depends on the device's security architecture design. In one implementation, the relay device's public key can be stored in the device's read-only storage area, such as a firmware partition or a dedicated key storage chip, using hardware-level write protection mechanisms to prevent tampering. In another implementation, the relay device's public key can also be stored in a protected configuration file, ensuring its integrity through digital signatures or message authentication codes. When reading the relay device's public key, the first communication device first verifies the public key's format validity and checks whether the public key conforms to the elliptic curve point encoding standard, ensuring that the point corresponding to the public key lies on a predefined elliptic curve.

[0054] In deployment scenarios with multiple relay devices, the primary communication device may need to store the public keys of multiple relay devices. In this case, the primary communication device maintains a list of relay device public keys, where each entry contains the relay device's identification information and its corresponding public key. The relay device identification information can be the relay device's network address, device serial number, or domain name, etc. When initiating a tunnel establishment request, the primary communication device searches for the corresponding public key in the public key list based on the target relay device's identification information. To improve search efficiency, the primary communication device can create an index structure for the public key list, such as using a hash table or balanced tree to organize the public key entries, reducing the search time complexity to logarithmic levels. Updates to the public key list are implemented through a secure key management protocol. When a relay device's public key changes, the primary communication device can promptly obtain the new public key and update its local storage.

[0055] Managing the validity period of relay device public keys is a crucial step in the key acquisition process. Each relay device public key is associated with an effective date and an expiration date. Before using a public key, the first communication device checks if the current time is within the public key's validity period. For public keys that are about to expire, the first communication device can trigger a public key update process in advance, obtaining a new public key from the key management server to achieve a smooth transition. After a public key expires, the first communication device will refuse to use it to establish a new tunnel connection. However, for existing session connections, the original session key can continue to be used to complete data transmission, avoiding session interruption. Setting the public key's validity period requires a trade-off between security and availability. A validity period that is too short increases the complexity of key management, while a validity period that is too long may increase the risk of key leakage.

[0056] Step S22: The first communication device calculates the symmetric session key based on the temporary private key and the public key of the relay device using an elliptic curve key exchange algorithm.

[0057] The execution of the elliptic curve key exchange algorithm is the core step in generating symmetric session keys. The first communication device decompresses the relay device's public key from its compressed format into complete elliptic curve point coordinates. The decompression process requires calculating the corresponding ordinate based on the x-coordinate and sign bit. The ordinate of an elliptic curve point satisfies the curve equation; by solving the curve equation and combining it with the sign bit information, the value of the ordinate can be uniquely determined. The decompressed relay device public key is a point structure containing x-coordinates and ordinates, located on a predefined elliptic curve.

[0058] Next, the first communication device performs elliptic curve multiplication, calculating the scalar product of the temporary private key and the relay device's public key. Multiplication is the most time-consuming operation in elliptic curve cryptography, with computational complexity proportional to the bit length of the private key. On a 256-bit elliptic curve, multiplication typically requires over two hundred elliptic curve additions and doubling operations. To improve computational efficiency, the first communication device can employ various optimization algorithms. In one implementation, the first communication device can use a window-based multiplication algorithm, which decomposes the multiplication operation into multiple table lookups and additions by pre-calculating multiple base points, thus reducing the number of doubling operations. In another implementation, the first communication device can also use the Montgomery ladder algorithm, which has constant-time characteristics and can resist time-based side-channel attacks.

[0059] The result of the dot product operation is a point on the elliptic curve, and the x-coordinate of this point contains the raw material for the shared key. The first communication device extracts the x-coordinate of this point and converts it into a fixed-length byte sequence. The x-coordinate is typically encoded in big-endian byte order, with the most significant byte first and the least significant byte last. For x-coordinates that are too short, zeros are padded to the standard length in the high-order bits. The x-coordinate byte sequence is used as input to the key derivation function to generate the final symmetric session key.

[0060] The execution of the key derivation function consists of several stages. The first stage is the extraction stage, which uses a cryptographic hash algorithm to compress the input key material to obtain a fixed-length pseudo-random key. The extraction stage can accept an optional salt parameter, which is typically a sequence of all-zero bytes or a predefined constant. The second stage is the expansion stage, which uses a hash-based message authentication code algorithm to iteratively expand the pseudo-random key, generating an output key material of the required length. Each iteration of the expansion stage mixes the output of the previous iteration, the counter value, and optional context information to ensure that every byte of the output depends on the input key material and all context parameters.

[0061] The symmetric session key is extracted from the first few bytes output by the key derivation function. The extraction process is a simple byte copying operation; the first communication device uses the first 32 bytes of the output byte sequence as the symmetric session key. This key is used as a key parameter in subsequent encryption operations for the symmetric encryption algorithm. The entropy value of the symmetric session key is equivalent to the entropy value of the shared key material, possessing sufficient randomness and unpredictability to resist brute-force and statistical analysis attacks. After obtaining the symmetric session key, the first communication device stores it in a protected key cache and sets usage attributes for the key, such as allowing the key to be used only for encryption operations and preventing its export. The access control mechanism of the key management module ensures the secure use of the key.

[0062] Step S23: The first communication device calculates the basic random number based on the temporary private key and the public key of the relay device using the elliptic curve key exchange algorithm.

[0063] The generation process of the basic random number uses the same key derivation function as the generation process of the symmetric session key, but the extracted byte positions differ. The first communication device extracts the basic random number from the latter part of the key derivation function's output bytes; specifically, it uses the 32 bytes offset 32 ​​bytes from the output byte sequence as the basic random number. By extracting different segments of bytes from the same key derivation output, the independence between the symmetric session key and the basic random number can be ensured. Even if an attacker obtains one parameter, they cannot deduce the value of the other parameter.

[0064] The base random number remains constant throughout the session, but is combined with a changing sequence number to generate a different one-time random number for each encryption operation. This design provides a unique random number input for each encryption operation while maintaining low computational overhead, preventing cryptographic attacks caused by the reuse of random numbers. The base random number has the same length as the symmetric session key, 32 bytes, which provides sufficient random space to ensure the uniqueness of the one-time random number even in high-frequency communication scenarios.

[0065] In some implementations, the generation of the base random number can incorporate additional contextual information. For example, the first communication device can add a communication direction identifier to the context parameters of the key derivation function to distinguish the base random numbers used for uplink and downlink communication. By introducing the direction identifier, even if both communicating parties use the same session key, the one-time random numbers for uplink and downlink data will not conflict. In another implementation, the first communication device can also add an application layer protocol identifier or a service type identifier to the context parameters, allowing different types of service data to use different base random number derivation spaces, further enhancing cryptographic isolation.

[0066] The storage and protection of the basic random numbers also require strict security measures. After generating the basic random numbers, the first communication device stores them along with the symmetric session key in a session key cache structure. This cache structure is typically located in the device's secure memory area and is protected by memory access control mechanisms to prevent unauthorized processes from reading the key material. On communication devices supporting hardware security modules, the basic random numbers can be stored in the internal memory of the hardware security module, ensuring that the key material cannot be obtained by software-level attacks through hardware-level isolation mechanisms. The basic random numbers need to be securely erased at the end of the session. The erasure process typically employs a multi-overwrite method, repeatedly writing random or fixed-pattern data to the memory area where the key resides, ensuring that the key material cannot be recovered through memory residue analysis techniques.

[0067] Step S3: The first communication device determines a one-time random number based on the local sequence number and the basic random number.

[0068] One-time random number generation is a crucial mechanism for ensuring the security of each encryption operation. In symmetric encryption algorithms, especially when using authenticated encryption modes, the uniqueness of random numbers directly affects the security of the encryption system. If the same random number is reused with the same key, an attacker may be able to deduce the plaintext information by analyzing the differences between the ciphertext and even recover the encryption key. Traditional random number generation schemes typically rely on true random number generators or pseudo-random number generators, but these schemes may face performance bottlenecks or random number exhaustion problems in high-frequency communication scenarios. The one-time random number generation scheme adopted in this invention combines a monotonically increasing sequence number with a fixed base random number, which ensures the uniqueness of the random number while avoiding the overhead of frequently calling the random number generator.

[0069] The local sequence number is the low-order part extracted from the absolute sequence number, which is a monotonically increasing counter that increments once for each message sent. The first communication device sets the absolute sequence number to zero during session initialization. Thereafter, before each message transmission, it reads the current absolute sequence number and increments it immediately after use. The absolute sequence number is typically 64 bits wide, capable of supporting a very large number of message transmissions without overflow. In typical communication scenarios, even with continuous transmission at a rate of one million messages per second, the 64-bit sequence number can support continuous use for over half a million years.

[0070] Extracting local sequence numbers is done to save transmission overhead in messages. Carrying the complete 64-bit absolute sequence number in every message would occupy eight bytes of message space. By transmitting only the lower-order bits of the absolute sequence number, such as the lower 16 bits or the lower 24 bits, the sequence number field length can be reduced to two or three bytes. The receiver can reconstruct the complete absolute sequence number from the received local sequence number using its locally maintained absolute sequence number state. This sequence number compression mechanism significantly reduces protocol overhead while maintaining sequence number uniqueness, making it particularly suitable for bandwidth-constrained or message-length-sensitive applications.

[0071] Step S31: The first communication device obtains the locally maintained absolute serial number.

[0072] The first communication device maintains an independent absolute sequence number counter for each session. This counter is stored in the session context structure, which contains all session-related state information, such as the session state identifier, symmetric session key, basic random number, and absolute sequence number. The absolute sequence number counter is initialized to zero when the session is established and then increments continuously as packets are sent. The reading operation of the absolute sequence number needs to be atomic, especially in multi-threaded or multi-process environments. Synchronization mechanisms are required to prevent multiple execution flows from simultaneously reading and modifying the sequence number, thus avoiding the reuse of the sequence number.

[0073] In one implementation, the first communication device can use atomic operation instructions to read and increment the sequence number. Modern processors typically provide atomic addition instructions or compare-swap instructions, which can complete the reading, modification, and writing back of variables in a single indivisible operation, ensuring that no race conditions occur even in a multi-core concurrent environment. By using atomic operations, the first communication device can avoid introducing heavyweight synchronization mechanisms such as mutexes, reducing the latency overhead of sequence number operations.

[0074] In another implementation, the first communication device can also maintain an independent sequence number subspace for each sending thread. For example, if the communication device uses four threads to send messages concurrently, the 64-bit sequence number space can be partitioned by the high-order bits, with each thread using a different high-order prefix and independently incrementing the sequence number within its own subspace. This scheme can completely eliminate sequence number contention between threads, but it requires additional thread identification information to be carried in the message, and the receiver also needs to maintain an independent sequence number state for each sending thread.

[0075] Persistent storage of absolute serial numbers is necessary in certain application scenarios. If the communication device may restart or the session needs to be resumed after a device restart, the first communication device needs to periodically save the current value of the absolute serial number to non-volatile storage media. After the device restarts, the first communication device reads the saved serial number value from the storage media and continues to increment it, ensuring the global monotonicity of the serial number throughout the device's lifecycle. To reduce the frequency of persistent storage, the first communication device can adopt a checkpointing mechanism, performing a storage operation only when the serial number grows to a specific threshold. Even if the device restarts abnormally between two storage operations, only a small amount of serial number space will be lost, without affecting the overall security of the system.

[0076] Step S32: The first communication device extracts the low-order data of the absolute sequence number as the local sequence number.

[0077] The extraction of the local sequence number is achieved through bitwise operations, resulting in extremely high execution efficiency. The first communication device uses a bitwise AND operation to perform a bitwise AND operation between the absolute sequence number and the mask. The low-order bits of the mask are all one, and the high-order bits are all zero. The result of the AND operation is the low-order part of the absolute sequence number. For example, if it is necessary to extract the lower 16 bits as the local sequence number, and the mask value is hexadecimal zero x 0000FFFF, the result of calculating the bitwise AND between the absolute sequence number and the mask is the lower 16 bits of the absolute sequence number.

[0078] The choice of local sequence number bit width requires a trade-off between transmission overhead and sequence number reconstruction complexity. Shorter local sequence numbers reduce message overhead but increase the difficulty of sequence number reconstruction at the receiver, as the receiver needs to handle sequence number wrapping more frequently. Longer local sequence numbers, while increasing transmission overhead, simplify the receiver's processing logic and reduce the risk of sequence number reconstruction errors. In typical applications, the local sequence number bit width is chosen to be either 16 bits or 24 bits. A 16-bit local sequence number can represent over 65,000 different sequence number values, and the receiver can accurately reconstruct the absolute sequence number within normal network jitter and out-of-order ranges. A 24-bit local sequence number can represent over 16 million sequence number values ​​and is suitable for network environments with high packet loss rates or large out-of-order packets.

[0079] In multicast or broadcast communication scenarios, extracting local sequence numbers requires considering the sequence number synchronization issue among multiple receivers. Since different receivers may begin receiving messages at different times, their locally maintained initial values ​​for absolute sequence numbers may differ. To ensure all receivers can correctly reconstruct the sequence number, the sender needs to periodically include the complete absolute sequence number in the message as a synchronization point for the receivers. After receiving a message with the complete sequence number, the receiver updates its local absolute sequence number baseline value and subsequently calculates the absolute sequence number of the current message based on the increment of the local sequence number.

[0080] Step S33: The first communication device performs zero-padding on the high-order bits of the absolute sequence number to obtain an extended sequence number. The length of the extended sequence number is the same as the length of the base random number.

[0081] Zero-padding is an operation that extends the absolute sequence number from its original bit width to the same bit width as the base random number. The base random number is 32 bytes long, or 256 bits, while the original bit width of the absolute sequence number is 64 bits. Zero-padding adds 192 bits of zero to the high-order bits of the absolute sequence number, making the extended sequence number 256 bits long. This extension operation ensures that the two operands in subsequent XOR operations have the same length, allowing for bit-by-bit correspondence operations.

[0082] The implementation of zero-padding depends on the data storage format. In big-endian byte order, the most significant byte is located at the lowest address, and the least significant byte is located at the highest address. The first communication device allocates a 32-byte buffer, fills the first 24 bytes of the buffer with zeros, and then copies the 8 bytes of absolute sequence number data in big-endian format to the last 8 bytes of the buffer. In little-endian byte order, the least significant byte is located at the lowest address, and the most significant byte is located at the highest address. The first communication device copies the 8 bytes of absolute sequence number data to the first 8 bytes of the buffer, and then fills the last 24 bytes with zeros. Regardless of the byte order used, the zero-padding extended sequence number is numerically equal to the original absolute sequence number; only the bit width is increased.

[0083] The generation of extended serial numbers does not involve complex mathematical operations, requiring only memory copying and padding, thus resulting in extremely high execution efficiency. On modern processors, a 32-byte memory padding operation can typically be completed within a few clock cycles. To further optimize performance, the first communication device can use vectorized instructions to pad multiple bytes at once. For example, using a 128-bit vector register, 24 bytes of zero padding can be completed in two vector storage operations. On processors supporting 256-bit vector instructions, the entire extended serial number can even be constructed in a single vector operation.

[0084] The layout of the extended sequence number in memory needs to consider the efficiency of subsequent XOR operations. If the extended sequence number and the basic random number are aligned in memory, the XOR operation can be performed directly at the aligned memory address, avoiding the performance penalty caused by unaligned access. When allocating the extended sequence number buffer, the first communication device ensures that the starting address of the buffer is aligned according to the processor's cache line size, typically 64 bytes. This alignment not only improves the efficiency of the XOR operation but also reduces cache line crossings, lowering memory access latency.

[0085] Step S34: The first communication device performs a bitwise XOR operation on the extended sequence number and the basic random number to obtain the one-time random number.

[0086] The bitwise XOR operation is the core step in generating one-time random numbers. XOR has excellent cryptographic properties; it can thoroughly mix the randomness of the two inputs, and the output result is statistically close to a uniform distribution. When one of the inputs is truly random or pseudo-random data, the output of the XOR operation also has the same random property. In this invention, the basic random number is high-entropy data generated through a key derivation function. Although the extended sequence number is monotonically increasing, its predictability is completely masked by XORing it with the basic random number. The generated one-time random number is unique and unpredictable in each encryption operation.

[0087] Bitwise XOR is one of the most fundamental logical operations at the hardware level, and modern processors provide efficient XOR instructions. For 32 bytes of data, the first communication device needs to perform 32 byte-level XOR operations or fewer. On a 64-bit processor, an 8-byte-wide XOR instruction can be used, requiring only four XOR operations to complete the calculation of a one-time random number. On processors that support vectorized instructions, 128-bit or 256-bit vectorized XOR instructions can be used to further reduce the number of instruction executions, compressing the computation time to the nanosecond level.

[0088] The generation process of a one-time random number is completely deterministic. Given the same extended sequence number and base random number, the same one-time random number will always be obtained. This determinism allows both communicating parties to independently generate the same one-time random number. As long as both parties have a consistent understanding of the sequence number, they can use the same one-time random number for encryption and decryption operations. Furthermore, since the sequence number increments with each communication, the one-time random number also changes accordingly, ensuring that the random number used in each encryption operation is unique.

[0089] In some implementations, the first communication device can perform batch optimization of the one-time random number generation process. If the first communication device needs to send multiple messages consecutively, it can pre-calculate one-time random numbers corresponding to several future sequence numbers and cache these one-time random numbers in memory. When actually sending messages, the corresponding one-time random numbers are read directly from the cache, avoiding repeated execution of expansion and XOR operations. This batch pre-computation scheme can significantly reduce the latency of encryption operations in high-throughput communication scenarios, but it requires additional memory space to store the pre-computed one-time random numbers, and the pre-computation cache needs to be cleared when the sequence number changes or the session key is updated.

[0090] Once a one-time random number is generated, the first communication device immediately uses it for subsequent encryption operations. This one-time random number does not need to be stored long-term and can be discarded after each encryption operation. This disposable characteristic simplifies key management complexity and avoids the storage and protection issues associated with one-time random numbers. Furthermore, because the one-time random number can be quickly recalculated based on the sequence number and the base random number, even on memory-constrained embedded devices, the caching requirements for one-time random numbers will not consume excessive resources.

[0091] One-time random numbers are used as initialization vectors or random number parameters in authentication encryption algorithms. Authentication encryption algorithms require that the random number used in each encryption operation must be unique; otherwise, it will lead to serious security vulnerabilities. By XORing a monotonically increasing sequence number with a fixed base random number, the one-time random number generation scheme of this invention guarantees the uniqueness of the random number from a fundamental mechanism. As long as the sequence number is not repeated, the one-time random number will not be repeated. Furthermore, the monotonically increasing characteristic of the sequence number naturally avoids the possibility of sequence number duplication, thus reliably ensuring the uniqueness of the one-time random number.

[0092] In practical applications, the first communication device monitors the usage range of the sequence number. When the absolute sequence number approaches its maximum value, the first communication device triggers a session renegotiation process, establishing a new session connection with the relay device, generating a new temporary key pair, a symmetric session key, and a basic random number, and resetting the absolute sequence number to zero. This periodic key update mechanism not only avoids the problem of sequence number overflow but also enhances the forward confidentiality of the system; even if the key materials of one session are leaked, it will not affect the security of other sessions. In high-frequency communication scenarios, the session renegotiation trigger threshold can be set lower, for example, performing a key update when the sequence number reaches 4.2 billion, ensuring that the system always operates within a secure parameter range.

[0093] Step S4: The first communication device encrypts its physical identity identifier using the symmetric session key and the one-time random number to obtain the ciphertext payload.

[0094] Specifically, after completing key negotiation and random number generation, the first communication device needs to securely transmit its core identity information to the relay device. The physical identity identifier is a globally unique hardware code assigned to the first communication device at the factory, such as the device's Media Access Control address, integrated circuit card identification code, or International Mobile Equipment Identity (IMSI). These identifiers are immutable and unique, serving as the fundamental basis for the relay device to perform device authentication and access control. Because physical identity identifiers are highly privacy-sensitive, if transmitted directly in plaintext in an open network environment, they are easily intercepted by network sniffers, potentially leading to the exposure of the device's location, identity forgery, or targeted denial-of-service attacks. Therefore, strong cryptographic methods must be used to protect them.

[0095] In one possible implementation, the first communication device employs a symmetric encryption algorithm with authentication functionality to handle the physical identity identifier. Symmetric encryption algorithms use the same key for both encryption and decryption, resulting in significantly higher computational efficiency than asymmetric encryption algorithms. This makes them ideal for encrypting and decrypting large amounts of data on resource-constrained communication devices. The first communication device uses the symmetric session key derived in the preceding steps as the key input to the encryption algorithm and a generated one-time random number as the initialization vector input. The initialization vector in symmetric encryption disrupts the statistical patterns of the plaintext, ensuring that even if the same plaintext is encrypted multiple times in different communication sessions or different messages within the same session, distinct ciphertexts are produced. This mechanism effectively prevents replay attacks and traffic pattern analysis. The first communication device inputs the physical identity identifier as plaintext into the encryption engine. The encryption engine performs multiple rounds of complex mathematical transformations, including byte substitution, row shifting, column obfuscation, and round key addition, ultimately outputting a stream of seemingly random pseudo-random bytes—the ciphertext payload. This encrypted payload not only hides the true content of the physical identity, but also includes integrity verification information through an authentication encryption mechanism, ensuring that the receiver can immediately detect any tampering of the data during transmission.

[0096] Step S5: The first communication device generates a first message based on the session state identifier, the target physical identity identifier, the local sequence number, the temporary public key, and the ciphertext payload, and sends the first message to the relay device.

[0097] Specifically, the first message is the initial handshake message for establishing a secure tunnel connection between the first communication device and the relay device. It carries key negotiation materials, authentication information, and tunnel status parameters. To ensure that the relay device can correctly parse and process this message, the first communication device needs to assemble and splice the various data fields in an orderly manner according to a predefined tunnel protocol format. The structural design of the first message balances security and transmission efficiency, placing information that does not need to be kept confidential but is used for routing and status identification in the plaintext area, and placing sensitive identity and business data in the ciphertext area.

[0098] Step S51: The first communication device concatenates the session state identifier, the target physical identity identifier, and the local sequence number to obtain a plaintext tunnel header. The target physical identity identifier is the gateway addressing identifier reserved by the relay device.

[0099] In one possible implementation, the plaintext tunnel header is located at the beginning of the first message and is the first part parsed by the relay device after receiving the message. The first communication device first extracts the session state identifier, which indicates which specific communication session the current message belongs to. Subsequently, the first communication device obtains the target physical identity identifier. Unlike the first communication device's own physical identity identifier, the target physical identity identifier is a globally unique addressing identifier for the relay device in the entire network system, often referred to as the gateway addressing identifier. This identifier is pre-allocated and embedded in the relay device during system deployment, and the first communication device obtains this identifier through local configuration or a domain name resolution service. Including the target physical identity identifier in the plaintext tunnel header allows the underlying forwarding devices or load balancers in the network to accurately route the message to the corresponding relay device cluster or specific node based on this identifier without decrypting the message content. Finally, the first communication device appends a local sequence number to the tunnel header. The local sequence number is used by the relay device for anti-replay detection and reconstruction of a one-time random number. The first communication device stores these three fields sequentially into a continuous memory buffer according to a fixed byte length and network byte order, forming a complete plaintext tunnel header.

[0100] Step S52, the first communication device determines that the temporary public key is a plaintext payload.

[0101] Specifically, the temporary public key is the public portion of the asymmetric key pair generated by the first communication device in the current session. To enable the relay device to calculate the exact same symmetric session key as the first communication device, the first communication device must transmit the temporary public key to the relay device. Since the public key is designed to be public, even if intercepted by a third party, the temporary private key cannot be deduced, therefore, it does not require encryption. The first communication device directly transmits the byte sequence of the temporary public key as the plaintext payload, immediately following the plaintext tunnel header. In some application scenarios, to further compress the message length, the first communication device can use elliptic curve compression technology, transmitting only the x-coordinate of the temporary public key and a flag bit. The relay device can then recover the complete public key coordinates using mathematical equations. This approach has significant advantages in narrowband communication networks with extremely limited bandwidth.

[0102] Step S53: The first communication device performs symmetric encryption on the physical identity and configuration information of the first communication device according to the symmetric session key and the one-time random number to obtain the initial ciphertext payload and standard authentication tag.

[0103] In one possible implementation, in addition to physical identification, the first communication device also needs to transmit configuration information for establishing the tunnel to the relay device. This configuration information may include the highest protocol version number supported by the device, the expected heartbeat keep-alive period, the device's current battery status, network signal strength indication, and a list of supported encryption algorithm suites. This information is of significant reference value for the relay device in allocating appropriate system resources and formulating distribution strategies. The first communication device packages the physical identification and configuration information into a continuous plaintext data block according to a predetermined format. Subsequently, the first communication device calls the authentication encryption engine, inputting the symmetric session key, a one-time random number, and the plaintext data block. While performing the encryption operation, the authentication encryption engine also calculates a cryptographic checksum in parallel. The encryption operation converts the plaintext data block into an initial ciphertext payload, while the cryptographic checksum generates a standard authentication tag. The standard authentication tag is typically a 16-byte hash value that not only covers the ciphertext payload but can also selectively cover additional authentication data such as the plaintext tunnel header. This means that any slight alteration to the plaintext tunnel header or the encrypted payload will cause the receiver to produce completely different results when recalculating the authentication tag, thus leading to immediate rejection.

[0104] Step S54: The first communication device performs a truncation process on the standard authentication tag to obtain a truncated authentication tag.

[0105] Specifically, while the 16-byte standard authentication tag offers extremely high tamper-proof security, in certain IoT scenarios highly sensitive to communication traffic, such as smart water meters and smart gas meters—devices powered by batteries and communicating via narrowband networks—each byte of transmission consumes valuable electrical energy and expensive network bandwidth. To strike a balance between security and transmission costs, the first communication device truncates the standard authentication tag. Truncation involves extracting a portion of bytes from the standard authentication tag's byte sequence according to fixed rules, discarding the remaining bytes. For example, the first communication device might retain only the first eight bytes of the standard authentication tag as a truncated tag. Although truncation reduces the tag's length, theoretically increasing the probability of an attacker forging the tag through brute force, an eight-byte tag still requires an extremely large number of attempts to achieve a collision. Combined with a one-time random number mechanism and the replay protection window of the relay device, an attacker simply cannot complete enough attempts within a limited time. Therefore, this truncation effectively reduces the overall message length without significantly reducing actual security.

[0106] Step S55: The first communication device attaches the truncated authentication tag to the end of the initial ciphertext payload to obtain the ciphertext payload.

[0107] In one possible implementation, the first communication device allocates a new contiguous space in memory, copies the encrypted initial ciphertext payload into this space, and then appends the truncated authentication tag obtained in the previous step to the end of the initial ciphertext payload. This data structure, which binds the ciphertext and the authentication tag together, constitutes the final ciphertext payload. During processing, the receiver, according to the truncation length agreed upon in the protocol, removes the truncated authentication tag from the end of the ciphertext payload and processes the remaining portion as the ciphertext to be decrypted. This compact data layout improves the efficiency of memory operations and reduces memory fragmentation.

[0108] Step S56: The first communication device concatenates the outer network protocol header, the plaintext tunnel header, the plaintext payload, and the ciphertext payload in sequence to obtain the first message.

[0109] Specifically, to enable message routing and transmission in the complex internet environment, the first communication device needs to encapsulate the tunnel data with a standard outer network protocol header. This outer network protocol header typically includes a network layer header and a transport layer header. The first communication device first constructs the transport layer header, such as the User Datagram Protocol (UDP) header, which contains the source and destination port numbers. The destination port number is the listening port used by the relay device to provide tunnel access services, while the source port number is a randomly assigned available port on the first communication device's local machine. Next, the first communication device constructs the network layer header, such as the Internet Protocol version 4 (IP4) header, which contains the source network address of the network the first communication device is currently in and the public destination network address of the relay device. Following the encapsulation order of the network protocol stack, the first communication device sequentially concatenates the outer network protocol header, the plaintext tunnel header, the plaintext payload containing the temporary public key, and the ciphertext payload containing identity and configuration information. During this concatenation process, the first communication device also calculates and fills in the length and checksum fields of the outer network protocol header to ensure the message conforms to standard network protocol specifications, ultimately forming a complete first message.

[0110] Step S57: The first communication device sends the first message to the relay device through the wireless communication link.

[0111] In one possible implementation, the first communication device is typically deployed in remote areas or mobile scenarios lacking wired network coverage, thus relying on wireless communication links to interact with the outside world. These wireless communication links can be based on 4G or 5G mobile communication technologies using cellular networks, or narrowband IoT technologies or long-range radio technologies designed for low-power wide-area networks. The first communication device submits the assembled first message to the underlying wireless radio frequency module. The wireless radio frequency module modulates the digital signal into a high-frequency analog radio frequency signal, which is then radiated into free space through an antenna. After being received, demodulated, and decoded by the base station, the radio frequency signal is reconstructed into a digital message and enters the core network, ultimately being forwarded through the internet backbone to the network node where the relay device is located. During wireless transmission, the first communication device may face physical layer problems such as signal fading, interference, and packet loss. Therefore, the underlying communication protocol typically provides a certain degree of retransmission and error correction mechanisms to improve the reliability of the first message reaching the relay device.

[0112] Step S6: The relay device receives the first message and determines the symmetric session key and the basic random number based on the temporary public key and the relay device private key.

[0113] Specifically, a relay device is a high-performance gateway server deployed in the cloud or enterprise data center, responsible for terminating tunnel connections from a massive number of primary communication devices and performing security authentication and data routing. The relay device's network interface continuously listens to a preset service port. When the first packet arrives at the relay device through the network, the operating system's network protocol stack strips the outer network protocol header and delivers the packet's payload to the tunnel processing service process. The relay device first parses the plaintext tunnel header, extracting the session state identifier and the target physical identity identifier. The relay device verifies whether the target physical identity identifier matches its own gateway address identifier. If they do not match, it indicates that the packet has been incorrectly routed, and the relay device will directly discard the packet to prevent resource consumption.

[0114] After confirming that the message was sent to itself, the relay device extracts the temporary public key of the first communication device from the plaintext payload. At this point, the relay device needs to perform a key negotiation calculation corresponding to the first communication device. The relay device maintains its own long-term asymmetric private key, i.e., the relay device private key, in a secure storage area. This private key and the relay device's pre-set public key are mathematically strictly related key pairs. The relay device inputs the extracted temporary public key and its own relay device private key into the elliptic curve cryptography engine. Based on the mathematical properties of the elliptic curve discrete logarithm problem, the relay device performs a scalar multiplication operation on the first communication device's temporary public key using its private key. The resulting point on the elliptic curve is exactly the same as the point obtained by the first communication device performing a scalar multiplication operation on its public key using its temporary private key.

[0115] The relay device extracts the x-coordinate of the shared point and uses it as input to the key derivation function. Using the exact same key derivation algorithm and context parameters as the first communication device, the relay device performs hash expansion and compression on the input. Since the input and derivation algorithm are identical, the relay device can calculate the same byte sequence as the first communication device. Following predetermined rules, the relay device truncates a specific length of bytes from the first part of this byte sequence as the symmetric session key and a specific length of bytes from the second part as the base random number. Thus, without directly transmitting any sensitive key material over the network, the relay device successfully establishes consistent symmetric encryption parameters with the first communication device, laying the foundation for subsequent ciphertext decryption.

[0116] Step S7: The relay device determines the one-time random number based on the local sequence number and the basic random number, and decrypts the encrypted payload based on the symmetric session key and the one-time random number to obtain the physical identity identifier of the first communication device.

[0117] Specifically, after obtaining the symmetric session key and the basic random number, the relay device needs to decrypt the ciphertext payload in the first message to verify the true identity of the first communication device. The decryption process is not only an operation to recover the plaintext data, but also a rigorous security audit. Any mismatch in cryptographic parameters will lead to decryption failure, thus preventing unauthorized access.

[0118] Step S71: The relay device initializes a local absolute sequence number for the session state identifier.

[0119] In one possible implementation, since the first message is the initial message for establishing a session, the relay device has not yet established a complete context corresponding to the session state identifier in its local memory. The relay device first allocates a new context data structure for the session state identifier in its memory cache. Within this data structure, the relay device needs to maintain a sequence number state for tracking message order and preventing replay attacks. The relay device initializes the local absolute sequence number of this session to a preset starting value, typically zero. This local absolute sequence number represents the complete sequence number of the next message that the relay device expects to receive from the first communication device. Initializing the local absolute sequence number is the foundation for establishing a sliding window mechanism; all subsequent arriving messages will be checked and reconstructed based on this baseline value.

[0120] Step S72: The relay device reconstructs the complete absolute serial number based on the local serial number and the local absolute serial number.

[0121] Specifically, the plaintext tunnel header of the first message only carries a partial sequence number, i.e., the low-order part of the absolute sequence number. The relay device needs to combine the high-order state of the locally maintained absolute sequence number to deduce the complete absolute sequence number used by the first communication device during encryption. During the initial handshake phase, since the local absolute sequence number is just initialized to zero, the reconstruction process is relatively simple; the relay device directly uses the received partial sequence number as the low-order part of the complete absolute sequence number, padding the high-order parts with zeros. However, in subsequent business communication, network packets may be out of order, delayed, or lost. The relay device uses a sliding window algorithm to handle these complex situations. The relay device calculates the difference between the received partial sequence number and the low-order part of the local absolute sequence number. If the difference is within a reasonable positive window range, it indicates that this is a new message that has arrived normally. The relay device concatenates the high-order part of the local absolute sequence number with the received partial sequence number to obtain the complete absolute sequence number. If the difference is negative and its absolute value is large, it indicates that the local sequence number has wrapped around, meaning the low-order counter has overflowed and restarted from zero. In this case, the relay device needs to increment the high-order bits of the local absolute sequence number by one before concatenating it with the local sequence number. If the difference is within a reasonable negative window range, it indicates that this is an out-of-order old message, and the relay device uses the high-order bits of the current local absolute sequence number for concatenation. Through this rigorous reconstruction logic, the relay device can accurately reconstruct the complete absolute sequence number used by the first communication device in complex network environments.

[0122] Step S73: The relay device performs a bitwise XOR operation on the complete absolute serial number and the basic random number to obtain the one-time random number.

[0123] In one possible implementation, after successfully reconstructing the complete absolute sequence number, the relay device needs to generate a one-time random number for decryption. The relay device first extends the complete absolute sequence number by padding its high-order bits with zero bytes, making its total length exactly the same as the length of the base random number. Then, the relay device sends the extended sequence number and the previously calculated base random number to the processor's arithmetic logic unit (ALU) to perform a bitwise XOR operation. Due to the symmetry of the XOR operation, as long as the complete absolute sequence number reconstructed by the relay device is consistent with the sequence number used by the first communication device during encryption, and both devices calculate the same base random number, the relay device will inevitably be able to generate a one-time random number identical to that of the first communication device. This one-time random number will serve as the initialization vector for the decryption algorithm, ensuring the correct execution of the decryption process.

[0124] Step S74: The relay device decrypts and verifies the ciphertext payload based on the symmetric session key and the one-time random number.

[0125] Specifically, the relay device extracts the ciphertext payload from the end of the first message and, according to the agreed-upon length, separates it into the initial ciphertext to be decrypted and a truncated authentication tag. The relay device invokes the same authentication / decryption engine as the first communication device, inputting the symmetric session key, a one-time random number, and the initial ciphertext into the engine. The decryption engine first uses the key and random number to generate a pseudo-random keystream, XORs it with the initial ciphertext, and recovers the plaintext data block. Simultaneously, the decryption engine recalculates a standard 16-byte authentication tag based on the recovered plaintext data block and additional authentication data. The relay device truncates the recalculated standard authentication tag according to the same truncation rules as the first communication device, obtaining a locally calculated truncated authentication tag. The relay device performs a strict memory byte comparison between the locally calculated truncated authentication tag and the truncated authentication tag carried in the message. If they match perfectly, it indicates that the ciphertext has not been tampered with by any third party during transmission, and the sender indeed possesses the correct symmetric session key; the decryption verification is successful. If the comparison fails, it indicates that the message may have been maliciously tampered with, there may have been a network transmission error, or the sender may have used an incorrect key. The relay device will immediately terminate the decryption process, discard the message, and record a security alarm log.

[0126] Step S75: If the decryption verification is successful, the relay device extracts the physical identity identifier of the first communication device from the decrypted data.

[0127] In one possible implementation, after successful decryption verification, the relay device is certain that the recovered plaintext data block is authentic and reliable. The relay device parses the plaintext data block according to a predetermined data structure format. The plaintext data block contains the physical identity identifier of the first communication device and related configuration information. By reading fields with specific offsets and lengths, the relay device accurately extracts the physical identity identifier of the first communication device. This identifier serves as the true identity proof of the first communication device within the system, and the relay device will use this identifier for subsequent permission checks. Simultaneously, the relay device also extracts configuration information, such as the heartbeat cycle, and stores it in the context of the session to guide subsequent connection maintenance.

[0128] Step S76: The relay device determines whether the physical identity identifier of the first communication device exists in the preset identity whitelist.

[0129] Specifically, merely verifying message integrity and key correctness is insufficient to allow devices to access the network. To prevent unauthorized devices (such as stolen or illegally counterfeited devices) from consuming system resources or stealing business data, relay devices implement strict access control policies. The relay device maintains a preset identity whitelist in local memory or a cached database. This whitelist contains the physical identities of all communication devices legally registered by the system administrator and permitted to access the current relay device. The whitelist data is typically distributed and synchronized in real-time by the upper-layer device management platform through a secure management channel. The relay device uses the extracted physical identity of the first communication device as a query keyword to quickly search the identity whitelist. To improve retrieval efficiency, the whitelist is typically organized using efficient data structures such as hash tables or Bloom filters, enabling matching queries of massive amounts of identity identifiers at the microsecond level.

[0130] Step S77: If the physical identity identifier of the first communication device exists in the preset identity whitelist, the relay device determines that the authentication is successful.

[0131] In one possible implementation, if the relay device successfully matches the physical identity of the first communication device in the identity whitelist, it indicates that the device is a legitimate system member with network access privileges. At this point, the relay device determines that the authentication process for the first packet has passed. Successful authentication means that the relay device formally accepts the tunnel establishment request from the first communication device, and the trust relationship between the two parties is established. The relay device will then allow the session to proceed to the next stage, namely, establishing a mapping relationship for subsequent service data forwarding. If the physical identity is not in the whitelist, the relay device will determine that authentication has failed, refuse to establish the tunnel, and may send an alarm message for an unauthorized access attempt to the device management platform.

[0132] Step S8: The relay device establishes a mapping relationship based on the physical identity of the first communication device, the session state identifier, the outer network address information of the first message, and the symmetric session key and sequence number.

[0133] Specifically, after successful authentication, the relay device needs to build a core routing and state forwarding table locally, i.e., a mapping relationship. This mapping relationship is a key data structure for the relay device to achieve efficient data forwarding and session management. It tightly binds the device's physical identity, logical session state, underlying network addressing information, and cryptographic parameters together, ensuring that every subsequent service packet can be processed quickly and securely.

[0134] Step S81: The relay device extracts the outer source network protocol address and the outer source user datagram protocol port number of the first message as the outer network address information.

[0135] In one possible implementation, the first communication device is typically located in a complex network topology, potentially having passed through multiple levels of Network Address Translation (NAT) devices. Therefore, the source network address and port number entered by the first communication device when constructing the packet may have been modified to a public IP address and mapped port by the NAT device by the time it reaches the relay device. The relay device cannot rely on the private IP address that may be carried within the packet for return packet routing; it must extract the real source network protocol address (i.e., public IP address) and source UDP port number from the outermost network protocol header of the first packet. These two parameters combined constitute the real outer network address information of the first communication device in the current network environment. The relay device will use this address information as the destination address for subsequent downlink packets sent to the first communication device, thereby achieving NAT traversal and ensuring that downlink data is accurately delivered to the first communication device.

[0136] Step S82: The relay device establishes a six-tuple record in its memory cache containing the physical identity identifier of the first communication device, the session state identifier, the outer source network protocol address, the outer source user datagram protocol port number, the symmetric session key, and the sequence number.

[0137] Specifically, the relay device allocates an entry in a high-performance memory cache to store the complete context information of the session. This entry is designed as a six-tuple record containing information from six key dimensions. The first is the physical identity identifier, used to identify the tunnel's owner; the second is the session state identifier, serving as the primary key for fast indexing; the third and fourth are the outer source network protocol address and port number, used for underlying network routing; the fifth is the symmetric session key, used for encryption and decryption of subsequent service packets; and the sixth is the sequence number status, including the local absolute sequence number and the anti-replay window status, used to defend against replay attacks. The relay device stores these six elements in a structured manner in memory and establishes multi-level indexes. For example, a primary index is created using the session state identifier, and a secondary index is created using the physical identity identifier. To prevent memory leaks and zombie sessions consuming resources, the relay device also starts an aging timer for this six-tuple record. If no packets are received from the session within the configured heartbeat period, the timer expires, and the relay device automatically cleans up the six-tuple record, releasing memory resources.

[0138] Step S83: The relay device constructs an acknowledgment message carrying the physical identity of the first communication device based on the symmetric session key.

[0139] In one possible implementation, after the mapping relationship is established, the relay device needs to send a response to the first communication device, informing it that the tunnel has been successfully established. The relay device constructs an acknowledgment message, whose plaintext tunnel header contains the same session state identifier, allowing the first communication device to identify which session the response belongs to. The relay device uses the first communication device's physical identity and the tunnel parameters allocated by the relay device (such as the allocated virtual internal network address, acknowledgment heartbeat period, etc.) as plaintext data blocks. Subsequently, the relay device uses the symmetric session key from the six-tuple record, combined with its own maintained downlink sequence number and basic random number to generate a downlink one-time random number, and uses this to authenticate and encrypt the plaintext data block, generating the acknowledgment ciphertext payload. This encrypted response mechanism not only protects the confidentiality of the tunnel parameters but also proves to the first communication device that the relay device has indeed successfully derived the correct symmetric session key, completing two-way cryptographic authentication.

[0140] In step S84, the relay device sends the confirmation message to the first communication device.

[0141] Specifically, the relay device will concatenate the ciphertext payload with the plaintext tunnel header and then encapsulate it with an outer network protocol header. At this point, the destination network address and destination port number in the outer network protocol header are precisely the outer source network protocol address and outer source UDP port number extracted from the six-tuple record. The relay device then sends the acknowledgment message to the public network through its network interface. The message will return along the original path, penetrating NAT devices along the way, and finally reaching the first communication device. Once the first communication device receives the acknowledgment message and successfully decrypts and verifies it, the secure tunnel is officially established, and both parties can begin secure transmission of business data.

[0142] Step S9: The relay device receives the service message sent by the first communication device and forwards the service message according to the mapping relationship.

[0143] Specifically, after the tunnel is established, the first communication device will continuously generate service data, such as environmental data collected by sensors, device operation status logs, or user interaction commands. This service data is encapsulated in service packets and sent to the relay device. As the core hub of the network, the relay device undertakes the important tasks of decryption, routing, re-encryption, and forwarding. Relying on the previously established mapping relationship, the relay device can efficiently process massive concurrent service packets, realizing the secure flow of data.

[0144] Step S91: The relay device receives the service message and extracts the session state identifier and the current local sequence number from the service message.

[0145] In one possible implementation, when a service message arrives at the relay device, the relay device first parses the plaintext tunnel header of the message. Similar to the first message, the plaintext tunnel header of the service message also contains a session state identifier and a local sequence number. This local sequence number is called the current local sequence number, which reflects the sequence number status of the first communication device when sending the service message. The relay device extracts these two key fields as input parameters for subsequent queries and processing. Because the plaintext tunnel header is not encrypted, the relay device can complete the extraction operation in a very short time, which is crucial for improving the overall throughput of the gateway.

[0146] Step S92, the relay device queries the corresponding symmetric session key and the basic random number in the mapping relationship according to the session state identifier.

[0147] Specifically, the relay device uses the session state identifier as the query key to look up the information in a memory-cached mapping table. Since the mapping table typically uses a hash table structure, the time complexity of the query operation is close to constant. The relay device quickly locates the corresponding six-tuple record. If the query fails, it indicates that the session may have been aged out due to timeout or that the message is forged. In this case, the relay device will discard the message and request the first communication device to re-initiate the tunnel establishment process. If the query succeeds, the relay device reads the session-specific symmetric session key and basic random number from the six-tuple record. These two cryptographic parameters are essential for decrypting the current business message.

[0148] Step S93: The relay device determines the current one-time random number based on the current local sequence number and the basic random number.

[0149] In one possible implementation, the relay device reads the local absolute sequence number status stored in the six-tuple record. The relay device uses a sliding window algorithm to calculate the difference between the current local sequence number and the lower bits of the local absolute sequence number to determine the message's order status. If the message is within the anti-replay window and has not been processed, the relay device reconstructs the complete absolute sequence number corresponding to the current service message. Subsequently, the relay device pads this complete absolute sequence number with zeros and performs a bitwise XOR operation with the queried base random number. In this way, the relay device dynamically generates a one-time random number specifically used to decrypt the current service message. Simultaneously, the relay device updates the sequence number status and anti-replay window bitmap in the six-tuple record, marking the sequence number as processed to prevent attackers from intercepting the message and retransmitting it in the future.

[0150] Step S94: The relay device decrypts and verifies the ciphertext payload of the service message based on the symmetric session key and the current one-time random number.

[0151] Specifically, the relay device extracts the encrypted payload and truncated authentication tag from the service message. The relay device inputs the retrieved symmetric session key, the dynamically generated one-time random number, and the encrypted payload into the authentication decryption engine. The decryption engine performs a symmetric decryption operation to recover the plaintext containing the actual service data. Simultaneously, the decryption engine recalculates the authentication tag, truncates it according to rules, and compares it with the tag carried in the message. If the comparison is successful, it indicates that the service data has maintained confidentiality and integrity during transmission, and the decryption verification is successful. The decrypted service data may contain application layer protocol headers, sensor values, or control commands, etc. If the comparison fails, the relay device discards the message, protecting the backend system from attacks involving compromised data.

[0152] Step S95: If the decryption verification is successful, the relay device extracts the current outer network address information of the service message.

[0153] In one possible implementation, the underlying network access point of a mobile communication device, or a device in a dynamic network environment, may change. For example, the device may switch from one base station to another, or its NAT device may reassign mapped ports. This change will cause the outer source network protocol address and port number of the service packet to change when it arrives at the relay device. To maintain the smooth operation of the downlink communication link, the relay device extracts the current source network protocol address and source UDP port number from the outer network protocol header of each successfully decrypted and verified service packet; that is, the current outer network address information. Since the packet has passed strict cryptographic authentication, the relay device can be certain that this new address information does indeed come from the legitimate first communication device, and is not a source address forged by an attacker.

[0154] Step S96: The relay device updates the outer network address information in the mapping relationship according to the current outer network address information.

[0155] Specifically, the relay device compares the extracted current outer network address information with the original outer network address information stored in the six-tuple record. If they differ, it indicates that the network location of the first communication device has shifted. The relay device immediately updates the outer source network protocol address and port number in the six-tuple record with the currently extracted values. This adaptive address update mechanism based on authentication messages enables the secure tunnel to have strong mobility support capabilities. Regardless of how the first communication device roams in the underlying network, as long as it can continuously send legitimate service packets, the relay device can track its latest network location in real time, ensuring that subsequent downlink control commands or response data can be accurately routed back to the first communication device, achieving seamless service continuity.

[0156] Step S961: The relay device extracts the physical identity identifier of the second communication device from the service message.

[0157] In one possible implementation, the service data sent by the first communication device is often not intended for the relay device itself, but rather needs to be forwarded to other entities in the system, such as a cloud-based business server, data analysis platform, or another terminal device. This receiving entity is referred to as the second communication device. The decrypted plaintext service data typically contains an application-layer routing header or destination address field. The relay device parses this application-layer routing header to extract the physical identifier of the second communication device, indicating the final destination of the data. This identifier is also globally unique and is used to accurately locate the target device within the relay device's routing system.

[0158] In step S962, the relay device queries the target outer network address information and target symmetric session key bound to the second communication device in the mapping relationship based on the physical identity of the second communication device.

[0159] Specifically, the relay device, acting as a centralized security proxy, maintains not only the tunnel with the first communication device but also a secure tunnel with the second communication device (such as a business server). The relay device uses the extracted physical identity of the second communication device to perform an auxiliary index lookup in a global mapping table. If the second communication device is currently online and has already established a secure tunnel with the relay device, the relay device will successfully retrieve the six-tuple record belonging to the second communication device. From this record, the relay device extracts the target outer network address information (i.e., the second communication device's current public network address and port) and the target symmetric session key used to send data to the second communication device. The target symmetric session key is negotiated and generated between the relay device and the second communication device during their handshake phase and is completely independent of the key of the first communication device.

[0160] In step S963, the relay device encrypts the service data in the service message according to the target symmetric session key to obtain re-encrypted service data.

[0161] In one possible implementation, to ensure end-to-end data security, business data must be encrypted again before leaving the relay device and being sent to the second communication device. The relay device employs a re-encryption mechanism: first decrypting with the key of the first communication device, and then encrypting with the key of the second communication device. The relay device takes the extracted plaintext business data as input, uses the queried target symmetric session key, and combines it with the downlink sequence number maintained for the tunnel of the second communication device and the target one-time random number generated from the basic random number to call the authentication encryption engine for encryption. The encryption engine outputs the re-encrypted business data and the corresponding target truncated authentication tag. This re-encryption mechanism enables the relay device to perform deep security auditing, protocol conversion, or content filtering on plaintext data during forwarding, while physically isolating the key systems of the first and second communication devices. Even if the key of one device is leaked, it will not threaten the security of the entire system.

[0162] Step S964: The relay device generates a forwarding message based on the target outer network address information and the re-encrypted service data.

[0163] Specifically, the relay device concatenates the re-encrypted service data with the target truncated authentication tag to form a new ciphertext payload. Then, the relay device constructs a plaintext tunnel header destined for the second communication device, containing the second communication device's tunnel session state identifier and an incremented downlink local sequence number. The relay device concatenates the plaintext tunnel header with the new ciphertext payload. Finally, the relay device encapsulates the outer network protocol header, setting the destination network address and destination port number to the queried target outer network address information, and the source address to the relay device's own public IP address. After this series of encapsulation operations, the relay device generates a forwarding message that conforms to the protocol specifications.

[0164] In step S965, the relay device sends the forwarding message to the second communication device.

[0165] Example 1:

[0166] This invention proposes a zero-handshake (0-RTT) secure tunnel forwarding method for narrowband satellite links. This method aims to achieve extremely low-overhead end-to-end secure relay in dynamic NAT environments by completely decoupling the terminal's physical identity (short identifier) ​​from its temporary security state (session index), without the public network relay server participating in the underlying dynamic routing protocol calculations. Its overall forwarding logic is summarized as follows: Figure 2 As shown: (1) Definition of network roles and preconditions The system comprises several network hosts, several satellite terminals (which may consist of multiple sub-modules, such as a micro gateway module, a satellite communication module, etc.), and a public network relay server with a fixed public IP address. The relay server holds the server's private key and retains a specific identifier (such as 0x0000) as a gateway addressing identifier; each satellite terminal is pre-configured with a 2-byte short ID and a pre-set server public key.

[0167] (2) Satellite terminal zero-handshake online registration mechanism When a satellite terminal connects for the first time or reconnects after a disconnection, it does not need to exchange keys with the server in multiple rounds. Instead, it directly generates a 4-byte temporary session index (sessionID) and a temporary asymmetric key pair (including a temporary public key and a temporary private key) locally. It then uses the pre-set server public key and temporary private key to unidirectionally derive the symmetric session key and the base random number (Base_Nonce). Finally, it calculates the one-time random number (Nonce) used for the actual encryption of this message based on the local sequence number and Base_Nonce. Subsequently, the terminal assembles and sends a registration message. The plaintext portion of this message carries the temporary public key and the local sequence number, while the ciphertext portion uses the session key combined with the Nonce for symmetric encryption, carrying the terminal's shortID and authentication information, thus achieving covert registration and blind transmission.

[0168] (3) Miniature tunnel encapsulation with state and routing decoupled At the packet encapsulation level, this invention constructs a "miniature tunnel message." Its outer layer uses plaintext double tags (containing a random session ID and a destination shortID for the current session), while the inner layer is the actual payload encrypted using the session key. This structure physically separates "decryption addressing" from "routing addressing."

[0169] (4) Server-side authentication and establishment of the six-tuple state machine After receiving the registration message, the public server first extracts the plaintext temporary public key and, together with its own server private key, derives the same session key and Base_Nonce. It then calculates the Nonce of this message using the local sequence number, decrypts it, and obtains the source shortID and authentication information. After successful authentication, the server dynamically establishes a six-tuple mapping table based on the outer network information of the latest received message: [shortID - sessionID - outer IP - outer UDP port - session key - sequence number].

[0170] (5) Stateless transparent forwarding and roaming recovery In routine business communications, after receiving a message, the server performs a fast key retrieval based on the sessionID exposed in the plaintext, and decrypts the message for key verification and replay protection. If verification passes, it directly reads the shortID from the plaintext tag, queries the aforementioned six-tuple table to extract the target terminal's key, re-encrypts the business data, and delivers it to the target terminal's currently bound IP:Port. If the terminal experiences cross-beam roaming or NAT drift, the server will dynamically update the IP and port in the business data packet with the sessionID upon successful authentication, achieving NAT traversal and roaming recovery.

[0171] I. Definition of Miniature Tunnel Message Format To achieve extremely low-overhead data transmission on narrowband satellite links with severely limited MTU, the core data structure of this invention is a "micro-tunneling message". This message abandons the lengthy encryption header protocols of traditional IPsec or WireGuard, compressing it to an extreme level with only 16 bytes of overhead (8 bytes for the tunnel header and 8 bytes for the encryption authentication bit).

[0172] Depending on the communication stage, microtunneling messages have the following two structural formats: (1) Registration and heartbeat message format This message is used for terminal first-packet zero-round-trip time (0-RTT) blind access, encryption key negotiation, and periodic heartbeat keep-alive. The message format is as follows: Figure 3 As shown: The contents of each field in the registration and heartbeat messages are as follows: Outer public network transport header (28 bytes): The standard IPv4 header and UDP header are used for public internet routing and NAT traversal.

[0173] Miniature tunnel head (8 bytes): sessionID: 4 bytes, a temporary session tag randomly generated by the terminal, used as an index of the current connection state.

[0174] Server shortID: 2 bytes, always filled with a special short identifier reserved by the server (e.g., 0x0000), indicating that the destination of the message is the public network server itself.

[0175] Local sequence number: 2 bytes, the lower 16 bits of an absolutely incrementing sequence number maintained locally by the terminal. The receiving end reconstructs the absolute sequence number based on this local sequence number and the local window sliding mechanism, and derives the Nonce from it in conjunction with Base_Nonce.

[0176] Plaintext payload (32 bytes): Temporary public key: 32 bytes (based on elliptic curves such as Curve 25519), provided to the server to perform the ECDH algorithm and unidirectionally derive the symmetric session key.

[0177] Ciphertext payload (18 bytes): Encryption is performed using the derived symmetric session key and the currently derived nonce, which contains: Source ShortID: 2 bytes, the shortID identifier of the terminal sending the registration message. Placing it inside ciphertext effectively prevents intermediate nodes from capturing packets and plotting the network communication topology (preventing traffic analysis).

[0178] Additional configuration information: 8 bytes, containing configurations for some optional tunnel features, as well as high-order synchronization information for the absolute sequence number.

[0179] Authentication information truncated: 8 bytes. The standard 16-byte Authentication Code (MAC) tag is truncated to 8 bytes. Based on the physical transmission rate limit of narrowband satellite links, the 8-byte truncated tag is sufficient to ensure protection against all online brute-force forgery and tampering attacks during the device's lifecycle.

[0180] (2) Service forwarding message format like Figure 4 As shown, this message is used by the terminal to send routine service data to other terminals (multi-hop destinations) after registration is completed. To maximize payload bandwidth, unnecessary tunnel control information is removed from this message, and the header overhead is close to the theoretical minimum.

[0181] Outer public network transport protocol header (28 bytes): Standard IPv4 header and UDP header (used for public internet routing and NAT hole punching by carriers).

[0182] Plaintext miniature tunnel header (8 bytes): sessionID: 4 bytes, the session index used by the satellite terminal during its last registration. The server can use this index to match the current satellite terminal's session key, ignoring NAT drift.

[0183] Destination Node ShortID: 2 bytes, filled with the short identifier of the actual next-hop / final destination satellite terminal.

[0184] Local serial number: Same as above.

[0185] Ciphertext payload: Encryption is performed using the derived symmetric session key and the currently derived nonce, which contains: Business data: The inner protocol data unit (PDU) carried by the application.

[0186] Truncate authentication information: Same as above.

[0187] II. The specific steps are as follows: Step 1: Zero-handshake (0-RTT) terminal access process based on ECDH like Figure 5 As shown, this step defines how a satellite terminal can securely register with a public network relay server and establish an encrypted tunnel without increasing additional handshake latency when it first powers on and connects or reconnects after a disconnection.

[0188] (1) Pre-set conditions Public network relay server: It pre-generates and holds a pair of high-strength static asymmetric keys, including the server's private key and public key. Simultaneously, the server reserves a specific short identifier (such as 0x0000) as its own virtual gateway addressing identifier.

[0189] Satellite terminal: During factory or initial configuration, a unique 2-byte short identifier (hereinafter referred to as the source shortID) is burned and assigned, and the server's public key is pre-set. Each time the terminal connects to the network for registration, it initializes an 8-byte absolute serial number locally (initial value is 0).

[0190] (2) 0-RTT key negotiation When a satellite terminal needs to initiate communication, the following preparation procedure is performed: Generate a session index: The terminal randomly generates a 4-byte session index (sessionID) locally. This index serves as a unique state identifier throughout the lifecycle of this connection.

[0191] Generate a temporary key pair: The terminal randomly generates a pair of temporary asymmetric keys based on an elliptic curve algorithm (such as Curve25519): a temporary private key and a temporary public key (32 bytes).

[0192] One-way derived session key: The terminal uses its own temporary private key and the pre-set server public key to calculate the symmetric session key and the 16-byte base random number Base_Nonce locally using the ECDH (Elliptic Curve Diffie-Hellman) algorithm.

[0193] Nonce Construction: The terminal pads its locally maintained 8-byte absolute sequence number with zeros at the high bits, extending it to the same length as the Base_Nonce (e.g., the 16 bytes required by ASCON-128). Then, it performs a bitwise XOR operation between the extended absolute sequence number and the Base_Nonce to obtain the Nonce used to encrypt this message. This design ensures that the Nonce changes dynamically with each packet transmission without incurring additional network overhead.

[0194] (3) Assemble registration and heartbeat messages: Terminal A sets the plaintext tunnel header of the outer layer of the message to: sessionID + server shortID + lower 2 bytes of absolute sequence number.

[0195] The temporary public key is placed in the plaintext payload to tell the server how to derive the session key and Base_Nonce.

[0196] Using the session key and nonce, the terminal's shortID and additional configuration information are symmetrically encrypted (such as the ASCON-128 algorithm of the AEAD type) to generate a ciphertext payload and a 16-byte standard authentication tag.

[0197] The 16-byte standard authentication tag is truncated into an 8-byte truncated authentication tag and appended to the end of the encrypted payload to form the complete encrypted payload.

[0198] Finally, the terminal concatenates the outer network header (IP+UDP), the micro-tunnel header, the plaintext payload, and the complete encrypted payload in sequence to obtain the complete registration and heartbeat message.

[0199] (4) Sending 0-RTT registration message After terminal A is assembled, it sends the initial registration packet directly to the public server's IP address and port via a satellite link using a UDP socket, without waiting for any response or protocol exchange from the server, and increments the absolute sequence number by 1. If the packet arrives normally, the service message to be forwarded can be sent normally without waiting for the server to return handshake information; if no ACK confirmation is received within a timeout, the registration message is resent. This mechanism reduces the protocol handshake latency to 0-RTT in the absence of packet loss.

[0200] Step 2: Server-side authentication, state machine establishment, and six-tuple management like Figure 6 As shown, this step defines how the public network relay server performs lightweight pre-authentication after receiving the initial registration packet from the terminal, and establishes a core data structure in memory for subsequent fast forwarding.

[0201] (1) Fast parsing and key derivation After receiving a UDP packet, the public network relay server first parses its 8-byte mini-tunnel header. If it finds that the shortID is a server-reserved ID, it determines that the packet is a registration control message sent to the server itself.

[0202] The server extracts the temporary public key from the plaintext payload, combines it with its own server private key, and uses the ECDH algorithm to unidirectionally derive a symmetric session key and Base_Nonce that are completely identical to those of terminal A.

[0203] The server initializes a local absolute sequence number for the new session, reconstructs the complete absolute sequence number by combining it with the received local sequence number, and then XORs it with Base_Nonce to recover the Nonce.

[0204] (2) Authentication and anti-replay attack verification The server attempts to decrypt the ciphertext payload using the derived session key.

[0205] If decryption fails (authentication tag verification fails), or if the internal shortID is found to be outside the system whitelist after decryption, or if the anti-replay counter is less than the historical record, the server will trigger a silent discard mechanism.

[0206] Silent drop feature: The server does not return any error codes or ICMP rejection messages to the sender. This design completely cuts off the feedback path for public network attackers, greatly reducing the risk of port scanning and DoS attacks targeting the server's exposed surface.

[0207] (3) Establishment of the six-tuple state machine and ACK confirmation If the verification passes completely, the server executes the core state binding logic: Extract the outer source IP address and outer UDP port number of the current data packet when it arrives at the server after passing through the operator's NAT.

[0208] The server creates or updates a core six-tuple record for the terminal in a high-speed cache in memory (such as a hash table): [shortID - sessionID - outer IP - outer UDP port - session key - sequence number].

[0209] Note: This six-tuple supports two-key indexes of sessionID and shortID.

[0210] ACK Confirmation: The server uses the terminal's session parameters to construct a miniature ACK packet carrying the source's shortID and sends it back to the terminal. Upon receiving it, the terminal establishes tunnel connectivity and enters normal service forwarding mode.

[0211] Step 3: Packet forwarding and NAT traversal based on plaintext double tags This step defines how, after the tunnel is established, the server uses plaintext double tags to decrypt and route data during routine business communication between two terminals (e.g., terminal A sending data to terminal B, which acts as a relay node), and how it combats NAT drift of satellite links with zero overhead.

[0212] (1) Construction of routine business forwarding messages When terminal A needs to send service data to terminal B: Terminal A constructs a service forwarding message. In its mini tunnel header, the sessionID is filled with the index of the currently active session of terminal A; the shortID is filled with the real physical identifier of terminal B (such as 0x1234), and the lower 2 bytes of the absolute sequence number of the current terminal A are filled in.

[0213] The Nonce is calculated using the same method as in step two. The business data is then symmetrically encrypted using the session key and the Nonce (such as the ASCON-128 algorithm of the AEAD type), and an 8-byte truncated authentication tag is appended to form the complete ciphertext payload.

[0214] Assemble the data packet and send it to the public network server.

[0215] (2) NAT traversal with the flow Due to the instability of satellite communication links, the exit IP and UDP ports of Terminal A may "drift" at any time due to beam switching or CGNAT aging.

[0216] When the server receives a business data packet, it completely ignores any changes to the outer IP address and port. The server directly reads the plaintext sessionID, retrieves the corresponding session key and Base_Nonce from the memory six-tuple, and recovers the Nonce by combining it with the local sequence number in the mini-tunnel header. The server then decrypts the packet and truncates the authentication tag for verification.

[0217] If the verification is successful, it proves that the data packet was indeed sent by terminal A. The server then extracts the new outer IP and UDP port of the packet at this time and directly overwrites the old record in the six-tuple table, realizing "In-band NAT Traversal". After the terminal experiences a roaming disconnection, there is no need to re-handshake. As long as the first valid encrypted data packet sent by the terminal arrives at the server, the network routing mapping can be restored instantly.

[0218] (3) Public network server business message forwarding logic After verifying the legitimacy of terminal A, the server directly reads the destination shortID (i.e., the short identifier 0x1234 of terminal B) from the message header.

[0219] The server queries the six-tuple table using the destination shortID to extract the outer IP address, outer UDP port, corresponding session key, and local sequence number on the server side currently bound to terminal B.

[0220] The server re-encrypts the business data originating from terminal A using the same method as the terminal, encapsulates it with the corresponding terminal B's outer IP and UDP header, and sends it to the public network for forwarding.

[0221] This invention constructs a miniature tunnel message containing plaintext dual labels and ciphertext payload on the terminal side, wherein the plaintext dual labels consist of a temporary session index and a short identity identifier. The terminal uses a pre-set public key to derive a symmetric key to encrypt the payload containing the real identity and business data, achieving blind transmission of the first packet with zero round-trip time (0-RTT). After receiving the message, the public network gateway performs fast key retrieval and route lookup based on the plaintext session index, and synchronously updates the NAT mapping status of the terminal. Subsequently, it performs next-hop routing forwarding based on the short identity identifier of the destination node.

[0222] The foregoing has provided a detailed description of a zero-handshake, high-security tunnel forwarding system, method, and readable storage medium for narrowband satellite links, as provided in the embodiments of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application; furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

[0223] Certain terms are used in the specification and claims to refer to specific components. Those skilled in the art will understand that hardware manufacturers may use different names to refer to the same component. This specification and claims do not distinguish components based on differences in name, but rather on differences in function. The terms "comprising" and "including" used throughout the specification and claims are open-ended and should be interpreted as "comprising / including but not limited to". "Approximately" means that within an acceptable margin of error, those skilled in the art can solve the technical problem and substantially achieve the technical effect within a certain margin of error. The following descriptions in the specification are preferred embodiments for carrying out this application; however, these descriptions are for the purpose of illustrating the general principles of this application and are not intended to limit the scope of this application. The scope of protection of this application shall be determined by the appended claims.

[0224] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0225] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0226] The foregoing description illustrates and describes several preferred embodiments of this application. However, as previously stated, it should be understood that this application is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the application concept described herein through the foregoing teachings or techniques or knowledge in related fields. Any modifications and variations made by those skilled in the art that do not depart from the spirit and scope of this application should be within the protection scope of the appended claims.

Claims

1. A zero-handshake, high-security tunneling forwarding system for narrowband satellite links, characterized in that, It includes a terminal device and a relay gateway device, which are connected via a narrowband satellite link. The terminal device includes a key generation unit, a random number calculation unit, a payload encryption unit, and a message assembly and transmission unit connected in sequence. The relay gateway device includes a message parsing and decryption unit, an authentication and verification unit, a mapping management unit, and a service forwarding unit connected in sequence. The message assembly and sending unit communicates with the message parsing and decryption unit. The key generation unit adopts a zero-handshake key derivation mechanism and does not perform handshake interaction with the relay gateway device. The payload encryption unit is used to encrypt the device identity identifier to obtain the ciphertext payload; The message assembly and sending unit adopts a plaintext double-label microtunnel encapsulation mechanism to generate and send microtunnel messages with a total tunnel protocol overhead of no more than 16 bytes. The message parsing and decryption unit is used to receive and decrypt messages; The authentication and verification unit is used to complete the device identity authentication and verification. The mapping management unit is used to establish and maintain tunnel mapping relationships; The service forwarding unit adopts the NAT traversal mechanism.

2. The zero-handshake high-security tunnel forwarding system for narrowband satellite links according to claim 1, characterized in that, The zero-handshake key derivation mechanism of the key generation unit generates a symmetric session key and a basic random number by using a locally generated temporary private key and a pre-set public key of the relay gateway device through an elliptic curve key exchange algorithm. Specifically, it includes: Obtain the session state identifier and a temporary asymmetric key pair, wherein the temporary asymmetric key pair includes a temporary private key and a temporary public key; Retrieve the public key of the locally pre-stored relay gateway device; An elliptic curve key exchange algorithm is used, which combines the user's own temporary private key with the public key of the relay gateway device to calculate and generate a symmetric session key and a basic random number.

3. The zero-handshake high-security tunnel forwarding system for narrowband satellite links according to claim 1, characterized in that, The random number calculation unit adopts an implicit nonce mechanism, as detailed below: Obtain the absolute serial number maintained locally in real time; Extract the low-order bits of the absolute sequence number as a local sequence number; The high-order bits of the absolute sequence number are padded with zeros to generate an extended sequence number with the same length as the base random number. Perform a bitwise XOR operation on the extended sequence number and the basic random number to obtain a one-time random number that dynamically changes with the message sequence number without incurring additional transmission overhead.

4. The zero-handshake high-security tunnel forwarding system for narrowband satellite links according to claim 1, characterized in that, The payload encryption unit works in conjunction with the message assembly and transmission unit, specifically for: The payload encryption unit performs symmetric encryption on the physical identity and device configuration information according to the symmetric session key and the one-time random number, generates an initial ciphertext payload and a standard authentication tag, truncates and simplifies the standard authentication tag to obtain a truncated authentication tag, appends the truncated authentication tag to the end of the initial ciphertext payload, and integrates them to obtain a complete ciphertext payload. The plaintext dual-label microtunnel encapsulation mechanism of the message assembly and sending unit is used to concatenate the session state identifier, the target short identity identifier, and the local sequence number into an 8-byte plaintext tunnel header, and concatenate the ciphertext payload with the truncated authentication label to generate a microtunnel message with a total tunnel protocol overhead of no more than 16 bytes and send it. The message assembly and sending unit concatenates the session state identifier, the target physical identity identifier, and the local sequence number to generate a plaintext tunnel header, configures the temporary public key as the plaintext payload, and concatenates and assembles the first message in a fixed order of outer network protocol header, plaintext tunnel header, plaintext payload, and ciphertext payload. The first message is then sent to the relay gateway device via a narrowband satellite wireless link. The target physical identity identifier is a gateway-specific addressing identifier preset by the relay gateway device.

5. The zero-handshake high-security tunnel forwarding system for narrowband satellite links according to claim 1, characterized in that, The message parsing and decryption unit and the authentication and verification unit work together to complete message decryption and identity authentication, specifically for: The receiving terminal device sends the first message and initializes the corresponding local absolute sequence number for the received session state identifier; The complete absolute sequence number is reconstructed by combining the local sequence number carried in the message with the local absolute sequence number. The complete absolute sequence number is then XORed with the base random number to obtain a one-time random number. The symmetric session key and the one-time random number are used to decrypt and verify the integrity of the encrypted payload. After the decryption verification is successful, the physical identity identifier of the terminal device is extracted from the decrypted data. Verify whether the physical identity is registered in the preset identity whitelist. If the verification passes, the device authentication is deemed legitimate.

6. The zero-handshake high-security tunnel forwarding system for narrowband satellite links according to claim 1, characterized in that, The mapping management unit is specifically used for: Extract the outer source network protocol address and outer source user datagram protocol port number from the first message and combine them as the outer network address information; In the local memory cache, a six-tuple mapping record is established, which includes the terminal device's physical identity identifier, session state identifier, outer source network protocol address, outer source user datagram protocol port number, symmetric session key, and sequence number. Based on the symmetric session key, an acknowledgment message carrying the physical identity of the terminal device is encapsulated and sent back to the terminal device to complete the tunnel link initialization confirmation.

7. The zero-handshake high-security tunnel forwarding system for narrowband satellite links according to claim 1, characterized in that, The following NAT traversal mechanism of the service forwarding unit dynamically overwrites the network address parameters in the mapping record based on the latest outer network address information of the service packet after the decryption verification is successful, so as to achieve following NAT traversal and seamless roaming recovery without re-handshaking, and complete the tunnel forwarding of the service packet. Specifically, it includes: Receive service messages uploaded by terminal devices and extract the session state identifier and current local sequence number carried in the messages; The corresponding six-tuple mapping record is retrieved using the session state identifier, and the matching symmetric session key and basic random number are obtained. The current one-time random number is calculated in real time by combining the current local sequence number with the basic random number, and the encrypted payload of the service message is decrypted and verified based on the symmetric session key and the current one-time random number. If the decryption verification passes, the current outer network address information of the business message is extracted, and the network address parameters in the mapping record are dynamically updated based on the latest outer network address information.

8. The zero-handshake high-security tunnel forwarding system for narrowband satellite links according to claim 7, characterized in that, The service forwarding unit is also used for: Extract the physical identity identifier of the peer device to be communicated from the decrypted business message; Based on the physical identity of the peer device, query the target outer network address information and the target symmetric session key bound in the mapping record; The decrypted business data is re-encrypted using the target symmetric session key to generate re-encrypted business data. Based on the target outer network address information and the re-encrypted service data, a standardized forwarding message is generated and accurately sent to the corresponding terminal device to complete the service tunnel forwarding.

9. A zero-handshake high-security tunnel forwarding method for narrowband satellite links, used to implement the zero-handshake high-security tunnel forwarding system for narrowband satellite links according to any one of claims 1-8, characterized in that, Includes the following steps: S1. Obtain the session state identifier and a temporary asymmetric key pair, wherein the temporary asymmetric key pair includes a temporary private key and a temporary public key; S2. Determine the symmetric session key and the basic random number based on the temporary private key and the preset relay device public key; S3. Determine a one-time random number based on the local sequence number and the basic random number; S4. Encrypt the physical identity identifier using the symmetric session key and the one-time random number to obtain the ciphertext payload; S5. Assemble a first message based on the session state identifier, target physical identity identifier, local sequence number, temporary public key and ciphertext payload, and send the first message to the relay end; S6. Receive the first message, parse the symmetric session key and the basic random number according to the temporary public key and the local private key, calculate a one-time random number according to the local sequence number and the basic random number, and decrypt the ciphertext payload through the symmetric session key and the one-time random number to obtain the physical identity identifier of the communication terminal; S7. Establish a corresponding mapping relationship based on the physical identity identifier of the communication terminal, the session state identifier, the outer network address information of the first message, the symmetric session key and the sequence number; S8. Receive uploaded service messages; S9. Based on the established mapping relationship, complete the tunnel forwarding of the service message.

10. A readable storage medium, characterized in that, The readable storage medium stores a computer-executable program, which, when executed by a processor, implements all the steps of the zero-handshake high-security tunnel forwarding method for narrowband satellite links as described in claims 1-8.

Images