End-to-end encryption tunnel method and system under zero-trust security architecture

Abstract

The invention provides an end-to-end encryption tunnel method and system under a zero-trust security architecture, and relates to the technical field of network security, and the method comprises the steps: carrying out the unified management of identity credentials and access strategies of communication entities through a control plane, and verifying the identity when a first communication entity requests to access a second communication entity; after verification is passed, an authorization token is generated and sent to the first tunnel agent, and the first tunnel agent carries the token to initiate a connection request to the second tunnel agent; the second tunnel agent verifies the validity of the token by using the public key, and after the verification is passed, the two parties negotiate an encryption algorithm suite and execute key exchange to generate a session key; establishing an end-to-end encryption tunnel based on the session key to realize direct encrypted data transmission between two communication entities; and automatically destroying the session key and terminating the tunnel connection through effective duration control of the authorization token and a tunnel idle timeout mechanism. The method has the technical effect that the risk that sensitive resources are visited beyond authority or abused is reduced.

Description

Technical Field

[0001] This application relates to the field of network security technology, specifically to an end-to-end encrypted tunneling method, system, device, and medium under a zero-trust security architecture. Background Technology

[0002] With the rapid development of technologies such as cloud computing, mobile office, and the Internet of Things, the boundaries of enterprise internal networks are becoming increasingly blurred, posing a serious challenge to traditional network boundary-based security protection models. Users and devices need to access enterprise resources distributed in multiple locations from different network environments. How to achieve dynamic authorization management based on the access session lifecycle and prevent the abuse of security permissions and access control failures has become an urgent technical problem to be solved.

[0003] Currently, traditional solutions generally adopt a static authorization model of one-time authentication and long-term trust. After the system completes the initial authentication, a persistent trust relationship is established, allowing users or devices to access resources within the authorized scope for a relatively long period. While this approach provides basic identity authentication and access authorization functions, it cannot adapt to the dynamic changes in identity status and access requirements in modern network environments, thereby increasing the risk of unauthorized access or abuse of sensitive resources. Summary of the Invention

[0004] This application provides an end-to-end encrypted tunneling method, system, device, and medium under a zero-trust security architecture to reduce the risk of unauthorized access or abuse of sensitive resources.

[0005] Firstly, this application provides an end-to-end encrypted tunneling method under a zero-trust security architecture, applied to a control plane. The control plane receives identity credentials reported by a first communication entity and a second communication entity, completes registration, and stores and manages access policies. The method includes: In response to a request from the first communication entity to access the second communication entity, the identity credentials of the first communication entity are verified, and the access policy is used to determine whether the first communication entity allows access to the second communication entity. When the identity credentials of the first communication entity meet preset requirements and the first communication entity allows access to the second communication entity, an authorization token is generated and sent to the first tunnel agent of the first communication entity. This allows the first tunnel agent to initiate a connection request to the second tunnel agent of the second communication entity carrying the authorization token. The second tunnel agent verifies the authorization token using the public key of the control plane. When the verification is successful, the first tunnel agent and the second tunnel agent exchange their respective lists of supported encryption algorithms and negotiate to select an encryption algorithm suite. This allows the first tunnel agent and the second tunnel agent to perform key exchange based on the encryption algorithm suite and generate a session key. Based on the session key, an end-to-end encrypted tunnel is established between the first communication entity and the second communication entity, allowing the first communication entity and the second communication entity to directly transmit encrypted data through the end-to-end encrypted tunnel. When the authorization token reaches its validity period or the idle time of the end-to-end encrypted tunnel exceeds a preset threshold, the session key is destroyed and the end-to-end encrypted tunnel is terminated.

[0006] By adopting the above technical solution, centralized authentication and access control are achieved through unified management of identity credentials and access policies on the control plane, ensuring that only the first communication entity, after strict authentication and conforming to the access policy, can obtain access authorization. A cryptographically-based trusted authorization mechanism is established by generating time-sensitive authorization tokens, which are then verified by the second tunnel agent using the control plane's public key, effectively preventing unauthorized access and token forgery. The first and second tunnel agents negotiate encryption algorithm suites and perform key exchange to generate session keys, enabling flexible encryption strength selection and end-to-end key security management. The end-to-end encrypted tunnel established based on the session key allows the first and second communication entities to directly transmit encrypted data, avoiding the risk of data leakage at intermediate nodes. Through a dual control mechanism of authorization token validity period and end-to-end encrypted tunnel idle time, the system can promptly destroy session keys and terminate the encrypted tunnel, achieving dynamic management of access permissions and automatic control of session lifecycle, thereby reducing the risk of unauthorized access or abuse of sensitive resources.

[0007] Secondly, this application provides an end-to-end encrypted tunnel system under a zero-trust security architecture, the system comprising: a response module, a generation module, a verification module, a construction module, and a termination module; wherein, The response module is configured to respond to a request from a first communication entity to access a second communication entity, verify the identity credentials of the first communication entity, and determine whether the first communication entity allows access to the second communication entity according to an access policy; the generation module is configured to generate an authorization token when the identity credentials of the first communication entity meet preset requirements and the first communication entity allows access to the second communication entity, and send the authorization token to the first tunnel proxy of the first communication entity; so that the first tunnel proxy carries the authorization token to initiate a connection request to the second tunnel proxy of the second communication entity, and the second tunnel proxy verifies the authorization token according to the public key of the control plane; the verification module uses... When verification is successful, the first tunnel proxy and the second tunnel proxy exchange their respective lists of supported encryption algorithms and negotiate to select an encryption algorithm suite, so that the first tunnel proxy and the second tunnel proxy perform key exchange according to the encryption algorithm suite and generate a session key; the construction module is used to establish an end-to-end encrypted tunnel between the first communication entity and the second communication entity according to the session key, so that the first communication entity and the second communication entity can directly transmit encrypted data through the end-to-end encrypted tunnel; the termination module is used to destroy the session key and terminate the end-to-end encrypted tunnel when the authorization token reaches its validity period or the idle time of the end-to-end encrypted tunnel exceeds a preset threshold.

[0008] Thirdly, this application provides an electronic device that adopts the following technical solution: including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to enable the electronic device to execute a computer program of an end-to-end encrypted tunneling method under any of the above-described zero-trust security architectures.

[0009] Fourthly, this application provides a computer-readable storage medium that employs the following technical solution: storing a computer program capable of being loaded by a processor and executing any of the above-mentioned end-to-end encrypted tunneling methods under a zero-trust security architecture.

[0010] In summary, this application includes at least one of the following beneficial technical effects: By centrally managing identity credentials and access policies through a unified control plane, centralized authentication and access control are achieved, ensuring that only the first communication entity, after strict authentication and conforming to the access policy, can obtain access authorization. A cryptographically-based trusted authorization mechanism is established by generating time-sensitive authorization tokens, which are then verified by the second tunnel agent using the control plane's public key, effectively preventing unauthorized access and token forgery. The first and second tunnel agents negotiate encryption algorithm suites and perform key exchange to generate session keys, enabling flexible encryption strength selection and end-to-end key security management. The end-to-end encrypted tunnel established based on the session key allows the first and second communication entities to directly transmit encrypted data, avoiding the risk of data leakage at intermediate nodes. Through a dual control mechanism of authorization token validity period and end-to-end encrypted tunnel idle time, the system can promptly destroy session keys and terminate the encrypted tunnel, achieving dynamic management of access permissions and automatic control of session lifecycle, thereby reducing the risk of unauthorized access or abuse of sensitive resources. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating an end-to-end encrypted tunneling method under a zero-trust security architecture provided in an embodiment of this application. Figure 2 This is a schematic diagram of a zero-trust end-to-end encrypted tunnel system architecture provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an end-to-end encrypted tunnel system under a zero-trust security architecture provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0012] Explanation of reference numerals in the attached figures: 1000, electronic device; 1001, processor; 1002, communication bus; 1003, user interface; 1004, network interface; 1005, memory. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0014] In the description of the embodiments in this application, words such as "illustrative," "for example," or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "illustrative," "for example," or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "illustrative," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0015] Figure 1 This is a flowchart illustrating an end-to-end encrypted tunneling method under a zero-trust security architecture provided in an embodiment of this application. Figure 1 As shown, the method includes S101-S105: S101, in response to the request sent by the first communication entity to access the second communication entity, verify the identity credentials of the first communication entity, and determine whether the first communication entity allows access to the second communication entity according to the access policy.

[0016] When a first communication entity (e.g., the backend service of the statistics bureau's data analysis platform) needs to access a second communication entity (e.g., the National Health Commission's database server), the first tunnel proxy of the first communication entity sends an access request to the control plane. This request contains the identity credentials of the first communication entity and its intent to access the second communication entity. Upon receiving the request, the control plane first verifies the identity credentials of the first communication entity using an X.509 digital certificate authentication mechanism. The identity credentials contain the first communication entity's unique identifier, digital certificate, and related identity attribute information. The control plane confirms the legitimate identity of the first communication entity by verifying the signature validity of the digital certificate, the integrity of the certificate chain, and the certificate's validity period. This ensures that only authorized legitimate entities can initiate access requests, preventing malicious entities from impersonating legitimate users for unauthorized access.

[0017] After successful authentication, the control plane authorizes the access request based on pre-configured access policies. An access policy is a set of rules that defines which communication entities can access which target entities under what conditions, and the types of operations allowed. The specific policy judgment process includes checking whether the first communication entity has permission to access the second communication entity, whether the current access time is within the allowed time window, whether the requested operation type conforms to the permission scope defined by the policy, and whether other contextual conditions such as network location and device security status are met. The control plane's policy engine comprehensively evaluates these factors and makes an authorization decision based on the principle of least privilege, that is, only allowing the minimum privilege operations necessary to complete a specific task, rather than granting excessively broad network access permissions.

[0018] S102, when the identity credentials of the first communication entity meet the preset requirements and the first communication entity allows access to the second communication entity, an authorization token is generated and sent to the first tunnel agent of the first communication entity; so that the first tunnel agent carries the authorization token to initiate a connection request to the second tunnel agent of the second communication entity, and the second tunnel agent verifies the authorization token according to the public key of the control plane.

[0019] Once the control plane confirms the validity of the first communication entity's credentials and that the access policy allows it to access the second communication entity, it immediately generates an authorization token as the access credential. The authorization token is a time-sensitive digital credential containing key information such as the unique identifier of the first communication entity, the identifier of the second communication entity, the type of authorized operation (e.g., read, write, execute), the validity period, and a one-time random number. The entire token structure is encapsulated in JSON format and digitally signed using the control plane's private key to ensure its immutability and authenticity. The control plane employs the authorization token mechanism to implement time constraints and scope limitations on access permissions, avoiding the security risks that traditional long-term valid credentials may pose. Simultaneously, the one-time random number ensures the uniqueness of each token, preventing replay attacks.

[0020] After the control plane generates the authorization token, it sends it to the first tunnel proxy of the first communication entity through a secure channel. The first tunnel proxy is a security proxy component deployed in the network environment of the first communication entity, responsible for proxying secure communication between this entity and other network entities. Upon receiving the authorization token, the first tunnel proxy immediately initiates a connection request to the second tunnel proxy of the second communication entity. This request message carries complete authorization token information and the negotiation parameters required for connection establishment. This design adopts the proxy pattern architecture, allowing the communication entity itself to handle complex security protocol details without having to deal with them. Instead, security functions are handled by a dedicated tunnel proxy component, simplifying application development complexity and improving the standardization of security implementation.

[0021] Upon receiving a connection request, the second tunnel proxy first verifies the authorization token using the control plane's public key. This verification process includes decrypting the digital signature using the public key to confirm the token was indeed issued by the control plane. Next, it parses the token content to check if the one-time random number has already been used, recording any unused random numbers in a local anti-replay list. Finally, it checks if the token's validity period is within the specified time window. The second tunnel proxy can independently complete token verification without contacting the control plane again because it employs an asymmetric encryption verification mechanism based on public-key cryptography. The control plane's public key can be pre-distributed to all tunnel proxies, allowing the verification process to be performed offline, significantly improving system response speed and scalability.

[0022] Based on the above embodiments, as an optional implementation, in S102, the authorization token includes the identifier of the first communication entity, the identifier of the second communication entity, the authorization operation type, the validity period, and a one-time random number, and the authorization token is digitally signed by the private key of the control plane.

[0023] The authorization tokens generated by the control plane use a structured data format to carry complete authorization information, ensuring the accuracy and verifiability of access control. The authorization token's data structure contains five core fields. First, there is the identifier of the first communication entity, a globally unique identifier within the system, typically using UUID format or a hierarchical identification system based on organizational codes. This clearly identifies the entity initiating the access request, ensuring that the token user and the authorized object are completely consistent. The identifier of the second communication entity also uses the same identifier specification, explicitly specifying the target entity being accessed. This two-way identification mechanism aims to achieve precise point-to-point authorization, avoiding unauthorized access issues that may arise from traditional coarse-grained access control, and ensuring that access permissions are limited to specific pairs of communication entities.

[0024] The authorized operation type field defines in detail the specific range of operations that the first communication entity is allowed to perform on the second communication entity. Operation types are typically represented as enumerated values, including basic permission types such as read, write, execute, and delete operations, as well as composite operation types customized for specific business scenarios, such as data query, report generation, and configuration modification. This fine-grained definition of operation permissions enables the system to implement access control based on the principle of least privilege, meaning that each access token is granted only the minimum operation permissions necessary to complete a specific task, rather than granting overly broad general access permissions. The explicit definition of operation types also provides precise data for subsequent access auditing and behavior monitoring. Security administrators can identify potential abnormal access behaviors and security threats by analyzing the usage of operation types.

[0025] The validity period field records the time constraint information of the authorization token. It typically uses a UTC timestamp format to represent the token's effective and expiration times, or a relative time format to represent the valid duration calculated from the token's generation. The implementation of the time constraint mechanism ensures the temporary nature of access permissions, avoiding the security risks that long-term valid credentials might pose. Especially in the event of credential leakage or changes in user permissions, time constraints can automatically limit the impact time and scope of potential security threats. Setting the validity period requires finding a balance between security and availability. Too short a validity period may lead to frequent re-authorization, impacting user experience, while too long a validity period may increase security risks. In practice, the time parameter is usually dynamically adjusted based on the sensitivity of the business scenario and the frequency of access.

[0026] One-time random numbers are a key security element in authorization tokens. Generated using cryptographically secure random number generation algorithms, they are typically 128-bit or 256-bit random binary data, represented as text using Base64 encoding. The primary function of one-time random numbers is to ensure the uniqueness of each authorization token and prevent replay attacks. Even if the rest of the token is identical, different random values ​​will result in different digital signatures, thus preventing attackers from reusing intercepted tokens for unauthorized access. The generation of random numbers must meet cryptographic security requirements, exhibiting unpredictability and uniform distribution. Typically, operating system-provided cryptographically secure random number generators or hardware random number generators are used to ensure the quality of the random numbers.

[0027] After assembling the complete authorization token data structure, the control plane digitally signs the entire token content using its private key. The digital signature process first serializes all fields of the token in a predefined order, generating a standardized binary data stream. Then, the SM3 cryptographic hash algorithm is used to calculate the hash value of this data stream. Finally, the SM2 elliptic curve digital signature algorithm and the control plane's private key are used to sign the hash value, generating the digital signature data. The adoption of this digital signature mechanism ensures the integrity and non-repudiation of the authorization token. Any malicious modification to the token content will cause signature verification to fail, thus being identified and rejected by the system. Simultaneously, the private key-based signature generation process ensures the token's authority; only entities possessing the control plane's private key can generate valid authorization tokens, preventing unauthorized entities from forging access credentials.

[0028] The generated authorization tokens are typically encapsulated and transmitted in JSON Web Token (JWT) format. The JWT format consists of three parts: a header, a payload, and a signature. The header declares the signature algorithm type and token type, the payload contains the five core authorization information fields mentioned above, and the signature is the digital signature of the header and payload content. The entire JWT token is represented in Base64URL encoding format, facilitating transmission and processing over HTTP and other text protocols. This standardized token format not only improves system interoperability but also provides a unified technical specification for token parsing, verification, and management.

[0029] Based on the above embodiments, as an optional implementation, in S102, the second tunnel agent verifies the authorization token based on the public key of the control plane, specifically including S21-S24: S21, the second tunnel agent uses the public key of the control plane to verify the digital signature of the authorization token.

[0030] The second tunneling proxy first performs digital signature verification, which is the foundation of the entire verification process. The digital signature verification process begins with the second tunneling proxy extracting the signature data and the original signed content from the received authorization token. Then, it performs cryptographic verification of the signature using a pre-configured control plane public key. Specifically, the verification process includes recalculating the hash value of the token content using the SM3 cryptographic hash algorithm, then verifying the signature data using the SM2 elliptic curve signature verification algorithm and the control plane's public key, and finally comparing the calculated result with the hash value contained in the signature. The significance of digital signature verification is to ensure that the authorization token truly originates from a trusted control plane, and is not a forged token created by a malicious third party, while also verifying that the token content has not been tampered with or corrupted during transmission. This public-key cryptography-based verification mechanism has a high level of security; even if an attacker intercepts the authorization token, they cannot forge a valid digital signature without knowing the control plane's private key.

[0031] S22, when the digital signature verification passes, the second tunnel agent parses the one-time random number in the authorization token and checks whether the one-time random number has been used.

[0032] The second tunnel proxy initiates its replay attack protection mechanism for one-time random numbers. First, it parses the one-time random number field from the verified authorization token. This field is typically represented in hexadecimal or Base64 encoding, and the parsing process must adhere to predefined token format specifications. After obtaining the one-time random number, the second tunnel proxy checks its locally maintained anti-replay list to see if the random number already exists. The anti-replay list is a data structure specifically designed to store used random numbers, typically implemented using a hash table or Bloom filter to improve search efficiency. If the same one-time random number is found in the anti-replay list, it indicates that the token may be the product of a replay attack—that is, an attacker attempting to reuse a previously intercepted valid token to gain unauthorized access. In this case, the second tunnel proxy immediately terminates the verification process and rejects the access request, while simultaneously logging the suspicious replay attack attempt in the security log.

[0033] S23, when the one-time random number is not used, the second tunnel agent records the one-time random number to the local anti-replay list and checks whether the validity period of the authorization token is within the validity period.

[0034] Once it's confirmed that a one-time random number has not been used, the second tunnel agent immediately adds it to the local anti-replay list. The timing of this operation is crucial; it must be completed before the token is officially accepted to ensure that even in high-concurrency scenarios, the same random number will not be accepted multiple times, preventing race conditions. Managing the anti-replay list requires balancing storage space and performance. Since the number of random numbers may continue to grow, the system typically cleans up expired random number records periodically, based on the token's validity period information. That is, when a token corresponding to a random number has exceeded its maximum validity period, the random number record can be safely deleted, thus avoiding storage and performance issues caused by the unlimited growth of the anti-replay list. After completing the random number recording, the second tunnel agent continues with a time validity check, extracting the validity period field from the authorized token and comparing it with the current system time to ensure the token is still within the preset validity period.

[0035] Time validity verification requires special attention to clock synchronization. Since the system clocks of different nodes in the network may deviate, the second tunnel proxy typically allows for a certain time tolerance range when performing time comparisons, such as a tolerance for clock deviations of a few minutes, to avoid valid tokens being incorrectly rejected due to minor time differences. The time verification process also needs to consider the token generation time and network transmission latency to ensure that the token is not mistakenly judged as expired due to transmission delays within the normal network transmission time. Furthermore, the system checks whether the token generation time is reasonable. If the token's generation time is significantly earlier than a reasonable range or later than the current time, it will be considered a suspicious token and rejected.

[0036] S24, if the authorization token is within its validity period, confirm that the verification is successful.

[0037] Once all pre-verification steps have successfully passed, the second tunnel proxy confirms the authorization token's validity and prepares to establish secure communication with the first tunnel proxy. This successful verification not only guarantees the token's legitimacy but, more importantly, ensures the security and trustworthiness of the entire access request chain. At this point, the second tunnel proxy records the successful verification event in its local log system, including key information such as the verification time, the first communication entity identifier, and the authorization operation type. These audit logs provide crucial evidence for subsequent security analysis and compliance checks.

[0038] S103, when the verification is successful, the first tunnel agent and the second tunnel agent exchange their respective lists of supported encryption algorithms and negotiate the selection of an encryption algorithm suite so that the first tunnel agent and the second tunnel agent can perform key exchange according to the encryption algorithm suite and generate a session key.

[0039] After the second tunnel agent completes authorization token verification, the two tunnel agents enter the encryption algorithm negotiation phase, which is a crucial step in establishing a secure communication tunnel. The first tunnel agent first sends the second tunnel agent a list of its supported encryption algorithms. This list is a structured dataset containing at least one key exchange algorithm (such as SM2 elliptic curve key exchange or ECDH key exchange), at least one symmetric encryption algorithm (such as SM4 block cipher or AES encryption), and at least one integrity verification algorithm (such as SM3 cryptographic hash or SHA-256 hash algorithm). Upon receiving this list, the second tunnel agent compares it with its own list of supported algorithms and, according to preset security strength priorities and performance requirements, selects the optimal combination of encryption algorithms from the intersection of the two lists to form the encryption algorithm suite for this communication session.

[0040] The algorithm negotiation process employs a consensus mechanism to ensure that both parties support the selected algorithm combination. This design aims to address potential differences in algorithm support between different systems and devices, while balancing security and compatibility. In the actual negotiation process, the system prioritizes domestically developed cryptographic algorithms (such as the SM2, SM3, and SM4 algorithm suites). This not only complies with national cryptographic management policies but also ensures the cryptographic security and controllability of critical information infrastructure. The algorithm suite selection result is included in the integrity verification of subsequent handshake messages to prevent man-in-the-middle attackers from tampering with the negotiation results or launching downgrade attacks, ensuring that both communicating parties reach a genuine and consistent consensus on the security parameters used.

[0041] After algorithm negotiation, the two tunnel agents immediately perform a key exchange process based on the selected suite of encryption algorithms. Taking SM2 elliptic curve key exchange as an example, the first tunnel agent uses the SM2 algorithm to generate a first key pair, including a first private key and a first public key, and sends the first public key to the second tunnel agent through the established secure channel. Simultaneously, the second tunnel agent also uses the same SM2 algorithm to generate a second key pair, including a second private key and a second public key, and sends the second public key to the first tunnel agent. The key exchange employs a variant of the elliptic curve Diffie-Hellman algorithm. The mathematical basis of this algorithm is the difficulty of the elliptic curve discrete logarithm problem; even if an attacker intercepts the exchanged public keys, they cannot derive the private key or shared key within a computationally feasible time.

[0042] Both tunnel proxies use each other's public key and their own private key to calculate the same shared key. This shared key is an intermediate result of the key exchange algorithm. To generate the final session key used for data encryption, both tunnel proxies use the SM3 cryptographic hash algorithm to hash the shared key and combine it with contextual information such as session identifiers and timestamps to generate a session key with sufficient entropy and randomness. The use of the SM3 hash algorithm not only enhances the randomness of the key but also effectively isolates the keys of different sessions through the key derivation process, ensuring that even if the key of one session is leaked, it will not affect the security of other sessions.

[0043] Based on the above embodiments, as an optional implementation, in S103, the first tunnel proxy and the second tunnel proxy perform key exchange according to the encryption algorithm suite to generate a session key, specifically including S31-S33: S31, the first tunnel agent generates a first key pair using the SM2 elliptic curve public key cryptography algorithm and sends the first public key to the second tunnel agent.

[0044] The first tunnel agent initiates the key exchange process by first calling the key generation function of the SM2 elliptic curve public-key cryptography algorithm to create the first key pair. The SM2 algorithm is designed based on an elliptic curve over a 256-bit prime field, where the elliptic curve equation adopts the standard Weierstrass form, and the curve parameters are carefully selected to ensure a balance between cryptographic security and computational efficiency. The generation of the first key pair first requires generating a 256-bit random number as the private key. This random number must meet cryptographic security requirements, i.e., possess sufficient randomness and unpredictability. Typically, a hardware random number generator or a certified software random number generator is used to ensure the quality of the random number. After the private key is generated, the system calculates the corresponding public key using elliptic curve dot product operations. This involves performing a scalar multiplication of the base point G of the elliptic curve with the private key to obtain a point on the elliptic curve as the public key. This calculation process leverages the difficulty of the elliptic curve discrete logarithm problem, ensuring that even if the public key is made public, an attacker cannot reverse-engineer the corresponding private key.

[0045] After generating the key pair, the first tunnel agent sends the first public key to the second tunnel agent via a secure communication channel. The public key transmission format typically uses either compressed or uncompressed point representation. The compressed format transmits only the parity indicators of the x and y coordinates of the elliptic curve points, significantly reducing the amount of data transmitted. The uncompressed format transmits the complete x and y coordinate information simultaneously. To ensure the integrity and authenticity of the public key during transmission, the first tunnel agent usually digitally signs the public key using its own private key and sends the signature along with the public key. This allows the second tunnel agent to verify the authenticity and integrity of the received public key.

[0046] S32, the second tunnel agent uses the SM2 elliptic curve public key cryptography algorithm to generate a second key pair and sends the second public key to the first tunnel agent.

[0047] The second tunneling agent generates the second key pair in the same manner as the first tunneling agent, employing the same elliptic curve parameters, random number generation standards, and public key calculation methods. The second tunneling agent also needs to ensure the secure storage of the private key and the trusted transmission of the public key. In particular, it must avoid using predictable pseudo-random number generators when generating random numbers to prevent attackers from deducing private key information by analyzing random number patterns. When the second tunneling agent sends the generated second public key to the first tunneling agent, it also needs to be digitally signed to ensure the bidirectional trustworthiness of the key exchange process. This bidirectional key generation and exchange mechanism achieves complete forward security. Even if one party's long-term identity private key is leaked in the future, it will not affect the security of the established session because the session key generation relies on a temporarily generated key pair, rather than a long-term stored identity key.

[0048] S33, the first tunnel agent and the second tunnel agent calculate the shared key based on the other party's public key and their own private key, respectively, and perform a hash operation on the shared key using the SM3 cryptographic hash algorithm to generate a session key.

[0049] The first tunneling agent performs an elliptic curve dot product (ECD) on the received second public key using its own first private key, resulting in a shared point on the elliptic curve. Simultaneously, the second tunneling agent performs the same ECD on the received first public key using its own second private key. Due to the mathematical properties of the elliptic curve Diffie-Hellman protocol, these two calculations produce identical elliptic curve points, whose coordinates represent the shared key material. The shared key calculation process reflects the core security assumption of elliptic curve cryptography: the computational difficulty of the elliptic curve discrete logarithm problem. This ensures that even if an attacker observes the exchanged public keys, they cannot calculate the shared key without access to either party's private key.

[0050] To convert elliptic curve points into a session key format suitable for symmetric encryption, both parties need to perform further cryptographic processing on the calculated shared key. The system employs the SM3 cryptographic hash algorithm to hash the shared key. The SM3 algorithm can convert input data of arbitrary length into a fixed-length 256-bit hash output, exhibiting strong cryptographic properties such as one-wayness, collision resistance, and avalanche protection. The input to the hash operation typically includes the coordinates of the shared elliptic curve points, the identity information of both parties, and a unique identifier for the key exchange session. This combination ensures that even the same elliptic curve points will generate different session keys in different sessions, enhancing the uniqueness and uncorrelatedness of the key. The output of the hash operation is directly used as the session key, and its length perfectly matches the key requirements of the SM4 symmetric encryption algorithm, providing a secure key foundation for subsequent encrypted data transmission.

[0051] As an optional implementation method based on the above embodiments, in S103, negotiating and selecting an encryption algorithm suite specifically includes: In this optional implementation, the first tunnel agent and the second tunnel agent establish optimal secure communication parameters through a dynamic encryption algorithm negotiation mechanism. This design adapts to the diverse characteristics of different network environments and security requirements, and avoids the security risks and compatibility issues that may be caused by hard-coded fixed algorithms.

[0052] The construction and exchange of encryption algorithm lists is a fundamental step in the negotiation process. Each tunnel agent generates a list of supported algorithms based on its hardware capabilities, software configuration, and security policies. The key exchange algorithm list includes various options such as ECDH based on SM2 and ECDH based on the P-256 curve. The symmetric encryption algorithm list covers SM4 block ciphers, AES-128, and AES-256. The integrity verification algorithm list includes HMAC based on SM3 and HMAC based on SHA-256. The algorithm lists are prioritized according to security strength assessment, performance test results, and compliance requirements.

[0053] The negotiation process adopts a client-server model. The first tunnel proxy sends a list of algorithms to the second tunnel proxy. The list is in ASN.1 encoding or JSON format to ensure compatibility. After receiving the list, the second tunnel proxy performs matching analysis with its supported algorithms. Based on the principle of security priority, it selects the final algorithm combination from the intersection, prioritizing national cryptographic algorithms and elliptic curve algorithms to meet compliance requirements and performance needs.

[0054] The negotiation results generate a standardized data structure containing information about all selected algorithms, recording algorithm identifiers, parameter configurations, and negotiation metadata. To ensure the security of the negotiation process, the system includes the negotiation results in the integrity verification scope of the handshake message, using the integrity verification algorithm determined through negotiation to provide end-to-end protection for the entire handshake process, preventing man-in-the-middle attackers from maliciously modifying the algorithm selection.

[0055] Through this algorithm negotiation and integrity protection mechanism, the system achieves a flexible, secure, and efficient cryptographic parameter negotiation process, ensuring the system's scalability and interoperability, and providing reliable technical support for building large-scale, highly secure network communication systems.

[0056] S104, Based on the session key, an end-to-end encrypted tunnel is established between the first communication entity and the second communication entity, so that encrypted data can be transmitted directly between the first communication entity and the second communication entity through the end-to-end encrypted tunnel.

[0057] Once the first and second tunnel agents successfully generate a session key, the system immediately begins establishing an end-to-end encrypted tunnel, a core component for secure data transmission. The end-to-end encrypted tunnel is a virtual secure communication channel that provides transparent encryption protection for data transmission between the first and second communication entities at the network layer. This ensures that data packets originally transmitted in plaintext are encrypted and encapsulated before entering the network, and are only decrypted upon reaching the destination endpoint. The fundamental purpose of establishing this encrypted tunnel is to ensure that data remains encrypted throughout the entire transmission path. Even if data packets are maliciously intercepted during transmission, attackers cannot obtain any valid information.

[0058] The tunnel establishment process first requires assigning unique tunnel identifiers to both the first and second tunnel agents. A tunnel identifier is a globally unique identifier within the system used to distinguish different encrypted tunnel instances. In practice, tunnel identifiers are typically generated using 128-bit or 256-bit random numbers to ensure their uniqueness and unpredictability. When the two tunnel agents negotiate a tunnel, they write their respective tunnel identifiers into the tunnel negotiation message. This ensures that both communicating parties are aware of the other party's tunnel identifier, providing a basis for subsequent packet routing and verification. In addition to the tunnel identifier, the tunnel negotiation message also includes encryption parameter confirmation, session key verification code, and other negotiation parameters, ensuring that both parties agree on all key parameters for tunnel establishment.

[0059] The encrypted tunnel's data transmission mechanism employs a layered encapsulation design. When the first communication entity needs to send data to the second communication entity, the original data is first encrypted by the first tunnel agent using the session key and the SM4 block cipher algorithm. The SM4 algorithm is a symmetric block cipher algorithm independently developed in China, employing a 128-bit key length and a 128-bit block length, characterized by high security and high efficiency. The encryption process uses either CBC mode or GCM mode. CBC mode requires the generation of a random initialization vector to ensure that the same plaintext, encrypted at different times, produces different ciphertexts. GCM mode, on the other hand, provides both encryption and authentication functions, further enhancing data security.

[0060] To ensure data integrity during transmission and prevent tampering attacks, the first tunnel proxy calculates a message authentication code (MAC) for the encrypted data using the SM3 cryptographic hash algorithm after encryption. The MAC is a hash function calculation based on the key, verifying the integrity and authenticity of the data. Any malicious modification to the encrypted data will cause the MAC verification to fail. The SM3 algorithm generates a 256-bit hash value, exhibiting strong collision resistance and irreversibility. Even if an attacker obtains the encrypted data and the MAC, they cannot forge a valid MAC without knowing the key.

[0061] After the first tunnel agent completes encryption and message authentication code calculation, it encapsulates the encrypted data, message authentication code, and necessary transmission header information into a standard network data packet. The packet header carries the corresponding tunnel identifier, and the packet is then sent to the second communication entity through the established end-to-end encrypted tunnel. During transmission over the network, intermediate routing and network devices can only see the encrypted data content and metadata such as the tunnel identifier; they cannot obtain any meaningful information about the original data, thus achieving end-to-end protection during data transmission.

[0062] When the second tunnel agent receives a data packet from the encrypted tunnel, it first verifies the packet's legitimacy based on the tunnel identifier in the packet header, confirming that the packet indeed originates from an established trusted tunnel. After successful verification, the second tunnel agent extracts the encrypted data and message authentication code, recalculates the message authentication code using the same session key via the SM3 algorithm, and compares it with the received message authentication code. Only when the message authentication code verification is successful does it indicate that the data has not been tampered with during transmission. The second tunnel agent then uses the session key to decrypt the encrypted data via the SM4 algorithm, recovering the original data to be transmitted, and forwards it to the second communication entity.

[0063] Based on the above embodiments, as an optional implementation, in S104, the direct transmission of encrypted data between the first communication entity and the second communication entity through an end-to-end encrypted tunnel specifically includes S41-S44: S41, the first communication entity encrypts the data to be transmitted using the session key and the SM4 block cipher algorithm to generate encrypted data.

[0064] The first communicating entity performs symmetric encryption on the data to be transmitted, using the session key generated during the initial key exchange as the encryption key for the SM4 block cipher algorithm. The SM4 algorithm is a block cipher algorithm independently designed in China, employing a 128-bit key length and a 128-bit block length, achieving high-strength data encryption protection through 32 rounds of nonlinear transformations. The encryption process first requires preprocessing of the data to be transmitted, including data format standardization and block padding. Since the SM4 algorithm requires input data to be a multiple of 128 bits, the system needs to use a standard padding scheme, such as PKCS#7 padding, to handle data blocks shorter than one block length. The padding scheme adds specific padding bytes to the end of the data, ensuring the total length meets the algorithm requirements while guaranteeing the reversibility of the padding process.

[0065] SM4 encryption operations employ block cipher modes to handle data exceeding the length of a single block. Common modes include CBC, CFB, and CTR, each with its specific security features and performance characteristics. CBC mode establishes association between blocks by XORing the previous ciphertext block with the current plaintext block, effectively preventing pattern leakage caused by identical plaintext blocks producing identical ciphertext. However, it requires a random initialization vector to ensure the unpredictability of the encryption result. CFB and CTR modes convert block ciphers into stream ciphers, supporting encryption of data of arbitrary length without padding and offering better parallel processing capabilities. Regardless of the mode used, the system generates a unique initialization vector or counter initial value for each encryption operation, ensuring that the encryption results of the same data are completely different at different times, preventing attackers from inferring information from the original data through ciphertext analysis.

[0066] S42, the first communication entity uses the SM3 cryptographic hash algorithm to calculate the message authentication code for the encrypted data.

[0067] The first communicating entity uses the SM3 cryptographic hash algorithm to calculate a message authentication code for the encrypted data. This is a crucial step in ensuring data integrity and authenticity. The message authentication code is calculated using the HMAC construction method, a hash function-based message authentication code algorithm, specifically implemented as the HMAC-SM3 algorithm. The HMAC algorithm generates a fixed-length authentication tag by performing a specific combination and hash operation between the key and the message. This tag depends on both the message content and the key information, ensuring that only the entity with the correct key can generate or verify a valid authentication code. The HMAC-SM3 calculation process first performs an XOR operation on the session key with a fixed padding constant to generate an inner key and an outer key. Then, the inner key is combined with the encrypted data to perform an SM3 hash operation to obtain an intermediate result. Finally, the outer key is combined with the intermediate result to perform a second SM3 hash operation to obtain the final message authentication code.

[0068] The calculation of a Message Authentication Code (CAPC) typically includes the encrypted data itself and related metadata, such as data length, encryption parameters, and timestamps. This design prevents attackers from performing various malicious operations on the ciphertext, including ciphertext truncation, rearrangement, and replay attacks. The calculated CAPC is fixed at 256 bits, providing extremely high security; even if an attacker attempts to forge the CAPC, the probability of success is extremely low. The use of CAPC ensures data non-repudiation, meaning the sender cannot deny sending specific data, and the receiver cannot forge data from the sender, providing reliable authentication for data transmission.

[0069] S43, the first communication entity encapsulates the encrypted data and message authentication code and sends them to the second communication entity through an end-to-end encrypted tunnel.

[0070] The first communication entity encapsulates the encrypted data and message authentication code according to a predefined protocol format, and then sends them to the second communication entity through the established end-to-end encrypted tunnel. The data encapsulation process needs to include necessary protocol header information, such as the protocol version number, message type, data length, encryption algorithm identifier, initialization vector, and other metadata. This information provides necessary guidance for the receiver's correct parsing and processing. The encapsulation format typically adopts a structure similar to the TLS record layer, containing fixed-length header fields and variable-length payload data. The header fields use network byte order encoding to ensure cross-platform compatibility, while the payload data contains the encrypted original data and the corresponding message authentication code.

[0071] End-to-end encrypted tunneling ensures the secure transmission of encapsulated data packets across the network. While the tunnel itself may be built on existing network protocols such as TCP or UDP, encryption prevents intermediate network nodes from obtaining any useful information. During transmission, network reliability and performance requirements must also be considered, including network-level technical issues such as packet fragmentation, retransmission mechanisms, and flow control to ensure that encrypted data arrives at the target entity intact and on time. For large-volume data transmission, the system may employ streaming, dividing large files into multiple data blocks, each encrypted and authenticated separately. Each data block contains an independent message authentication code and sequence number, allowing the receiver to process multiple data blocks in parallel and detect any loss or out-of-order delivery.

[0072] S44, the second communication entity verifies the integrity of the message authentication code using the SM3 cryptographic hash algorithm. After successful verification, it uses the session key to decrypt the encrypted data using the SM4 block cipher algorithm to generate the data to be transmitted.

[0073] After receiving the encapsulated data packet, the second communication entity first parses the protocol header to extract key information such as encryption parameters, data length, and message authentication code. Then, it begins the reverse processing of integrity verification and data decryption. Integrity verification is the first step in data processing. The second communication entity uses the same session key and HMAC-SM3 algorithm to recalculate the message authentication code on the received encrypted data and compares it with the received authentication code. This verification process must employ a constant-time comparison algorithm, meaning the comparison time does not depend on differences in data content, preventing attackers from analyzing and inferring partial information from the authentication code through timing attacks. If the two authentication codes match perfectly, it indicates that the data has not been tampered with during transmission and indeed comes from the sender with the correct key; the system can continue with decryption. If the authentication codes do not match, the system immediately discards the data packet and records a security alarm to prevent tampered data from entering subsequent processing.

[0074] After integrity verification, the second communicating entity uses the session key and the SM4 block cipher algorithm to decrypt the encrypted data. The decryption process is the complete reverse of the encryption process, requiring the same operating mode and initialization vector parameters. The decryption operation first restores the original data blocks, then removes the previously added padding bytes, ultimately obtaining the complete original data. The decryption process also includes additional security checks, such as verifying the correctness of the padding format and checking the reasonableness of the data length. These checks can detect certain types of cryptographic attack attempts. After decryption, the second communicating entity receives the exact same data as when the first communicating entity sent it, and the entire end-to-end secure transmission process is declared successful.

[0075] S105, when the authorization token reaches its valid duration or the idle time of the end-to-end encrypted tunnel exceeds a preset threshold, destroy the session key and terminate the end-to-end encrypted tunnel.

[0076] The system implements a time-constrained dynamic security management mechanism, ensuring timely recovery of security resources and risk control by monitoring the validity period of authorization tokens and the activity status of end-to-end encrypted tunnels. The validity period of an authorization token is a time window pre-set by the control plane based on access policies and security level requirements when the token is generated. This window typically ranges from a few minutes to several hours, depending on business needs and security requirements. This time-limited mechanism aims to implement the security concept of temporary authorization, meaning that access permissions should have a clear time limit to avoid security risks that may arise from long-term valid access credentials. The system adopts this time-based access control strategy because, in a zero-trust security architecture, any access permission should adhere to the principles of least privilege and shortest duration, ensuring that access permissions are only valid within the necessary time frame and automatically expire after that time, thereby significantly reducing security risks caused by credential leakage or abuse.

[0077] After establishing an end-to-end encrypted tunnel, both the first and second tunnel proxies continuously monitor the tunnel's usage status and time parameters, including the remaining validity time of the authorization token and the tunnel's idle time. Idle time refers to the elapsed time since the last data transmission activity. When a tunnel has no data transmission activity within a preset threshold time (such as 30 minutes or 1 hour), the system marks it as idle. This idle detection mechanism relies on the tunnel proxies continuously tracking packet transmission timestamps. Whenever a packet is transmitted through the tunnel, the system updates the last active time record and resets the idle timer. The main purpose of monitoring idle time is to promptly reclaim unused network resources, prevent a large number of idle encrypted tunnels from consuming system resources, and reduce the potential attack surface of long-standing secure channels.

[0078] When the system detects that an authorization token has reached its preset validity period limit, the control plane sends a token expiration notification to the relevant tunnel agent, instructing it to immediately cease all communication activities based on that token. Similarly, when a tunnel agent detects that the idle time of an end-to-end encrypted tunnel exceeds a preset threshold, it will proactively initiate a tunnel termination process. The tunnel termination process first requires both tunnel agents to negotiate and confirm that there are no ongoing data transmission tasks, and then performs resource cleanup operations in a secure order. In the actual termination process, the tunnel agent first stops accepting new data transmission requests, waits for currently processed data packets to complete transmission, and then sends a tunnel closure negotiation message to the other end. Upon receiving a confirmation reply, it formally enters the resource destruction phase.

[0079] Destroying the session key is a critical security operation during tunnel termination, ensuring that key information is completely erased and unrecoverable. The specific destruction process involves using secure memory erasure techniques to repeatedly overwrite the memory area storing the session key with random data, typically three or more times, to ensure the original key data cannot be recovered by any technical means. For key copies that may be stored in disk cache or swap files, the system will invoke the operating system's secure deletion interface for complete erasure and, if necessary, perform disk defragmentation to eliminate any potential data remnants. After the session key is destroyed, the system will clean up all state information related to the tunnel, including the tunnel identifier mapping table, routing information, statistics, etc., ensuring that no security traces that could be exploited are left behind.

[0080] In addition to session key destruction, the tunnel termination process also includes the formal closure of the network connection and the release of related network resources. The tunnel agent sends a connection termination request to the network layer, closes the network socket used for data transmission, releases the occupied port number and memory buffer, and updates the local connection state table. To ensure the integrity and auditability of the termination process, the system records detailed information about the tunnel termination in the security log, including the termination reason (token expiration or idle timeout), termination time, identification of the participating communication entities, and statistical information on the transmitted data. These audit logs are of great value for subsequent security analysis and compliance checks.

[0081] Based on the above embodiments, as an optional implementation method, the method further includes: A unique tunnel identifier is assigned to the first tunnel agent and the second tunnel agent respectively; when establishing an end-to-end encrypted tunnel, the first tunnel agent and the second tunnel agent write their respective tunnel identifiers into the tunnel negotiation message; when transmitting encrypted data, the first communication entity and the second communication entity carry the corresponding tunnel identifier in the header of the data packet; when the receiving tunnel agent receives the data packet, it verifies the legality of the data packet based on the tunnel identifier.

[0082] In this implementation, the system achieves precise management and access control of end-to-end encrypted tunnels through a tunnel identification mechanism. The control plane assigns a globally unique tunnel identifier to each tunnel agent. This identifier adopts a hierarchical structure design and includes information such as region identifier, device type, and device instance. By combining device hardware characteristics and random number generation, the uniqueness and unpredictability of the identifier are ensured.

[0083] During tunnel establishment, the first and second tunnel agents write their respective tunnel identifiers into the identity information field of the tunnel negotiation message and digitally sign the entire message. The receiver verifies the authenticity and validity of the tunnel identifier by checking the digital signature and comparing it with the registration information of the control plane. This two-way identifier declaration mechanism ensures the credibility of the identity during tunnel establishment.

[0084] During data transmission, the communicating entity carries the corresponding tunnel identifier in the extended field of each data packet header, along with control information such as the data packet sequence number and timestamp. Upon receiving the data packet, the receiving tunnel agent extracts the tunnel identifier from the header and compares it with a locally maintained list of valid tunnel identifiers. Simultaneously, it performs time window checks and sequence number verification to prevent replay attacks and abnormal transmissions.

[0085] Through this tunnel identifier verification mechanism, the system achieves precise routing control and real-time security checks at the data packet level, ensuring strict isolation between different tunnels, effectively preventing data leakage and malicious attacks, and providing reliable secure communication guarantees for large-scale network environments.

[0086] Figure 2 This is a schematic diagram of a zero-trust end-to-end encrypted tunnel system architecture provided in an embodiment of this application, such as... Figure 2 As shown, this system employs a design philosophy of separating control and data to achieve secure network communication. The entire system consists of three core layers: a top-level control plane identity and policy service, a middle tunnel orchestrator, and bottom-level data plane endpoints. The control plane contains an identity database and a policy engine, acting as a trust anchor to provide passwordless authentication, authorization, and token issuance functions, but explicitly states that it does not forward data streams, ensuring strict separation of control and data. The tunnel orchestrator is responsible for coordinating the establishment and management of connections between various tunnel agents, while the data plane contains two communication endpoints, Service A and Service B, which deploy lightweight tunnel agent A and lightweight tunnel agent B respectively to handle the actual encrypted data transmission.

[0087] The entire communication process establishes a secure connection and transmits data through four steps. First, agent A, carrying its identity certificate, initiates an authentication and authorization request to the control plane via the control signaling flow (represented by the dotted line). The control plane verifies the legitimacy of agent A's identity and determines its access permissions according to the rules of the policy engine. After successful verification, the control plane issues a short-term authorization token to agent A. This token contains the specific scope of permissions for accessing service B and a validity period limit, reducing the security risk of token leakage through short-term validity. Next, agent A sends the obtained authorization token to agent B for verification. This step is marked "optional" in the diagram, indicating that the system supports flexible verification methods. The token's validity can be verified directly by agent B, or it can be centrally verified through the control plane. Once the token verification is successful, agents A and B begin establishing an end-to-end encrypted tunnel, using the SM2 elliptic curve cryptography algorithm for key exchange, the SM4 block cipher algorithm for data encryption, and the SM3 cryptographic hash algorithm for integrity verification, forming a complete domestic cryptographic algorithm protection system.

[0088] The core advantage of this architecture lies in realizing the fundamental principle of zero-trust networks: distrusting no entity within the network, and requiring all communication to undergo rigorous authentication and authorization checks. The control plane, acting as a centralized trust decision point, uniformly manages authentication and access policies, ensuring consistency and manageability of security policies while avoiding becoming a performance bottleneck or single point of failure by not participating in data forwarding. The deployment of a lightweight tunnel proxy provides the system with excellent scalability and deployment flexibility, adapting to network environments of different sizes and types. The use of national cryptographic algorithm suites not only meets national information security compliance requirements but also provides security strength comparable to international standards, providing technical assurance for building an independent and controllable secure communication system.

[0089] Based on the above method, this application also discloses an end-to-end encrypted tunnel system under a zero-trust security architecture, such as... Figure 3 As shown, Figure 3 This is a schematic diagram of an end-to-end encrypted tunnel system under a zero-trust security architecture provided in an embodiment of this application. The system includes: a response module, a generation module, a verification module, a construction module, and a termination module; wherein, The system comprises the following modules: a response module, used to respond to a request from the first communication entity to access the second communication entity, verify the identity credentials of the first communication entity, and determine whether the first communication entity allows access to the second communication entity according to the access policy; a generation module, used to generate an authorization token when the identity credentials of the first communication entity meet preset requirements and the first communication entity allows access to the second communication entity, and send the authorization token to the first tunnel agent of the first communication entity; so that the first tunnel agent carries the authorization token to initiate a connection request to the second tunnel agent of the second communication entity, and the second tunnel agent verifies the authorization token according to the public key of the control plane; a verification module, used when the verification is successful, for the first tunnel agent and the second tunnel agent to exchange their respective supported encryption algorithm lists, negotiate and select an encryption algorithm suite, so that the first tunnel agent and the second tunnel agent perform key exchange according to the encryption algorithm suite and generate a session key; a construction module, used to establish an end-to-end encrypted tunnel between the first communication entity and the second communication entity according to the session key, so that the first communication entity and the second communication entity can directly transmit encrypted data through the end-to-end encrypted tunnel; and a termination module, used to destroy the session key and terminate the end-to-end encrypted tunnel when the authorization token reaches its validity period or the idle time of the end-to-end encrypted tunnel exceeds a preset threshold.

[0090] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0091] Please see Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 1000 may include: at least one processor 1001, at least one network interface 1004, a user interface 1003, a memory 1005, and at least one communication bus 1002.

[0092] The communication bus 1002 is used to realize the connection and communication between these components.

[0093] The user interface 1003 may include a display screen and a camera. Optionally, the user interface 1003 may also include a standard wired interface and a wireless interface.

[0094] The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0095] The processor 1001 may include one or more processing cores. The processor 1001 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1005, and by calling data stored in the memory 1005. Optionally, the processor 1001 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 1001 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 1001 and may be implemented as a separate chip.

[0096] The memory 1005 may include random access memory (RAM) or read-only memory. Optionally, the memory 1005 may include a non-transitory computer-readable storage medium. The memory 1005 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1005 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 4 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for an end-to-end encrypted tunneling method under a zero-trust security architecture.

[0097] exist Figure 4In the electronic device 1000 shown, the user interface 1003 is mainly used to provide an interface for users to input data and obtain user input data; while the processor 1001 can be used to call an application stored in the memory 1005 that is an end-to-end encrypted tunneling method under a zero-trust security architecture. When executed by one or more processors, the electronic device performs one or more of the methods described in the above embodiments.

[0098] An electronic device readable storage medium stores instructions that, when executed by one or more processors, cause the electronic device to perform one or more of the methods described in the above embodiments.

[0099] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0100] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0101] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus 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 system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some service interfaces; indirect couplings or communication connections between devices or units may be electrical or other forms.

[0102] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0104] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0105] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. An end-to-end encrypted tunneling method under a zero-trust security architecture, characterized in that, Applied to the control plane, the control plane receives identity credentials reported by a first communication entity and a second communication entity, completes registration, and stores and manages access policies. The method includes: In response to the request sent by the first communication entity to access the second communication entity, the identity credentials of the first communication entity are verified, and it is determined whether the first communication entity allows access to the second communication entity according to the access policy. When the identity credentials of the first communication entity meet the preset requirements and the first communication entity allows access to the second communication entity, an authorization token is generated and sent to the first tunnel agent of the first communication entity; so that the first tunnel agent carries the authorization token to initiate a connection request to the second tunnel agent of the second communication entity, and the second tunnel agent verifies the authorization token according to the public key of the control plane; When the verification is successful, the first tunnel agent and the second tunnel agent exchange their respective lists of supported encryption algorithms and negotiate to select an encryption algorithm suite, so that the first tunnel agent and the second tunnel agent can perform key exchange according to the encryption algorithm suite and generate a session key; Based on the session key, an end-to-end encrypted tunnel is established between the first communication entity and the second communication entity, so that the first communication entity and the second communication entity can directly transmit encrypted data through the end-to-end encrypted tunnel; When the authorization token reaches its validity period or the idle time of the end-to-end encrypted tunnel exceeds a preset threshold, the session key is destroyed and the end-to-end encrypted tunnel is terminated.

2. The end-to-end encrypted tunneling method under a zero-trust security architecture according to claim 1, characterized in that, The authorization token includes the identifier of the first communication entity, the identifier of the second communication entity, the authorization operation type, the validity period, and a one-time random number. The authorization token is digitally signed by the private key of the control plane.

3. The end-to-end encrypted tunneling method under a zero-trust security architecture according to claim 2, characterized in that, The second tunnel agent verifies the authorization token based on the public key of the control plane, including: The second tunnel agent uses the public key of the control plane to verify the digital signature of the authorization token; When the digital signature verification is successful, the second tunnel proxy parses the one-time random number in the authorization token and checks whether the one-time random number has been used. When the one-time random number is not used, the second tunnel agent records the one-time random number to the local anti-replay list and checks whether the validity period of the authorization token is within the validity period; The verification is confirmed when the authorization token is within its validity period.

4. The end-to-end encrypted tunneling method under a zero-trust security architecture according to claim 1, characterized in that, The first tunnel proxy and the second tunnel proxy perform a key exchange based on the encryption algorithm suite to generate a session key, including: The first tunnel proxy generates a first key pair using the SM2 elliptic curve public key cryptography algorithm and sends the first public key to the second tunnel proxy; The second tunneling agent uses the SM2 elliptic curve public key cryptography algorithm to generate a second key pair and sends the second public key to the first tunneling agent; The first tunnel proxy and the second tunnel proxy calculate a shared key based on the other party's public key and their own private key, respectively, and then perform a hash operation on the shared key using the SM3 cryptographic hash algorithm to generate a session key.

5. The end-to-end encrypted tunneling method under a zero-trust security architecture according to claim 1, characterized in that, The first communication entity and the second communication entity directly transmit encrypted data through the end-to-end encrypted tunnel, including: The first communication entity encrypts the data to be transmitted using the session key via the SM4 block cipher algorithm to generate encrypted data; The first communication entity uses the SM3 cryptographic hash algorithm to calculate the message authentication code for the encrypted data; The first communication entity encapsulates the encrypted data and the message authentication code and sends them to the second communication entity through the end-to-end encrypted tunnel; The second communication entity verifies the integrity of the message authentication code using the SM3 cryptographic hash algorithm. After successful verification, it uses the session key to decrypt the encrypted data using the SM4 block cipher algorithm to generate the data to be transmitted.

6. The end-to-end encrypted tunneling method under a zero-trust security architecture according to claim 1, characterized in that, The negotiated selection of encryption algorithm suite includes: The first tunnel proxy and the second tunnel proxy exchange their respective lists of supported encryption algorithms, the list of encryption algorithms including at least one key exchange algorithm, at least one symmetric encryption algorithm and at least one integrity verification algorithm; The key exchange algorithm, symmetric encryption algorithm, and integrity verification algorithm are negotiated and selected from the list of encryption algorithms, a negotiation result is generated, and the negotiation result is incorporated into the integrity verification of the handshake message.

7. The end-to-end encrypted tunneling method under a zero-trust security architecture according to claim 1, characterized in that, The method further includes: A unique tunnel identifier is assigned to the first tunnel agent and the second tunnel agent respectively; when establishing the end-to-end encrypted tunnel, the first tunnel agent and the second tunnel agent write their respective tunnel identifiers into the tunnel negotiation message; When transmitting encrypted data, the first communication entity and the second communication entity carry the corresponding tunnel identifier in the header of the data packet; When the receiving party's tunnel agent receives a data packet, it verifies the validity of the data packet based on the tunnel identifier.

8. An end-to-end encrypted tunnel system under a zero-trust security architecture, characterized in that, The system includes: a response module, a generation module, a verification module, a construction module, and a termination module; wherein, The response module is used to respond to a request sent by the first communication entity to access the second communication entity, verify the identity credentials of the first communication entity, and determine whether the first communication entity allows access to the second communication entity according to the access policy. The generation module is configured to generate an authorization token and send the authorization token to the first tunnel agent of the first communication entity when the identity credential of the first communication entity meets the preset requirements and the first communication entity allows access to the second communication entity; so that the first tunnel agent carries the authorization token to initiate a connection request to the second tunnel agent of the second communication entity, and the second tunnel agent verifies the authorization token according to the public key of the control plane; The verification module is used to, when the verification is successful, exchange the lists of supported encryption algorithms between the first tunnel proxy and the second tunnel proxy, negotiate and select an encryption algorithm suite, so that the first tunnel proxy and the second tunnel proxy can perform key exchange according to the encryption algorithm suite and generate a session key; The construction module is used to establish an end-to-end encrypted tunnel between the first communication entity and the second communication entity according to the session key, so that the first communication entity and the second communication entity can directly transmit encrypted data through the end-to-end encrypted tunnel. The termination module is used to destroy the session key and terminate the end-to-end encrypted tunnel when the authorization token reaches its validity period or the idle time of the end-to-end encrypted tunnel exceeds a preset threshold.

9. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1-7.

Images