Zero trust gateway data access method, client, gateway, communication system, storage medium and computer program product

Abstract

This application provides a zero-trust gateway data access method, client, gateway, communication system, storage medium, and computer program product. The method is applied to a client and includes: sending a single-packet authorization request message to the zero-trust gateway; receiving a single-packet authorization response message including ciphertext of a first key factor; decrypting the first key factor using a first private key; sending the first authentication information and the second key factor ciphertext to the zero-trust gateway, so that the zero-trust gateway generates a session key based on the first and second key factors using a preset algorithm; simultaneously, the client also generates a session key based on the first and second key factors using a preset algorithm; and establishing a connection channel with the zero-trust gateway based on the session key. This application uses a zero-trust gateway, which offers high security; and the data packet structure is designed with privacy in mind, resulting in fewer vulnerabilities and a lower risk of attack.

Description

Technical Field

[0001] This application relates to the field of network communication, specifically to a zero-trust gateway data access method, client, gateway, communication system, storage medium, and computer program product. Background Technology

[0002] Virtual Private Networks (VPNs), as a key technology for ensuring network communication security, have developed into a relatively mature system after years of development and play an important role in the current digital age. With the rapid growth of remote work needs, the global VPN market continues to expand, reaching a scale of hundreds of billions of yuan in 2023, with both enterprise and personal VPN demand growing simultaneously. Currently, VPN products mainly use two protocols: SSL / TLS and IPSec. The former operates at the TCP / UDP layer, while the latter operates at the IP network layer. Because these two protocols are the most widely used and supported by mature open-source projects, most vendors develop products based on open-source libraries. Hackers study the code of open-source projects more extensively, and security vulnerabilities in products developed based on open-source code have been discovered by numerous hackers. Therefore, for application scenarios with very high security requirements, using such VPN products will face significant security risks.

[0003] The main vulnerabilities of the secure tunnels provided by products based on SSL / TLS and IPSec protocols are: (1) Protocol vulnerabilities, such as zero-day vulnerabilities and encryption defects. These vulnerabilities affect remote code execution and data leakage. A typical example is CVE-2025-0282 of Ivanti VPN; (2) Imperfect key management, which is manifested in low key update efficiency and lack of PFS (Perfect Forward Secrecy). This affects session support and decryption of historical communications. A typical example is traditional IPSec key negotiation; (3) Architectural defects, which are manifested in Tunnel Crack and brute-force attacks. This affects traffic hijacking and unauthorized access. A typical example is the brute-force attack of Fortinet; (4) Maintenance problems, which are manifested in delayed patching and insecure firmware. This leads to long-term exposure of the device and control of the device. A typical example is the decryption problem of FortiOS firmware.

[0004] Therefore, there is a need to provide a zero-trust gateway data access method, client, gateway, communication system, storage medium, and computer program product to solve the above problems. Summary of the Invention

[0005] This application is made in view of at least one of the above-mentioned technical problems existing in the prior art. According to one aspect of this application, a zero-trust gateway data access method is provided, applied to a client, the zero-trust gateway data access method comprising:

[0006] Send a single-packet authorization request message to the zero-trust gateway;

[0007] Receive a single-packet authorization response message returned by the zero-trust gateway in response to the single-packet authorization request message; wherein, the single-packet authorization response message is generated by the zero-trust gateway after verifying and passing the single-packet authorization request message, and the single-packet authorization response message includes a first key factor ciphertext;

[0008] The first key factor is obtained by decrypting the ciphertext of the first key factor using the first private key.

[0009] A second key factor and first identity authentication information are generated. The second key factor is encrypted to obtain the second key factor ciphertext. The first identity authentication information and the second key factor ciphertext are sent to the zero trust gateway so that the zero trust gateway can decrypt the second key factor ciphertext to obtain the second key factor. A session key is generated based on the first key factor and the second key factor using a preset algorithm.

[0010] Receive the second identity authentication information returned by the zero-trust gateway;

[0011] Verify the second identity authentication information, and if the verification is successful, generate a session key based on the first key factor and the second key factor using a preset algorithm;

[0012] A connection channel is established with the zero-trust gateway based on the session key, so as to transmit data packets with the zero-trust gateway using the connection channel.

[0013] In some embodiments, the data packet includes a protocol header and a protocol body; the protocol header includes at least a message type;

[0014] Wherein, when the message type is a data transmission type, the protocol body includes at least data content, a checksum, and first padding data; wherein, the data content and the first padding data are both variable-length data; where the message type is a key update type, the protocol body includes at least a gateway new key, a client new key, a timestamp, a checksum, and second padding data; wherein, the second padding data is variable-length data.

[0015] In some embodiments, when the client transmits data packets with the zero-trust gateway using the connection channel, the protocol header is encrypted by the gateway key; and the protocol body is encrypted by the session key.

[0016] The gateway key is generated by the zero-trust gateway and reported to the key management center, which then sends it to the client.

[0017] In some embodiments, the method further includes:

[0018] The data packets are filled based on a preset message filling algorithm.

[0019] In some embodiments, the data packet is encapsulated by at least one zero-trust single-packet authorized data packet; filling the data packet based on a preset packet filling algorithm includes:

[0020] Calculate the minimum and maximum length of the ciphertext for a single zero-trust single-packet authorized data packet;

[0021] The padding code length is calculated using the Rand function based on the minimum and maximum lengths.

[0022] Based on the padding code length, padding data is generated using a preset padding algorithm, and the padding data is added to any zero-trust single-packet authorization data packet; wherein, the padding data includes a random number generated based on the padding code length.

[0023] In some embodiments, the protocol body further includes payload data and a data integrity and authenticity check code; wherein, the filling of the data packet based on a preset message filling algorithm includes:

[0024] The payload data is then populated.

[0025] In some embodiments, the length of the padded data packet does not exceed the length of the maximum transmission unit.

[0026] In some embodiments, characterized in that,

[0027] The message header also includes a client identifier and a zero-trust gateway identifier; wherein, the key management center distributes a first private key and a second private key to the client and the zero-trust gateway respectively based on the client identifier and the zero-trust gateway identifier;

[0028] The message header also includes a counter; the counter includes a message sequence number; the message sequence number is randomly generated based on the number of times the data message is sent, and the message sequence number is used by the zero-trust gateway to detect network attacks.

[0029] According to another aspect of this application, a zero-trust gateway data access method is also provided, applied to a zero-trust gateway, the method comprising:

[0030] Receive single-packet authorization request messages sent by the client;

[0031] The single-packet authorization request message is verified, and a single-packet authorization response message is generated after successful verification; wherein, the single-packet authorization response message includes the ciphertext of the first key factor;

[0032] The single-packet authorization response message is sent to the client, so that the client can use the first private key to decrypt the ciphertext of the first key factor to obtain the first key factor;

[0033] Receive the first authentication information and the second key factor ciphertext sent by the client;

[0034] The first identity authentication information is verified, and after the verification is successful, the second key factor is decrypted using the second private key to obtain the second key factor. A session key is generated based on the first key factor and the second key factor using a preset algorithm.

[0035] A second identity authentication information is generated and sent to the client, so that the client, upon successful authentication, generates the session key using the preset algorithm based on the first key factor and the second key factor;

[0036] A connection channel is established with the client based on the session key, so as to transmit data packets with the client using the connection channel.

[0037] In some embodiments, the data packet includes a protocol header and a protocol body; the protocol header includes at least a message type;

[0038] Wherein, when the message type is a data transmission type, the protocol body includes at least data content, a checksum, and first padding data; wherein, the data content and the first padding data are both variable-length data; where the message type is a key update type, the protocol body includes at least a gateway new key, a client new key, a timestamp, a checksum, and second padding data; wherein, the second padding data are both variable-length data.

[0039] In some embodiments, the method further includes: filling the data packet based on a preset message filling algorithm.

[0040] In some embodiments, the data packet is encapsulated by at least one zero-trust single-packet authorized data packet; filling the data packet based on a preset packet filling algorithm includes:

[0041] Calculate the minimum and maximum length of the ciphertext for a single zero-trust single-packet authorized data packet;

[0042] The padding code length is calculated using the Rand function based on the minimum and maximum lengths.

[0043] Based on the padding code length, padding data is generated using a preset padding algorithm, and the padding data is added to any zero-trust single-packet authorization data packet; wherein, the padding data includes a random number generated based on the padding code length.

[0044] In some embodiments, the protocol body further includes payload data and a data integrity and authenticity check code; wherein, the filling of the data packet based on a preset message filling algorithm includes:

[0045] The payload data is then populated.

[0046] In some embodiments, the length of the padded data packet does not exceed the length of the maximum transmission unit.

[0047] In some embodiments, the method further includes:

[0048] When the client transmits data packets with the zero-trust gateway using the connection channel, the protocol header is encrypted with the gateway key; the protocol body is encrypted with the session key.

[0049] The gateway key is generated by the zero-trust gateway and reported to the key management center, which then sends it to the client.

[0050] In some embodiments, the method further includes:

[0051] Under the condition that the preset triggering conditions are met, the session key and the gateway key are updated according to the preset strategy to obtain the new session key and the new gateway key.

[0052] The new session key and the new gateway key are sent to the client to enable communication with the client based on the new session key and the new gateway key.

[0053] In some embodiments, triggering an update of the session key according to a preset policy includes:

[0054] A first new key factor is generated when the preset triggering conditions are met;

[0055] The client sends a key update message and synchronously records the new key factor for the session connection. The client decrypts the key update message to obtain the new key factor, generates a second new key factor, and sends the second new key factor to the zero-trust gateway. The client uses the preset algorithm to generate the new session key based on the first new key factor and the second new key factor.

[0056] The system receives the second new key factor ciphertext sent by the client, decrypts the second new key factor ciphertext to obtain the second new key factor, and uses the preset algorithm to generate the new session key based on the first new key factor and the second new key factor.

[0057] In some embodiments, the process of updating the session key is triggered according to a preset strategy, and the coexistence time of the original session key and the new session key is a preset time; the method further includes:

[0058] If a data packet encrypted with the original session key is received, the data packet is decrypted using the original session key; if a data packet encrypted with the new session key is received, the data packet is decrypted using the new session key.

[0059] In some embodiments, the method further includes:

[0060] The gateway key is updated according to the preset update policy, and the new gateway key is sent to the key management center, which then sends the new gateway key to the client.

[0061] In some embodiments, the method further includes:

[0062] Receive zero-trust SPA data packets sent from the same source address;

[0063] If the number of failed decryption attempts for the zero-trust SPA data packet is greater than or equal to a preset number, the source address will be reported to the security center for early warning.

[0064] The source address is cleared according to the preset security policy.

[0065] In some embodiments, the method further includes:

[0066] When decryption fails, record the number of decryption failures for the data packet corresponding to the source address;

[0067] If decryption is successful before the preset number of failures is reached, the decryption failure record corresponding to the source address is cleared.

[0068] In some embodiments, the method further includes:

[0069] Decryption failure includes failure to decrypt the protocol header and / or protocol body of the data packet.

[0070] In some embodiments, the header further includes a counter; the counter includes a message sequence number; the message sequence number is randomly generated based on the number of times the data packet is sent, and the message sequence number is used by the zero-trust gateway to detect whether a network attack exists.

[0071] According to another aspect of this application, a client is also provided for implementing the zero-trust gateway data access method described above, the client comprising:

[0072] The first sending module is used to send a single-packet authorization request message to the zero-trust gateway;

[0073] The first receiving module is configured to receive a single-packet authorization response message returned by the zero-trust gateway in response to the single-packet authorization request message; wherein the single-packet authorization response message is generated by the zero-trust gateway after verifying and passing the single-packet authorization request message, and the single-packet authorization response message includes a first key factor ciphertext;

[0074] The first decryption module is used to decrypt the ciphertext of the first key factor using the first private key to obtain the first key factor;

[0075] The first sending module is further configured to generate a second key factor and first identity authentication information, encrypt the second key factor to obtain second key factor ciphertext, send the first identity authentication information and second key factor ciphertext to the zero trust gateway, so that the zero trust gateway can decrypt the second key factor ciphertext to obtain the second key factor, and generate the session key based on the first key factor and the second key factor using the preset algorithm.

[0076] The first receiving module is also used to receive the second identity authentication information returned by the zero-trust gateway;

[0077] The first verification module is used to verify the second identity authentication information. If the verification is successful, a session key is generated based on the first key factor and the second key factor using a preset algorithm.

[0078] The first connection module is used to establish a connection channel with the zero-trust gateway based on the session key, so as to use the connection channel to transmit data packets with the zero-trust gateway.

[0079] According to another aspect of this application, a zero-trust gateway is also provided for implementing the zero-trust gateway data access method described above, the zero-trust gateway comprising:

[0080] The second receiving module is used to receive single-packet authorization request messages sent by the client;

[0081] The second verification module is used to verify the single-packet authorization request message and generate a single-packet authorization response message after the verification is successful; wherein, the single-packet authorization response message includes the first key factor ciphertext;

[0082] The second decryption module is used to send the single-packet authorization response message to the client, so that the client can use the first private key to decrypt the first key factor ciphertext and obtain the first key factor;

[0083] The second receiving module is also used to receive the first identity authentication information and the second key factor ciphertext sent by the client;

[0084] The second verification module is also used to verify the first identity authentication information, and after the verification is successful, to decrypt the second key factor ciphertext using the second private key to obtain the second key factor, and to generate the session key based on the first key factor and the second key factor using a preset algorithm;

[0085] The second sending module is used to generate second identity authentication information and send the second identity authentication information to the client, so that the client can generate the session key based on the first key factor and the second key factor using the preset algorithm when the authentication is successful;

[0086] The second connection module is used to establish a connection channel with the client based on the session key, so as to use the connection channel to transmit data packets with the client.

[0087] According to another aspect of this application, a zero-trust gateway data access system is also provided, characterized in that it includes at least one client and a gateway.

[0088] According to another aspect of this application, a zero-trust gateway data access system is also provided, comprising: at least one client and a zero-trust gateway; wherein,

[0089] Any one of the at least one clients is used for:

[0090] Send a single-packet authorization request message to the zero-trust gateway;

[0091] Receive a single-packet authorization response message returned by the zero-trust gateway in response to the single-packet authorization request message; wherein, the single-packet authorization response message is generated by the zero-trust gateway after verifying and passing the single-packet authorization request message, and the single-packet authorization response message includes a first key factor ciphertext;

[0092] The first key factor is obtained by decrypting the ciphertext of the first key factor using the first private key.

[0093] A second key factor and first identity authentication information are generated. The second key factor is encrypted to obtain the second key factor ciphertext. The first identity authentication information and the second key factor ciphertext are sent to the zero trust gateway so that the zero trust gateway can decrypt the second key factor ciphertext to obtain the second key factor. A session key is generated based on the first key factor and the second key factor using a preset algorithm.

[0094] Receive the second identity authentication information returned by the zero-trust gateway;

[0095] Verify the second identity authentication information, and if the verification is successful, generate a session key based on the first key factor and the second key factor using a preset algorithm;

[0096] A connection channel is established with the zero-trust gateway based on the session key, so as to transmit data packets with the zero-trust gateway using the connection channel;

[0097] The zero-trust gateway is used for:

[0098] Receive single-packet authorization request messages sent by the client;

[0099] The single-packet authorization request message is verified, and a single-packet authorization response message is generated after successful verification; wherein, the single-packet authorization response message includes the ciphertext of the first key factor;

[0100] The single-packet authorization response message is sent to the client, so that the client can use the first private key to decrypt the ciphertext of the first key factor to obtain the first key factor;

[0101] Receive the first authentication information and the second key factor ciphertext sent by the client;

[0102] The first identity authentication information is verified, and after the verification is successful, the second key factor is obtained by decrypting the ciphertext of the second key factor using the second private key. The session key is then generated based on the first key factor and the second key factor using a preset algorithm.

[0103] A second identity authentication information is generated and sent to the client, so that the client, upon successful authentication, generates the session key using the preset algorithm based on the first key factor and the second key factor;

[0104] A connection channel is established with the client based on the session key, so as to transmit data packets with the client using the connection channel.

[0105] According to another aspect of this application, a storage medium is also provided, on which a computer program is stored, which, when run by a processor, causes the processor to execute the zero-trust gateway data access method as described above.

[0106] According to another aspect of this application, a computer program product is also provided, wherein the computer program / instructions, when executed by a processor, implement the steps of the method described above.

[0107] The zero-trust gateway data access method of this application embodiment involves a client sending a single-packet authorization request message to a zero-trust gateway. The zero-trust gateway generates a first key factor and sends the first key factor ciphertext to the client. After receiving the first key factor, the client generates a second key factor and sends the second key factor ciphertext to the zero-trust gateway. The zero-trust gateway returns second authentication information. The client and the zero-trust gateway decrypt the first key factor ciphertext and the second key factor ciphertext, respectively, thus both the client and the zero-trust gateway obtain the first key factor and the second key factor. Then, the client and the zero-trust gateway use the same preset algorithm to generate a session key based on the first key factor and the second key factor, and establish a connection channel with the zero-trust gateway based on the session key to transmit data packets with the zero-trust gateway using the connection channel. The zero-trust gateway data access method of this application embodiment has the following beneficial effects;

[0108] (1) The secure tunnel established by the technical solution of this application combines the security concept of "authentication before opening" of zero trust. The data port of the zero trust gateway is in an open state before authentication. Even if there is a network attack, the data port of the zero trust gateway cannot be detected, so the security is high.

[0109] (2) The technical solution of this application embodiment has a private design for the data packet structure. Compared with the SSL / TLS and IPSec protocol packets in traditional technologies, it has fewer vulnerabilities and a lower risk of attack.

[0110] (3) The security tunnel protocol of this application implements the zero-trust "default rejection" principle. Before the SPA message passes the verification, a silent mechanism is adopted, so the attacker cannot perceive the existence of the zero-trust gateway, thus realizing the network stealth capability.

[0111] (4) The secure tunnel protocol of this application embodiment is based on identity cryptography, which does not require a certificate, and therefore does not require the steps of certificate verification and certificate transmission, reducing the amount of computation and data transmission, and also reducing the number of handshake interactions required for connection, thus greatly improving the overall performance of the network system. Attached Figure Description

[0112] Figure 1A schematic flowchart illustrating a zero-trust gateway data access method according to an embodiment of this application is shown.

[0113] Figure 2 A signaling diagram illustrating a zero-trust gateway data access method according to an embodiment of this application is shown;

[0114] Figure 3(a) shows a schematic diagram of the header of a data packet according to an embodiment of this application;

[0115] Figure 3(b) shows a schematic diagram of the protocol body of a data transmission type data packet according to an embodiment of this application;

[0116] Figure 3(c) shows a schematic diagram of the protocol body of a key update type data message according to an embodiment of this application;

[0117] Figure 4 A schematic flowchart illustrating a process 400 of filling a data packet based on a preset message filling algorithm according to an embodiment of this application is shown.

[0118] Figure 5 A schematic flowchart of a key management process 500 according to an embodiment of this application is shown;

[0119] Figure 6 A schematic flowchart illustrating step S501 according to an embodiment of this application is shown;

[0120] Figure 7 A schematic flowchart illustrating the process of decrypting a data packet during a session key update according to an embodiment of this application;

[0121] Figure 8 A schematic flowchart illustrating the network attack detection process of a zero-trust gateway according to an embodiment of this application is shown.

[0122] Figure 9 A schematic flowchart illustrating the use of a preset security policy to clear source addresses according to an embodiment of this application is shown.

[0123] Figure 10 A schematic block diagram of a client 1000 according to an embodiment of this application is shown;

[0124] Figure 11 A schematic block diagram of a zero-trust gateway 1100 according to an embodiment of this application is shown;

[0125] Figure 12 A schematic block diagram of a zero-trust gateway data access system 1200 according to an embodiment of this application is shown. Detailed Implementation

[0126] The technical concept of the present invention will be described in detail below with reference to specific embodiments. It is readily understood that the embodiments described in this disclosure are merely illustrative and not all implementations of the present invention. Those skilled in the art, upon obtaining the description of the basic concept of the present invention in this disclosure and in conjunction with the given embodiments, can obtain other ways of implementing the present invention without creative effort, and can also make further improvements based on the basic concept of the present invention. All such variations or improvements fall within the scope defined by the claims of this application.

[0127] This application provides a zero-trust gateway data access method applied to a client. The method includes: sending a single packet authorization (SPA) request message to a zero-trust gateway; receiving a single packet authorization response message returned by the zero-trust gateway in response to the SPA request message; wherein the SPA response message is generated by the zero-trust gateway after verifying and passing the SPA request message, and the SPA response message includes a first key factor ciphertext; decrypting the first key factor ciphertext using a first private key to obtain a first key factor; generating a second key factor and first authentication information, and encrypting the second key factor to obtain a second key factor. The first identity authentication information and the second key factor ciphertext are sent to the zero-trust gateway, so that the zero-trust gateway can decrypt the second key factor ciphertext to obtain the second key factor, and generate the session key based on the first key factor and the second key factor using the preset algorithm; the second identity authentication information returned by the zero-trust gateway is received; the second identity authentication information is verified, and if the verification is successful, the session key is generated based on the first key factor and the second key factor using the preset algorithm; a connection channel is established with the zero-trust gateway based on the session key, so as to transmit data packets with the zero-trust gateway using the connection channel.

[0128] This application also provides a zero-trust gateway data access method, applied to a zero-trust gateway. The method includes: receiving a single-packet authorization request message sent by a client; verifying the single-packet authorization request message, and generating a single-packet authorization response message after successful verification; wherein the single-packet authorization response message includes a first key factor ciphertext; sending the single-packet authorization response message to the client, so that the client decrypts the first key factor ciphertext using a first private key to obtain a first key factor; receiving first identity authentication information and a second key factor ciphertext sent by the client; verifying the first identity authentication information, and after successful verification, decrypting the second key factor ciphertext using a second private key to obtain a second key factor, and generating a session key based on the first key factor and the second key factor using a preset algorithm; generating second identity authentication information and sending the second identity authentication information to the client, so that the client, upon successful verification, generates the session key based on the first key factor and the second key factor using the preset algorithm; establishing a connection channel with the client based on the session key, and transmitting data packets with the client using the connection channel.

[0129] This application employs a digital signature and key exchange protocol based on identifier cryptography to authenticate the authenticity of both communicating parties in a secure tunnel and negotiate keys. This reduces the number of handshake interactions and third-party dependencies during tunnel establishment, thereby improving tunnel performance. Simultaneously, the packet encapsulation design is improved to increase the difficulty of data packet analysis by hackers, thus enhancing the security of the tunnel protocol.

[0130] The technical solution of this application improves the protocol design to address the security risks of the current SSL / TLS and IPSec protocols, thereby creating an application that meets higher security requirements. The zero-trust gateway data access method of this application has the following beneficial effects: (1) The security tunnel established by the technical solution of this application combines the "authenticate first, open later" security concept of zero trust. The data port of the zero-trust gateway is not open before authentication. Even if there is a network attack, the data port of the zero-trust gateway cannot be detected, resulting in high security. (2) The technical solution of this application uses a private design for the data packet structure. Compared with the SSL / TLS and IPSec protocol packets in traditional technologies, it has fewer vulnerabilities and a lower risk of attack. (3) The security tunnel protocol of this application implements the "default denial" principle of zero trust. Before the SPA packet passes verification, a silent mechanism is used, and attackers cannot perceive the existence of the zero-trust gateway, thus achieving network stealth capability. (4) The secure tunnel protocol of this application embodiment is based on identity cryptography, which does not require a certificate, and therefore does not require the steps of certificate verification and certificate transmission, reducing the amount of computation and data transmission, and also reducing the number of handshake interactions required for connection, thus greatly improving the overall performance of the network system.

[0131] The technical terms used in this application are explained as follows:

[0132] Software Defined Perimeter (SDP) is a security framework developed by the Cloud Security Alliance (CSA) that controls access to resources based on identity. Each endpoint must be authenticated before connecting to the server, ensuring that each device is authorized to access. Its core idea is to hide core network assets and infrastructure from direct exposure to the internet through the SDP architecture, thus protecting them from external security threats. SDP aims to leverage standards-based and validated components such as data encryption, remote authentication (host authentication of remote access), Transport Layer Security (TLS, a method for encrypting and verifying client information), and Security Assertion Markup Language (SAML). It relies on encryption and digital signatures to protect specific access and verify access via X.509 certificate public keys. Combining these technologies with other standards-based technologies ensures that SDP can be integrated with existing enterprise security systems.

[0133] Single Packet Authorization (SPA) is a lightweight security protocol. Unlike the traditional TCP three-way handshake mechanism, it uses only a single data packet to request access. By integrating all necessary information into a single packet, it simplifies the access process. Before granting network access, it verifies the device and user's identity, thus achieving "network stealth" and preventing attackers from finding the service address and port. The core principles of SPA are threefold: first, integrating authentication information into a single data packet to simplify the access process; second, pre-authenticating devices and not responding to connection requests from outside the authenticated device; and third, hiding the service behind a firewall to achieve "network stealth."

[0134] Zero Trust Security Model: Also known as Zero Trust Architecture, Zero Trust Network Architecture, ZTA, ZTNA, etc., and sometimes called perimeterless security, this concept describes a methodology for designing and implementing IT systems. The main concept of the Zero Trust Security Model is "Never Trust, Always Authenticate," meaning devices should not be trusted by default, even if they are connected to a permitted network (e.g., a corporate LAN) and have previously been authenticated. Most modern enterprise networks are complex, containing numerous interconnected areas, cloud services, and infrastructure, as well as connections to remote and mobile environments and unconventional IT connections (e.g., IoT devices). The Zero Trust principle stems from the fact that traditional methods (such as trusting devices within a nominal "corporate perimeter" or devices connecting via VPNs) are ill-suited to the complexity of enterprise network environments. Zero Trust advocates for mutual authentication, including checking device identity and integrity regardless of location, and combining user authentication with confidence levels based on device identity and status to grant access to applications and services.

[0135] Figure 1 A schematic flowchart illustrating a zero-trust gateway data access method according to an embodiment of this application is shown; as follows: Figure 1 As shown, the zero-trust gateway data access method 100 according to an embodiment of this application may include the following steps S101, S102, S103, S104, S105, S106, S107, and S108:

[0136] In step S101, the client sends a Single Packet Authorization (SPA) request message to the zero-trust gateway.

[0137] In a zero-trust network architecture, a zero-trust SPA (Single Packet Authorization Packet) request message (or data packet) is a technical means to complete authentication and authorization through a single data packet before a network connection is established. Its core function is to hide the server port, prevent network reconnaissance attacks, and ensure that only authenticated clients can establish subsequent communication.

[0138] The core principle of SDP is that any unauthorized entity cannot access not only business systems (resources) but also the SDP infrastructure itself. To achieve this, entities must undergo cryptographically-based authorization verification before connecting to any SDP component. This mechanism enhances the security and resilience of SDP, preventing unauthorized entities from establishing network connections with SDP components (such as SDP controllers or gateways), thus preventing attempts at exploitation, brute-force attacks, or the use of stolen user accounts and passwords. This solves the technical problem of traditional technologies (such as VPNs) being easily exposed to malicious attackers on the internet.

[0139] The principle of preventing unauthorized access is based on the SPA (Single Packet Authorization) protocol. One of the key technologies is the HMAC one-time password (HOTP, RFC4226), which can prevent authorization packet duplication attacks. SPA message verification is relatively lightweight, which can improve the SDP system's resilience against DDoS attacks. The main principles for implementing SPA in the system are: (1) hiding SDP system components (SDP controller, SDP gateway); (2) mitigating denial-of-service attacks against TLS; and (3) attack detection.

[0140] SPA messages fall into two categories: first, the initial SPA message between the communicating parties (i.e., the single-packet authorization request message mentioned above); and second, SPA messages used in subsequent communications. During the initial communication, the sender (client) and receiver (zero-trust gateway) do not share a common SPA message key. If the receiver is known (e.g., ZCC), the initial common key is calculated using the ECDH protocol. If the receiver's identity is uncertain, configuring the accompanying public key is complex. In this case, the sender digitally signs the SPA message content, and the receiver verifies the signature's validity to determine if the SPA passes verification (since there is no common key when generating the SPA message, the HOTP and HMAC fields are empty).

[0141] It is worth noting that the premise of this application embodiment is that both the sender and the receiver have completed the application for the identification key in advance, have the identification cryptography module and their respective identification private key, system parameters and system public key, and have cryptographic capabilities such as signing, verification, data encryption and random number generation based on the identification cryptography.

[0142] In step S102, the zero-trust gateway verifies the single-packet authorization request message, and after successful verification, generates a single-packet authorization response message and sends it to the client.

[0143] In one example, the zero-trust gateway verifies single-packet authorization request messages. For instance, the zero-trust gateway (including the SDP controller) extracts user information, service request ciphertext, a digest of the service request ciphertext, and the current timestamp from the single-packet authorization request message. It then verifies the time validity of the single-packet authorization request message based on the current timestamp and verifies the information validity of the service request ciphertext based on the digest of the service request ciphertext. If both verifications pass, a specific service port is opened, allowing the client to negotiate a session key with the zero-trust gateway through that specific service port.

[0144] Furthermore, the zero-trust gateway can verify the time validity of a single-packet authorization request message using the current timestamp. For example, the SDP controller verifies the time validity of the single-packet authorization request message based on the current timestamp in the message. The SDP controller itself can obtain its current timestamp and compare it with the timestamp in the single-packet authorization request message. If the difference between the two timestamps is within a preset range, and the SDP controller's current timestamp is greater than the timestamp in the message, the single-packet authorization request message is deemed valid, meaning it has not been tampered with or is not subject to a replay attack. If the difference between the two timestamps is not within the preset range, or the SDP controller's current timestamp is less than or equal to the timestamp in the message, the single-packet authorization request message is deemed invalid, meaning it has been tampered with or is subject to a replay attack.

[0145] In this embodiment, the port of the zero-trust gateway is hidden. By default, the zero-trust gateway closes all service ports, retaining only one dedicated UDP (User Datagram Protocol, UDP) access port (e.g., Sangfor aTrust's UDP SPA). The client must first send a single-packet authorization request message (or SPA packet) to this port. Only after the zero-trust gateway verifies the request will the specific service port be opened. This single-packet authorization mechanism eliminates the need for multiple interactions during connection establishment; the client can complete authentication with a single SPA message or packet, avoiding the exposure of the zero-trust gateway's location and port information, thus ensuring high security.

[0146] Additionally, the single-packet authorization response message includes the ciphertext of the first key factor. In one example, the first key factor can be a random number, and the ciphertext of the first key factor is the ciphertext generated after encrypting the first key factor. The random number can be a pre-generated random number (such as a quantum random number) or a random salt value, etc., and is not limited here.

[0147] After verifying the single-packet authorization request message, the zero-trust gateway implemented in this application opens a specific service port to the client, enabling the client to negotiate and determine the session key with the zero-trust gateway through the specific service port.

[0148] In step S103, the client receives a single-packet authorization response message returned by the zero-trust gateway in response to the single-packet authorization request message; and decrypts the first key factor ciphertext using the first private key to obtain the first key factor.

[0149] For example, the first key factor can be the first random number R1.

[0150] In step S104, the client generates a second key factor and first identity authentication information, encrypts the second key factor to obtain second key factor ciphertext, and sends the first identity authentication information and second key factor ciphertext to the zero trust gateway.

[0151] For example, the first identity authentication information can be a first signature generated by the client, and the second key factor can be a second random number R2.

[0152] In step S105, the zero-trust gateway verifies the first identity authentication information, and after successful verification, it uses the second private key to decrypt the second key factor ciphertext to obtain the second key factor, and uses a preset algorithm to generate the session key based on the first key factor and the second key factor.

[0153] For example, the ZeroMessaging Gateway uses a preset algorithm to calculate the session key using a first random number R1 and a second random number R2.

[0154] In step S106, the zero-trust gateway generates second identity authentication information and sends the second identity authentication information to the client.

[0155] For example, the second identity authentication information could be a second signature generated by a zero-trust gateway.

[0156] In step S107, the client receives the second identity authentication information returned by the zero-trust gateway; verifies the second identity authentication information, and if the verification is successful, generates a session key based on the first key factor and the second key factor using a preset algorithm.

[0157] For example, after the client authenticates the second signature and passes the authentication, it can use a preset algorithm to calculate the session key using a first random number R1 and a second random number R2. In this way, both the client and the zero-trust gateway obtain a common session key.

[0158] In step S108, the client and the zero-trust gateway establish a connection channel to transmit data packets with the zero-trust gateway using the connection channel.

[0159] In this embodiment, when the client and the zero-trust gateway establish a connection channel, the client opens a specific service port to the zero-trust gateway, enabling the client to transmit data packets with the zero-trust gateway through the specific service port.

[0160] In this embodiment, the zero-trust gateway uses service hiding technologies (such as Single Packet Authorization (SPA) and Software Defined Perimeter (SDP)) to make internal resources (servers, applications, and data) invisible to unauthorized users, preventing them from being scanned or probed by attackers. An encrypted channel is only temporarily established after the visitor has been authenticated, selectively exposing the necessary resources to reduce the attack surface. The zero-trust gateway employs encryption and tunneling technologies; all access traffic is transmitted via encryption protocols such as TLS / DTLS to prevent data theft or tampering during transmission. The zero-trust gateway also supports identity-based encrypted tunnels, ensuring that only authorized entities can decrypt and access resources; even if the tunnel is intercepted, attackers cannot obtain valid information.

[0161] Zero Trust Gateway breaks the traditional network boundary thinking of "trustworthy internally and untrustworthy externally". It requires clients to re-authenticate every time they access the network, even within the internal network. Moreover, when accessing resources, it grants only the necessary permissions to complete the task based on the "principle of least privilege", avoiding over-authorization. It can also monitor the risk status of clients in real time (such as whether the client is infected or whether the location is abnormal) and dynamically adjust access permissions.

[0162] like Figure 2 The diagram shown is a signaling diagram of a zero-trust gateway data access method according to another embodiment of this application. The zero-trust gateway data access method 200 according to an embodiment of this application may include the following steps: S201, S202, S203, S204, S205, S206, S207, S208, and S209.

[0163] In step S201, the client sends a single-packet authorization request message to the zero-trust gateway;

[0164] In step S202, the zero-trust gateway verifies the single-packet authorization request message and, after successful verification, opens a specific service port to the client.

[0165] In step S203, the zero-trust gateway sends a single-packet authorization response message to the client, the single-packet authorization response message containing the first random number ciphertext;

[0166] In step S204, the client receives the first key factor ciphertext and decrypts it using the first private key to obtain the first random number R1.

[0167] In step S205, the client generates a second random number R2, encrypts the second random number R2 to obtain the second random number ciphertext, and uses the private key to generate a first signature for the first random number R1 and the second random number R2.

[0168] In step S206, the client sends the first signature and the second random number ciphertext to the zero-trust gateway.

[0169] In step S207, the zero-trust gateway uses the second private key to decrypt the second random number ciphertext to obtain the second random number R2, and verifies the first signature; after the verification is successful, it uses the second private key to generate a second signature for the first random number R1 and the second random number R2.

[0170] In step S208, the zero-trust gateway sends the second signature to the client.

[0171] In step S209, after verifying the second signature, the client uses the KDF algorithm to calculate the session key from the first random number R1 and the second random number R2.

[0172] In step S210, the client and the zero-trust gateway establish a connection channel to transmit data packets with the zero-trust gateway using the connection channel.

[0173] Steps S201 to S210 involve the client and the zero-trust network architecture communicating simultaneously using digital signatures based on identity cryptography and session key exchange protocols. This enables authentication of the two communicating parties in a secure tunnel and negotiation of session keys, reducing the number of handshake interactions during tunnel establishment and dependence on third parties, thereby improving tunnel performance.

[0174] Figure 3(a) illustrates a schematic diagram of the header of a data packet according to an embodiment of this application. As can be seen from the figure, the protocol header includes at least a message type. Data packets with different message types have different protocol bodies. The message type may include a data transmission type and a key update type.

[0175] Figure 3(b) shows a schematic diagram of the protocol body of a data transmission type data packet according to an embodiment of this application. When the message type is a data transmission type, the protocol body includes at least data content, a checksum, and first padding data; wherein the data content and the first padding data are both variable-length data.

[0176] Figure 3(c) shows a schematic diagram of the protocol body of a key update type data message according to an embodiment of this application. When the message type is a key update type, the protocol body includes at least a new gateway key, a new session key, a timestamp, a checksum, and second padding data; wherein the second padding data is variable-length data.

[0177] In one embodiment of this application, when the client transmits data packets with the zero-trust gateway using the connection channel, the protocol header is encrypted by the gateway key; the protocol body is encrypted by the session key. The gateway key is generated by the zero-trust gateway and reported to the key management center, which then sends it to the client.

[0178] This application employs a digital signature and key exchange protocol based on identifier cryptography to authenticate the authenticity of both communicating parties in a secure tunnel and negotiate keys. This reduces the number of handshake interactions and third-party dependencies during tunnel establishment, thereby improving tunnel performance. Simultaneously, the packet encapsulation design is improved to increase the difficulty of data packet analysis by hackers, thus enhancing the security of the tunnel protocol.

[0179] Furthermore, in this embodiment, to prevent data packet length leakage, which could allow attackers to guess the data packet type based on statistical patterns in data packet length and launch targeted attacks, the protocol specifies random padding of data packets to ensure variable data packet length. When padding data packets, a preset packet padding algorithm is used.

[0180] Typically, a data packet is encapsulated by at least one zero-trust single-packet authorization data packet. When filling the packet, it needs to be padded according to the length of the single zero-trust single-packet authorization data packet. As shown in Figure 4, a schematic flowchart of the data packet filling process 400 based on a preset packet filling algorithm according to an embodiment of this application is illustrated. The data packet filling process 400 based on a preset packet filling algorithm according to an embodiment of this application includes steps S401, S402, and S403:

[0181] In step S401, calculate the minimum and maximum length of the ciphertext of a single zero-trust single-packet authorized data packet;

[0182] In step S402, according to the minimum length and the maximum length, use the Rand function to calculate the length of the padding code;

[0183] In step S403, according to the length of the padding code, use a preset padding algorithm to generate padding data, and add the padding data to any one of the zero-trust single-pack authorization data packets; wherein, the padding data includes a random number generated according to the length of the padding code.

[0184] For example, first calculate the minimum length CLen of the ciphertext of a single zero-trust single-pack authorization data packet min , and the calculation formula is as follows:

[0185] CLen min = PLen + VAddLen,

[0186] where Plen represents the length of the plaintext data, and VAddLen represents the length of the check code.

[0187] It should be noted that in the counter mode (Counter Mode, CTR), there is no need to pad the data packet, and at this time, the length of the ciphertext is the same as the length of the plaintext data.

[0188] Then calculate the maximum length CLen of the ciphertext of a single zero-trust single-pack authorization data packet max , and the calculation formula is as follows:

[0189] If CLen max < MTU / 2, random padding is required, and at this time CLen max = MTU / 2;

[0190] If MTU / 2 ≤ CLenmin < MTU, then CLen max = CLen min .

[0191] Then, use the Rand function to calculate the length of the padding code PadLen, and the calculation formula is as follows:

[0192] PadLen = Rand(CLen min , CLen max ) – CLen min ,

[0193] where Rand represents a function that takes a random value in the interval; CLen min represents the minimum length of the ciphertext of a single zero-trust single-pack authorization data packet; CLen max represents the maximum length of the ciphertext of a single zero-trust single-pack authorization data packet.

[0194] The Rand function is calculated as follows: Rand(CLenmin,CLenmax) = rand() % (CLenmax -CLenmin) + CLenmin, which means the padding code PadLen = rand() % (CLenmax - CLenmin).

[0195] Finally, a random number generated based on the length of the padding code PadLen is used as the padding data.

[0196] It is worth noting that, since the protocol body also includes payload data and data integrity and authenticity verification codes, padding the data packet is actually padding the payload data.

[0197] The length of the padded datagram must not exceed the Maximum Transmission Unit (MTU). If the padded datagram exceeds the MTU, the datagram will be split into multiple IP packets during data transmission, leading to reduced transmission performance. For example, a single zero-trust single-packet authorized datagram is 1500 bytes long. The protocol message also includes a 20-byte Internet Protocol (IP) header and an 8-byte User Datagram Protocol (UDP) header. Therefore, the maximum length of the payload data is 1472 bytes. The total length of the entire protocol message must be less than this to ensure that the message is not split into multiple packets after security processing. Since the security protocol message header is 16 bytes and the protocol body contains an 8-byte data integrity and authenticity checksum, 24 bytes of additional security protocol data must be subtracted from the original payload data to obtain the effective payload data. Therefore, the MTU length is 1448 bytes.

[0198] In addition, the message header also includes a sender identifier (client identifier or zero-trust gateway identifier) ​​and a receiver identifier (zero-trust gateway identifier or client identifier). For example, the key management center distributes a first private key and a second private key to the client and the zero-trust gateway, respectively, based on the client identifier and the zero-trust gateway identifier.

[0199] Additionally, the message header includes a counter; the counter includes a message sequence number; the message sequence number is randomly generated based on the number of times the data packet has been sent, and the message sequence number is used by the zero-trust gateway to detect network attacks. For example, the zero-trust gateway uses the message sequence number to determine the number of times it has been attacked, thereby determining whether it is a malicious network attack.

[0200] The embodiments of this application improve the encapsulation design of data packets, increasing the difficulty of analyzing data packets and thus enhancing the security of the tunnel protocol.

[0201] In this embodiment, key management is also required, including the management of gateway keys and session keys. The gateway key is randomly generated by the zero-trust gateway during registration or periodic updates and reported to the key management center. After successful client authentication, the key management center distributes the key to the client via a secure protocol message. The user session key is obtained through a handshake process negotiated when the client connects to the zero-trust gateway.

[0202] like Figure 5 The diagram shows a schematic flowchart of a key management process 500 according to an embodiment of this application. The key management process 500 according to an embodiment of this application includes steps S501 and S502:

[0203] In step S501, if the preset triggering conditions are met, the session key and gateway key are updated according to the preset strategy to obtain a new session key and a new gateway key.

[0204] In step S502, the new session key and the new gateway key are sent to the client to enable communication with the client based on the new session key and the new gateway key.

[0205] In one example, such as Figure 6 The diagram illustrates a schematic flowchart of step S501 of this application, which involves triggering the update of the session key according to a preset strategy. Step S501, which involves triggering the update of the session key according to a preset strategy, includes steps S601, S602, and S603:

[0206] In step S601, if the preset triggering conditions are met, a first new key factor is generated;

[0207] In step S602, a key update message is sent to the client, and a new key factor for the session connection is recorded synchronously; wherein, the client decrypts the key update message to obtain a new key factor, generates a second new key factor, and sends the second new key factor to the zero-trust gateway; the client uses the preset algorithm to generate the new session key based on the first new key factor and the second new key factor;

[0208] In step S603, the second new key factor ciphertext sent by the client is received, the second new key factor is decrypted to obtain the second new key factor, and the new session key is generated based on the first new key factor and the second new key factor using the preset algorithm.

[0209] Generally, session key updates are initiated by the zero-trust gateway and triggered according to its preset update policy. It's important to note that session key updates are a continuous process based on the update policy, typically triggered only when preset update conditions are met. Therefore, the session key update mechanism differs from the gateway key update mechanism; the session key uses a distributed update mechanism. Because session key updates are continuous, situations may arise where the new session key and the old session key coexist during the update process. Generally, if a data packet encrypted with the old session key is received, it is decrypted using the old session key; if a data packet encrypted with the new session key is received, it is decrypted using the new session key. However, neither the client nor the zero-trust gateway can know in advance whether a data packet was encrypted with the old or new session key upon receiving it. They can only choose one session key for decryption; if decryption fails, they must choose the other session key.

[0210] In one example, such as Figure 7 As shown, the method further includes step S701:

[0211] In step S701, the receiver decrypts the received data packet using the new session key;

[0212] In step S702, if the data packet cannot be decrypted, the original session key is used to decrypt the data packet.

[0213] For example, during the process of updating the session key according to the preset strategy, the original session key and the new session key coexist for 2 minutes.

[0214] In this embodiment, the session key update is achieved by a zero-trust gateway generating a random number as the update key factor, which is sent to the corresponding client via a key update message. The gateway also synchronously records the update key factor for this session connection. It's important to note that the zero-trust gateway only synchronously records the new key factor; it doesn't replace the original session key because it may receive messages encrypted with the original key from the client during the update process. Upon receiving the key update message, the client decrypts it to obtain the key update factor and uses a similar gateway key derivation algorithm to obtain the new session key. The client then uses the new session key to decrypt newly received messages. If this fails, it attempts to decrypt using the original session key. The coexistence time of the two keys can be set to 2 minutes to address the issue of delayed UDP packet arrival.

[0215] In one example, the zero-trust gateway updates the gateway key according to a preset update policy, sends the new gateway key to the key management center, and the key management center then sends the new gateway key to the client.

[0216] Updating the gateway key involves a large number of client users, and the update process requires time. Therefore, during the gateway key update process, the gateway needs to maintain both the old and new keys simultaneously. After the update starts, the new gateway key is used first to decrypt the message header. If decryption fails, the old gateway key is then attempted. The gateway key update is performed by sending a random number generated by the gateway to each connected client via a key update message. After receiving the update message, the client decrypts it to obtain the corresponding random number, and then derives a new gateway key from this random number and the original gateway key. The derivation algorithm uses the HMAC cryptographic algorithm, using the original gateway key as data and the received random number key as the key to calculate the HMAC value.

[0217] In this application embodiment, a preset update strategy is used, such as a timed key update for a secure tunnel or a key update triggered according to preset update conditions to enhance protocol security. Key update typically refers to a key update mechanism for ongoing communication connections, initiated proactively by the gateway and processed through the protocol body structure in the update key message type of the protocol message. The gateway key and session key can be updated simultaneously or separately. The gateway key is used for encryption and decryption of the protocol header; gateway keys for the same gateway are identical. The session key, however, is negotiated between the gateway and the client; in the case of multiple clients, each client's user session key is unique.

[0218] In addition to key management, the zero-trust gateway in this embodiment also needs to perform network attack detection. For example... Figure 8 The diagram illustrates a schematic flowchart of a network attack detection process performed by a zero-trust gateway according to an embodiment of this application. The network attack detection process 800 performed by the zero-trust gateway according to an embodiment of this application may include steps S801, S802, and S803:

[0219] In step S801, a zero-trust SPA data packet sent from the same source address is received;

[0220] In step S802, if the number of decryption failures of the zero-trust SPA data packet is greater than or equal to a preset number, the source address is reported to the security center for early warning.

[0221] In step S803, the source address is cleared according to a preset security policy.

[0222] In this embodiment, the existence of a network attack can be determined based on the decryption status of data packets. For example, if the number of consecutive decryption errors for data packets sent from the same source address reaches a certain value, a network attack risk can be identified. In the event of a network attack risk, the zero-trust gateway should remove the client corresponding to this source address according to a preset security policy and report the risk to the management center for early warning. For example, the source address can be set as the default to refuse reception.

[0223] like Figure 9 The diagram illustrates a schematic flowchart of a source address clearing process using a preset security policy according to an embodiment of this application. The process of clearing a source address using a preset security policy according to an embodiment of this application may include steps S901 and S902:

[0224] In step S901, when decryption fails, the number of decryption failures of the data packet corresponding to the source address is recorded;

[0225] In step S902, if decryption is successful before the number of failed attempts reaches the preset number, the decryption failure record corresponding to the source address is cleared.

[0226] Since network attack detection can be performed either outside of key updates or during key updates, a hashtable can be constructed as an attack detection record table, using the client's physical IP address and port number as the key and the number of decryption failures as the value.

[0227] Typically, most of the time is spent in the non-key update period. When the zero-trust gateway receives data packets from clients, if the protocol header of the data packet fails to be decrypted using the gateway key, it extracts the source address (IP address) and port number from the data packet as keys and inserts them into the detection record table, setting the decryption failure count to 1. If this key already exists in the record table, the count is incremented by 1. For successful decryption of the protocol header but failed decryption of the protocol body, the same method is used to increment the count in the record table. When the number of failures reaches a set threshold (e.g., 10 times), it can be determined that there is a risk of attack. The zero-trust gateway will clear this source address according to the preset security policy, refuse the connection, and report to the control center for early warning, providing data support for the control center's security posture.

[0228] Under normal circumstances, both the protocol header and body should decrypt successfully. Consecutive decryption failures indicate that the client does not know the gateway key or session key, suggesting the data packet may be spoofed or the source data packet may have been illegally tampered with. In this embodiment, since some data packets may be due to transmission errors during network transmission, to reduce misjudgments of such data packets, a threshold can be set for the number of decryption failures. If decryption succeeds before reaching the threshold, the corresponding key is deleted from the attack detection record table.

[0229] Here, packet decryption failure includes failure to decrypt the protocol header and / or protocol body of the data packet. During key non-update periods, since there is only one gateway key, after decrypting the protocol header using that gateway key, the message type in the header will show as a data transmission type, indicating that the protocol body should have a unique session key. If the protocol body decryption fails, it can be considered a potential attack risk. During key update periods, only two gateway keys exist, old and new; therefore, the session key can be uniquely determined based on the gateway key. During key update periods, decrypting the protocol header requires attempts using both the old and new gateway keys. After a maximum of two decryption attempts, if the message type of the decrypted protocol header shows as a key update type, then there may be a maximum of two session keys. If decryption of the protocol header using both the old and new gateway keys fails, it can be considered a potential attack risk.

[0230] In a zero-trust security architecture, the zero-trust gateway is the core component for implementing resource access control and security protection. Based on the zero-trust principle of "never trust, always verify," it performs strict identity authentication, permission verification, and dynamic risk assessment on all access requests (whether from the internal or external network) to ensure that only fully verified entities can securely access specific resources.

[0231] The zero-trust gateway data access method of this application has the following beneficial effects;

[0232] (1) The secure tunnel established by the technical solution of this application combines the security concept of "authentication before opening" of zero trust. The data port of the zero trust gateway is in an open state before authentication. Even if there is a network attack, the data port of the zero trust gateway cannot be detected, so the security is high.

[0233] (2) The technical solution of this application embodiment has a private design for the data packet structure. Compared with the SSL / TLS and IPSec protocol packets in traditional technologies, it has fewer vulnerabilities and a lower risk of attack.

[0234] (3) The security tunnel protocol of this application implements the zero-trust "default rejection" principle. Before the SPA message passes the verification, a silent mechanism is adopted, so the attacker cannot perceive the existence of the zero-trust gateway, thus realizing the network stealth capability.

[0235] (4) The secure tunnel protocol of this application embodiment is based on identity cryptography, which does not require a certificate, and therefore does not require the steps of certificate verification and certificate transmission, reducing the amount of computation and data transmission, and also reducing the number of handshake interactions required for connection, thus greatly improving the overall performance of the network system.

[0236] The following is combined Figure 10 The client 1000 of this application is described, wherein, Figure 10 A schematic block diagram of a client 1000 according to an embodiment of this application is shown. The client 1000 includes:

[0237] The first sending module 1001 is used to send a single packet authorization request message to the zero trust gateway;

[0238] The first receiving module 1002 is used to receive a single-packet authorization response message returned by the zero-trust gateway in response to the single-packet authorization request message; wherein, the single-packet authorization response message is generated by the zero-trust gateway after verifying and passing the single-packet authorization request message, and the single-packet authorization response message includes a first key factor ciphertext;

[0239] The first decryption module 1003 is used to decrypt the first key factor ciphertext using the first private key to obtain the first key factor;

[0240] The first sending module 1001 is further configured to generate a second key factor and first identity authentication information, encrypt the second key factor to obtain second key factor ciphertext, send the first identity authentication information and second key factor ciphertext to the zero trust gateway, so that the zero trust gateway can decrypt the second key factor ciphertext to obtain the second key factor, and generate the session key based on the first key factor and the second key factor using the preset algorithm.

[0241] The first receiving module 1002 is also used to receive the second identity authentication information returned by the zero trust gateway;

[0242] The first verification module 1004 is used to verify the second identity authentication information. If the verification is successful, a session key is generated based on the first key factor and the second key factor using a preset algorithm.

[0243] The first connection module 1005 is used to establish a connection channel with the zero-trust gateway based on the session key, so as to use the connection channel to transmit data packets with the zero-trust gateway.

[0244] In addition, the client may include: one or more memories (not shown in the figure) and one or more processors (not shown in the figure), wherein the memories store a computer program that is executed by the processor, and the computer program, when executed by the processor, causes the processor to perform the zero-trust gateway data access method described above.

[0245] The client can be part or all of a computer device that can implement the zero-trust gateway data access method through software, hardware, or a combination of software and hardware.

[0246] The client includes one or more memories, one or more processors, a display (not shown), and a communication interface, etc., which are interconnected via a bus system and / or other forms of connection mechanisms (not shown). It should be noted that the components and structure of the client are exemplary and not limiting; the client may have other components and structures as needed.

[0247] The memory is used to store various data and executable program instructions generated during the operation of related methods, such as storing various application programs or algorithms that implement various specific functions. It may include one or more computer program products, which can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc.

[0248] The processor can be a central processing unit (CPU), a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other processing units with data processing and / or instruction execution capabilities, and can be other components in the client to perform the desired functions.

[0249] In one example, the client also includes an output device that can output various information (such as images or sounds) to the outside (e.g., a user), and may include one or more of a display device, a speaker, etc.

[0250] The communication interface can be any known communication protocol interface, such as a wired interface or a wireless interface. The communication interface may include one or more serial ports, USB interfaces, Ethernet ports, WiFi, wired networks, DVI interfaces, device integrated interconnect modules, or other suitable ports, interfaces, or connections.

[0251] The following is combined Figure 11The zero-trust gateway 1100 of this application is described, wherein, Figure 11 A schematic block diagram of a zero-trust gateway 1100 according to an embodiment of this application is shown. The zero-trust gateway 1100 includes:

[0252] The second receiving module 1101 is used to receive a single-packet authorization request message sent by the client;

[0253] The second verification module 1102 is used to verify the single-packet authorization request message and generate a single-packet authorization response message after the verification is successful; wherein, the single-packet authorization response message includes the first key factor ciphertext;

[0254] The second sending module 1103 is used to send the single-packet authorization response message to the client, so that the client can use the first private key to decrypt the first key factor ciphertext and obtain the first key factor;

[0255] The second receiving module 1101 is further configured to receive the first identity authentication information and the second key factor ciphertext sent by the client;

[0256] The second decryption module 1104 is also used to verify the first identity authentication information, and after the verification is passed, to decrypt the second key factor ciphertext using the second private key to obtain the second key factor, and to generate the session key based on the first key factor and the second key factor using a preset algorithm.

[0257] The second sending module 1103 is used to generate second identity authentication information and send the second identity authentication information to the client, so that the client can generate the session key according to the first key factor and the second key factor using the preset algorithm when the authentication is passed;

[0258] The second connection module 1105 is used to establish a connection channel with the client based on the session key, so as to use the connection channel to transmit data packets with the client.

[0259] The following is combined Figure 12 The zero-trust gateway data access system of this application is described, wherein, Figure 12 A schematic block diagram of a zero-trust gateway data access system 1200 according to an embodiment of this application is shown. The zero-trust gateway data access system according to this application includes: at least one client 1201 and a zero-trust gateway 1202; wherein,

[0260] Any one of the at least one client 1201 is used for:

[0261] Send a single-packet authorization request message to the zero-trust gateway 1202;

[0262] The zero-trust gateway 1202 receives a single-packet authorization response message in response to the single-packet authorization request message; wherein the single-packet authorization response message is generated by the zero-trust gateway 1202 after verifying and passing the single-packet authorization request message, and the single-packet authorization response message includes a first key factor ciphertext;

[0263] The first key factor is obtained by decrypting the ciphertext of the first key factor using the first private key.

[0264] A second key factor and first identity authentication information are generated. The second key factor is encrypted to obtain the second key factor ciphertext. The first identity authentication information and the second key factor ciphertext are sent to the zero trust gateway 1202 so that the zero trust gateway 1202 can decrypt the second key factor ciphertext to obtain the second key factor. The session key is generated based on the first key factor and the second key factor using the preset algorithm.

[0265] Receive the second identity authentication information returned by the zero-trust gateway 1202;

[0266] Verify the second identity authentication information, and if the verification is successful, generate a session key based on the first key factor and the second key factor using a preset algorithm;

[0267] A connection channel is established with the zero-trust gateway 1202 based on the session key, so as to transmit data packets with the zero-trust gateway 1202 using the connection channel;

[0268] The zero-trust gateway 1202 is used for:

[0269] Receive a single-packet authorization request message sent by client 1201;

[0270] The single-packet authorization request message is verified, and a single-packet authorization response message is generated after successful verification; wherein, the single-packet authorization response message includes the ciphertext of the first key factor;

[0271] The single-packet authorization response message is sent to the client 1201, so that the client 1201 can use the first private key to decrypt the first key factor ciphertext and obtain the first key factor;

[0272] Receive the first authentication information and the second key factor ciphertext sent by the client 1201;

[0273] The first identity authentication information is verified, and after the verification is successful, the second key factor is obtained by decrypting the ciphertext of the second key factor using the second private key. The session key is then generated based on the first key factor and the second key factor using a preset algorithm.

[0274] A second identity authentication information is generated and sent to the client 1201, so that the client 1201 can generate the session key based on the first key factor and the second key factor using the preset algorithm if the authentication is successful;

[0275] A connection channel is established with the client 1201 based on the session key, so as to transmit data packets with the client 1201 using the connection channel.

[0276] Furthermore, according to embodiments of this application, a storage medium is also provided, on which program instructions are stored. When executed by a computer or processor, these program instructions are used to perform corresponding steps of the zero-trust gateway data access method of this application. The storage medium may, for example, include a memory card of a smartphone, a storage component of a tablet computer, a hard disk of a personal computer, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a portable compact disc read-only memory (CD-ROM), a USB memory, or any combination of the above storage media.

[0277] Furthermore, according to embodiments of this application, a computer program product is also provided, which, when executed by a processor, implements the steps of the zero-trust gateway data access method as described above.

[0278] The client, zero-trust gateway, zero-trust gateway data access system, computer program product, and storage medium of this application embodiment have the same advantages as the aforementioned zero-trust gateway data access method because they can implement the aforementioned zero-trust gateway data access method.

[0279] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of this application. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of this application. All such changes and modifications are intended to be included within the scope of this application as claimed in the appended claims.

[0280] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0281] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0282] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0283] Similarly, it should be understood that, in order to streamline this application and aid in understanding one or more of the various inventive aspects, features of this application may sometimes be grouped together in a single embodiment, figure, or description thereof in the description of exemplary embodiments of this application. However, this approach should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the corresponding claims, its inventive point lies in solving the corresponding technical problem with features fewer than all features of a single disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0284] Those skilled in the art will understand that, apart from the mutual exclusion of features, all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or elements of any method or apparatus so disclosed may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0285] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the claims, any one of the claimed embodiments can be used in any combination.

[0286] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules according to the embodiments of this application. This application can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0287] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0288] The above description is merely a specific embodiment or illustration of the embodiments of this application. The scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. The scope of protection of this application shall be determined by the scope of the claims.

[0289] The technical solution of the present invention has been described above in conjunction with the embodiments. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of the present disclosure without departing from the technical concept of the present disclosure are also within the protection scope of the embodiments of the present disclosure.

Claims

1. A zero-trust gateway data access method, characterized in that, Applied to the client, the method includes: Sending a single-packet authorization request message to the zero-trust gateway; Receiving a single-packet authorization response message returned by the zero-trust gateway for the single-packet authorization request message; wherein, the single-packet authorization response message is generated by the zero-trust gateway after verifying the single-packet authorization request message and passing the verification, and the single-packet authorization response message includes a first key factor ciphertext; Decrypting the first key factor ciphertext with the first private key to obtain the first key factor; Generating a second key factor and first authentication information, encrypting the second key factor to obtain a second key factor ciphertext, and sending the first authentication information and the second key factor ciphertext to the zero-trust gateway, so that the zero-trust gateway decrypts the second key factor ciphertext to obtain the second key factor, and generates a session key based on the first key factor and the second key factor using a preset algorithm; Receiving the second authentication information returned by the zero-trust gateway; Verifying the second authentication information, and in the case of passing the verification, generating a session key based on the first key factor and the second key factor using a preset algorithm; Establishing a connection channel with the zero-trust gateway based on the session key to transmit data messages with the zero-trust gateway using the connection channel; Wherein, the data message includes a protocol header and a protocol body; the protocol header at least includes a message type; wherein, when the message type is a data transmission type, the protocol body at least includes data content, a check code, and first padding data; wherein, both the data content and the first padding data are variable-length data; when the message type is a key update type, the protocol body at least includes a gateway new key, a client new key, a timestamp, a check code, and second padding data; wherein, the second padding data is variable-length data; Wherein, when the client transmits a data message with the zero-trust gateway using the connection channel, the protocol header is encrypted with the gateway key; the protocol body is encrypted with the session key; wherein, the gateway key is generated by the zero-trust gateway and reported to the key management center, and the key management center sends it to the client; Wherein, the method further includes: filling the data message based on a preset message filling algorithm; Wherein, the data message is encapsulated by at least one zero-trust single-packet authorization data packet; filling the data message based on a preset message filling algorithm includes: calculating the minimum length and maximum length of the ciphertext of a single zero-trust single-packet authorization data packet; calculating the filling code length using the Rand function according to the minimum length and the maximum length; generating filling data using a preset filling algorithm according to the filling code length, and adding the filling data to any zero-trust single-packet authorization data packet; wherein, the filling data includes a random number generated according to the filling code length.

2. The method according to claim 1, wherein The protocol body further includes payload data and a data integrity and authenticity check code; wherein, filling the data message based on a preset message filling algorithm includes: Pad the payload data.

3. The method according to claim 1, wherein Among them, the length of the data packet after padding does not exceed the maximum transmission unit length.

4. The method according to claim 1, wherein the message header further includes a client identifier and a zero-trust gateway identifier; wherein, the key management center distributes a first private key and a second private key to the client and the zero-trust gateway respectively according to the client identifier and the zero-trust gateway identifier; the message header further includes a counter; the counter includes a message sequence number; the message sequence number is randomly generated based on the number of times the data packet is sent, and the message sequence number is used for the zero-trust gateway to detect network attacks.

5. A zero-trust gateway data access method, characterized in that, Applied to a zero-trust gateway, the method includes: Receiving a single-packet authorization request message sent by a client; Verifying the single-packet authorization request message, and after successful verification, generating a single-packet authorization response message; wherein, the single-packet authorization response message includes a first key factor ciphertext; Sending the single-packet authorization response message to the client, so that the client decrypts the first key factor ciphertext using the first private key to obtain a first key factor; Receiving the first authentication information and the second key factor ciphertext sent by the client; Verifying the first authentication information, and after successful verification, decrypting the second key factor ciphertext using the second private key to obtain a second key factor, and generating a session key based on the first key factor and the second key factor using a preset algorithm; Generating second authentication information, and sending the second authentication information to the client, so that the client, in the case of successful verification, generates the session key according to the first key factor and the second key factor using the preset algorithm; Establishing a connection channel with the client based on the session key to transmit data packets with the client using the connection channel; wherein, the data packet includes a protocol header and a protocol body; the protocol header at least includes a message type; wherein, when the message type is a data transmission type, the protocol body at least includes data content, a check code, and first padding data; wherein, both the data content and the first padding data are variable-length data; when the message type is a key update type, the protocol body at least includes a gateway new key, a client new key, a timestamp, a check code, and second padding data; wherein, the second padding data are all variable-length data; wherein, the method further includes: padding the data packet based on a preset packet padding algorithm; Among them, the data packet is encapsulated by at least one zero-trust single-packet authorization data packet; filling the data packet based on a preset packet filling algorithm includes: calculating the minimum length and the maximum length of the ciphertext of a single zero-trust single-packet authorization data packet; calculating the filling code length by using the Rand function according to the minimum length and the maximum length; generating filling data by using a preset filling algorithm according to the filling code length, and adding the filling data to any one zero-trust single-packet authorization data packet; wherein, the filling data includes a random number generated according to the filling code length.

6. The method according to claim 5, wherein The protocol body further includes payload data and a data integrity and authenticity verification code; wherein, filling the data packet based on a preset packet filling algorithm includes: Filling the payload data.

7. The method according to claim 5, wherein Among them, The length of the filled data packet does not exceed the maximum transmission unit length.

8. The method according to claim 5, wherein The method further includes: When the client transmits a data packet with the zero-trust gateway through the connection channel, the protocol header is encrypted by the gateway key; the protocol body is encrypted by the session key; Among them, the gateway key is generated by the zero-trust gateway and reported to the key management center, and the key management center sends it to the client.

9. The method according to claim 5, wherein The method further includes: When a preset trigger condition is met, updating the session key and the gateway key according to a preset policy to obtain a new session key and a new gateway key; Sending the new session key and the new gateway key to the client so as to communicate with the client based on the new session key and the new gateway key.

10. The method according to claim 9, wherein Triggering the update of the session key according to a preset policy includes: Generating a first new key factor when a preset trigger condition is met; Sending it to the client through a key update message packet and synchronously recording the new key factor of the session connection; wherein, the client decrypts the key update packet to obtain the new key factor, generates a second new key factor, and sends the second new key factor to the zero-trust gateway; the client uses the preset algorithm to generate the new session key according to the first new key factor and the second new key factor; Receiving the ciphertext of the second new key factor sent by the client, decrypting the ciphertext of the second new key factor to obtain the second new key factor, and using the preset algorithm to generate the new session key according to the first new key factor and the second new key factor.

11. The method according to claim 10, wherein Among them, In the process of triggering the update of the session key according to a preset policy, the coexistence time of the original session key and the new session key is a preset time; the method further includes: If a data packet encrypted by the original session key is received, decrypt the data packet with the original session key; if a data packet encrypted by the new session key is received, decrypt the data packet with the new session key.

12. The method according to claim 9, wherein The method further includes: Updating the gateway key according to a preset update policy, sending the new gateway key to the key management center, and the key management center sending the new gateway key to the client.

13. The method according to claim 5, characterized in that, The method further includes: Receive zero-trust SPA data packets sent from the same source address; If the number of failed decryption attempts for the zero-trust SPA data packet is greater than or equal to a preset number, the source address will be reported to the security center for early warning. The source address is cleared according to the preset security policy.

14. The method according to claim 13, wherein The method further includes: When decryption fails, record the number of decryption failures for the data packet corresponding to the source address; If decryption is successful before the preset number of failed decryption attempts is reached, the decryption failure record corresponding to the source address is cleared.

15. The method according to claim 14, wherein The method further includes: Decryption failure includes failure to decrypt the protocol header and / or protocol body of the data packet.

16. The method according to claim 15, characterized in that, The message header also includes a counter; the counter includes a message sequence number; the message sequence number is randomly generated based on the number of times the data message is sent, and the message sequence number is used by the zero-trust gateway to detect whether a network attack exists.

17. A client, characterized in that, The client includes: The first sending module is used to send a single-packet authorization request message to the zero-trust gateway; The first receiving module is configured to receive a single-packet authorization response message returned by the zero-trust gateway in response to the single-packet authorization request message; wherein the single-packet authorization response message is generated by the zero-trust gateway after verifying and passing the single-packet authorization request message, and the single-packet authorization response message includes a first key factor ciphertext; The first decryption module is used to decrypt the ciphertext of the first key factor using the first private key to obtain the first key factor; The first sending module is further configured to generate a second key factor and first identity authentication information, encrypt the second key factor to obtain second key factor ciphertext, send the first identity authentication information and second key factor ciphertext to the zero trust gateway, so that the zero trust gateway can decrypt the second key factor ciphertext to obtain the second key factor, and generate a session key based on the first key factor and the second key factor using a preset algorithm. The first receiving module is also used to receive the second identity authentication information returned by the zero-trust gateway; The first verification module is used to verify the second identity authentication information. If the verification is successful, a session key is generated based on the first key factor and the second key factor using a preset algorithm. A first connection module is configured to establish a connection channel with the zero-trust gateway based on the session key, and to transmit data packets with the zero-trust gateway using the connection channel; wherein the data packet includes a protocol header and a protocol body; the protocol header includes at least a message type; wherein, when the message type is a data transmission type, the protocol body includes at least data content, a checksum, and first padding data; wherein both the data content and the first padding data are variable-length data; wherein, when the message type is a key update type, the protocol body includes at least a new gateway key, a new client key, a timestamp, a checksum, and second padding data; wherein the second padding data is variable-length data. When the client transmits data packets with the zero-trust gateway using the connection channel, the protocol header is encrypted with the gateway key; the protocol body is encrypted with the session key; wherein the gateway key is generated by the zero-trust gateway and reported to the key management center, which then sends it to the client. The data packets are filled based on a preset message filling algorithm; The data packet is encapsulated by at least one zero-trust single-packet authorization data packet. The data packet is filled using a preset filling algorithm, including: calculating the minimum and maximum lengths of the ciphertext of a single zero-trust single-packet authorization data packet; calculating the filling code length using the Rand function based on the minimum and maximum lengths; generating filling data using the preset filling algorithm based on the filling code length; and adding the filling data to any zero-trust single-packet authorization data packet; wherein the filling data includes a random number generated based on the filling code length.

18. A zero-trust gateway, characterized in that, The zero-trust gateway includes: The second receiving module is used to receive single-packet authorization request messages sent by the client; The second verification module is used to verify the single-packet authorization request message and generate a single-packet authorization response message after the verification is successful; wherein, the single-packet authorization response message includes the first key factor ciphertext; The second sending module is used to send the single-packet authorization response message to the client, so that the client can use the first private key to decrypt the first key factor ciphertext and obtain the first key factor; The second receiving module is also used to receive the first identity authentication information and the second key factor ciphertext sent by the client; The second decryption module is also used to verify the first identity authentication information, and after the verification is successful, to decrypt the second key factor ciphertext using the second private key to obtain the second key factor, and to generate a session key based on the first key factor and the second key factor using a preset algorithm. The second sending module is used to generate second identity authentication information and send the second identity authentication information to the client, so that the client can generate the session key based on the first key factor and the second key factor using the preset algorithm when the authentication is successful; The second connection module is used to establish a connection channel with the client based on the session key, so as to use the connection channel to transmit data packets with the client; The data packet includes a protocol header and a protocol body; the protocol header includes at least a message type; wherein, when the message type is a data transmission type, the protocol body includes at least data content, a checksum, and first padding data; wherein both the data content and the first padding data are variable-length data; wherein, when the message type is a key update type, the protocol body includes at least a gateway new key, a client new key, a timestamp, a checksum, and second padding data; wherein the second padding data is variable-length data. The data packets are filled based on a preset message filling algorithm; The data packet is encapsulated by at least one zero-trust single-packet authorization data packet. The data packet is filled using a preset filling algorithm, including: calculating the minimum and maximum lengths of the ciphertext of a single zero-trust single-packet authorization data packet; calculating the filling code length using the Rand function based on the minimum and maximum lengths; generating filling data using the preset filling algorithm based on the filling code length; and adding the filling data to any zero-trust single-packet authorization data packet; wherein the filling data includes a random number generated based on the filling code length.

19. A zero-trust gateway data access system, characterized in that, include: At least one client and a zero-trust gateway; wherein the at least one client is used to perform the zero-trust gateway data access method according to any one of claims 1 to 4; The zero-trust gateway is used to execute the zero-trust gateway data access method according to any one of claims 5 to 16.

20. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, causes the processor to perform the zero-trust gateway data access method as described in any one of claims 1 to 16.

21. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 16.

Images