Controller authentication-based encrypted tunnel establishment method and device, and electronic device

Abstract

The application discloses a kind of based on controller authentication's encryption tunnel establishment method and device, electronic equipment, it is related to network security technical field or other related fields, the method includes: after encryption tunnel establishment flow is started, by client device to server device sends security negotiation request, and by server device returns security negotiation response;After receiving security negotiation response, by client device to server device sends identity authentication request, simultaneously to controller sends chain building permission request;By controller, chain building permission response is generated based on chain building permission request, and is synchronized to server device;By server device, chain building permission response and identity authentication request are verified, in the case where verification succeeds, the communication encryption tunnel between server device and client device is established based on identity authentication request.The application solves the technical problem that encryption tunnel establishment flow in the related art relies on static authorization detection, cannot cover real-time dynamic attack, leading to insufficient security.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and more specifically, to a method and apparatus for establishing an encrypted tunnel based on controller authentication, and an electronic device. Background Technology

[0002] Currently, with the increasing complexity of enterprise network environments and the widespread application of cloud services, SD-WAN (Software-Defined Wide Area Network) technology is highly favored due to its efficient and flexible network management, multi-link aggregation, and optimization features. The key component in the SD-WAN architecture—the SD-WAN controller—is responsible for global network policy enforcement and traffic routing, while the CPEs (Customer Premises Equipment) located at each site are responsible for executing controller instructions and establishing and maintaining encrypted tunnels. At the security level, the IPSec protocol (Internet Security Protocol) combined with IKEv2 (Internet Key Exchange Protocol version 2) is widely adopted to build end-to-end encrypted tunnels, aiming to ensure the confidentiality and integrity of data during transmission.

[0003] However, existing SD-WAN security mechanisms have significant shortcomings in authentication and real-time authorization. On one hand, the IKEv2 protocol is primarily used for peer authentication and key exchange, but it doesn't adequately consider the dynamic binding between devices and controllers during tunnel establishment. In other words, it lacks effective means to ensure that the CPE attempting to establish a tunnel truly belongs to a specific controller management domain. On the other hand, while traditional pre-shared keys or X.509 certificate authentication methods can confirm device identity to some extent, they fail to integrate with the SD-WAN controller for more granular real-time authentication and authorization. This results in the inability to effectively prevent unauthorized or cross-domain devices from accessing the network even when the network devices are configured with correct credentials, thus posing a potential threat to the security of the entire network.

[0004] The shortcomings of existing technologies include: lack of dynamic identity binding and real-time authorization, vulnerability to replay attacks, difficulty in traceable auditing, and separation of security mechanisms from SD-WAN controller functions. In general, the related technologies have technical problems such as the encrypted tunnel establishment process relying on static authorization detection, which cannot cover real-time dynamic attacks, resulting in insufficient security.

[0005] There is currently no effective solution to the above problems. Summary of the Invention

[0006] This invention provides a method, apparatus, and electronic device for establishing an encrypted tunnel based on controller authentication, which at least solves the technical problem in related technologies that the encrypted tunnel establishment process relies on static authorization detection, which cannot cover real-time dynamic attacks and leads to insufficient security.

[0007] According to one aspect of the present invention, a method for establishing an encrypted tunnel based on controller authentication is provided, applied to a target network environment including a controller, a server device, and a client device. The method includes: after the encrypted tunnel establishment process is initiated, the client device sends a security negotiation request to the server device, and the server device returns a security negotiation response, wherein the security negotiation request carries encryption algorithm materials, and the security negotiation response includes initial key materials generated based on the encryption algorithm materials; upon receiving the security negotiation response, the client device sends an authentication request to the server device and simultaneously sends a chain-building permission request to the controller, wherein the authentication request carries a client device identifier and an authentication signature, and the chain-building permission request carries at least the client device identifier; the controller generates a chain-building permission response based on the chain-building permission request and synchronizes it to the server device, wherein the chain-building permission response includes a client authentication result and a session real-time authentication result; the server device verifies the authentication signature in the chain-building permission response and the authentication request, and if all verifications are successful, establishes an encrypted communication tunnel between the server device and the client device based on the authentication request.

[0008] Furthermore, before the encrypted tunnel establishment process is initiated, the encrypted tunnel establishment method further includes: the controller sending server-side operation configuration information to the server-side device through a pre-agreed encrypted management channel, wherein the server-side operation configuration information includes: listening port parameters, encryption algorithm priority information, shared key exchange algorithm parameter set, and control identifier; after receiving the server-side operation configuration information, the server-side device loads a daemon process based on the listening port parameters, and in the daemon process starts a device authentication program based on the control identifier, starts a listening program based on the listening port parameters, creates a security association database based on the encryption algorithm priority information, and generates a server local key based on the shared key exchange algorithm parameter set.

[0009] Furthermore, before the encrypted tunnel establishment process is initiated, the encrypted tunnel establishment method further includes: the controller sending client operation configuration information to the client device through a pre-agreed encrypted management channel, wherein the client operation configuration information includes: security protocol parameters, shared key exchange algorithm parameter set, security policy, and network configuration parameters; after receiving the client operation configuration information, the client device generates an instantiated protocol stack based on the security protocol parameters, the security policy, and the network configuration parameters, and generates a client local key based on the shared key exchange algorithm parameter set.

[0010] Furthermore, after the encrypted tunnel establishment process is initiated, the step of the client device sending a security negotiation request to the server device includes: the client device generating a first random number using a local random number generator; retrieving the client's public key from the client's local key, and packaging the first random number and the client's public key into the security negotiation request; retrieving the list of encryption algorithms to be negotiated, the list of message authentication code algorithms, and the pseudo-random function used for key derivation as encryption algorithm materials, and associating the encryption algorithm materials with the security negotiation request; and sending the associated security negotiation request and the encryption algorithm materials to the server device.

[0011] Further, the step of the server device returning a security negotiation response includes: the server device parsing the security negotiation request and the encryption algorithm material, and calling a local random number generator to generate a second random number; retrieving the server's public key and private key from the server's local key, and performing encryption operations based on the server's private key and the client's public key to generate a shared key; determining the target encryption algorithm from the list of encryption algorithms to be negotiated to obtain a first type of algorithm identifier, and determining the target message authentication code algorithm from the list of message authentication code algorithms to obtain a second type of algorithm identifier; performing key derivation operations based on the target encryption algorithm, the pseudo-random function, and the shared key to obtain a derived key set; and packaging the second random number, the server's public key, the first type of algorithm identifier, the second type of algorithm identifier, and the derived key set into the security negotiation response and returning it to the client device.

[0012] Further, upon receiving the security negotiation response, the step of the client device sending an authentication request to the server device and simultaneously sending a blockchain establishment permission request to the controller includes: parsing the security negotiation response; performing encryption operations based on the server public key and the client private key to obtain the shared key; and storing the shared key along with the first type of algorithm identifier, the second type of algorithm identifier, and the derived key set; obtaining the client device identifier; generating the authentication signature based on the client private key; encrypting the client device identifier and the authentication signature using the shared key to generate the authentication request; and sending the authentication request to the server device; constructing the blockchain establishment permission request based on the first random number and the client device identifier; and sending the blockchain establishment permission request to the controller through a pre-agreed encryption management channel.

[0013] Further, the step of the controller generating a blockchain establishment permission response based on the blockchain establishment permission request and synchronizing it to the server device includes: upon receiving the blockchain establishment permission request, the controller searches in the registration domain based on the client device identifier to obtain a search result, wherein the registration domain is used to record pre-registered qualified devices; if the search result indicates that the registration domain contains the client device identifier, the client identity authentication result is set to authentication passed; if the search result indicates that the registration domain does not contain the client device identifier, the client identity authentication result is set to authentication failed; the session real-time authentication result is generated based on the first random number and the first current timestamp; the client identity authentication result and the session real-time authentication result are packaged into the blockchain establishment permission response, and a digital signature of the blockchain establishment permission response is generated; the blockchain establishment permission response is sent to the server device through a pre-agreed encrypted management channel.

[0014] Further, the step of the server-side device verifying the authentication signature in the blockchain establishment permission response and the identity authentication request includes: parsing the digital signature in the blockchain establishment permission response and verifying the integrity of the digital signature to obtain a first verification result; parsing the session real-time authentication result in the blockchain establishment permission response to obtain a first current timestamp, comparing the first current timestamp with a second current timestamp of the server's local clock based on a preset time window to obtain a second verification result; and confirming whether the identity information is consistent between the client identity authentication result in the blockchain establishment permission response and the authentication signature in the identity authentication request to obtain a third verification result.

[0015] According to another aspect of the present invention, an encrypted tunnel establishment apparatus based on controller authentication is also provided, applied to a target network environment including a controller, a server device, and a client device. The encrypted tunnel establishment apparatus includes: a first sending unit, configured to, after the encrypted tunnel establishment process is initiated, send a security negotiation request from the client device to the server device, and have the server device return a security negotiation response, wherein the security negotiation request carries encryption algorithm materials, and the security negotiation response includes: initial key materials generated based on the encryption algorithm materials; and a second sending unit, configured to, upon receiving the security negotiation response, send an authentication authentication message from the client device to the server device. The system comprises: a client device authentication request and a chain establishment permission request sent to the controller; a generation unit for generating a chain establishment permission response based on the chain establishment permission request and synchronizing it to the server device; and an establishment unit for verifying the authentication signature in the chain establishment permission response and the authentication request, and establishing an encrypted communication tunnel between the server device and the client device based on the authentication request if all verifications are successful.

[0016] Furthermore, the encrypted tunnel establishment device further includes: a first sending module, used to send server-side operation configuration information to the server-side device through a pre-agreed encryption management channel before the encrypted tunnel establishment process starts, wherein the server-side operation configuration information includes: listening port parameters, encryption algorithm priority information, shared key exchange algorithm parameter set, and control identifier; and a configuration module, used to load a daemon process based on the listening port parameters after the server-side device receives the server-side operation configuration information, and in the daemon process start a device authentication program based on the control identifier, start a listening program based on the listening port parameters, create a security association database based on the encryption algorithm priority information, and generate a server local key based on the shared key exchange algorithm parameter set.

[0017] Furthermore, the encrypted tunnel establishment device further includes: a second sending module, used to send client operation configuration information to the client device through a pre-agreed encryption management channel before the encrypted tunnel establishment process starts, wherein the client operation configuration information includes: security protocol parameters, shared key exchange algorithm parameter set, security policy, and network configuration parameters; and a first generation module, used to generate an instantiated protocol stack based on the security protocol parameters, the security policy, and the network configuration parameters, and generate a client local key based on the shared key exchange algorithm parameter set, after receiving the client operation configuration information.

[0018] Further, the first sending unit includes: a second generation module, used by the client device to generate a first random number using a local random number generator; a first packaging module, used to retrieve the client's public key from the client's local key, and package the first random number and the client's public key into the security negotiation request; an association module, used to retrieve a list of encryption algorithms to be negotiated, a list of message authentication code algorithms, and a pseudo-random function for key derivation as encryption algorithm materials, and associate the encryption algorithm materials with the security negotiation request; and a third sending module, used to send the associated security negotiation request and the encryption algorithm materials to the server device.

[0019] Furthermore, the first sending unit further includes: a third generation module, used by the server device to parse the security negotiation request and the encryption algorithm material, and call a local random number generator to generate a second random number; a first operation module, used to retrieve the server public key and server private key from the server's local key, and perform encryption operations based on the server private key and the client public key to generate a shared key; a determination module, used to determine the target encryption algorithm in the list of encryption algorithms to be negotiated, to obtain a first type of algorithm identifier, and determine the target message authentication code algorithm in the list of message authentication code algorithms, to obtain a second type of algorithm identifier; a second operation module, used to perform key derivation operations based on the target encryption algorithm, the pseudo-random function, and the shared key to obtain a derived key set; and a second packaging module, used to package the second random number, the server public key, the first type of algorithm identifier, the second type of algorithm identifier, and the derived key set into the security negotiation response, and return it to the client device.

[0020] Further, the second sending unit includes: a third calculation module, used to parse the security negotiation response, perform encryption calculations based on the server public key and the client private key to obtain the shared key, and store the shared key along with the first type of algorithm identifier, the second type of algorithm identifier, and the derived key set; a fourth generation module, used to obtain the client device identifier and generate the identity authentication signature based on the client private key; a fourth sending module, used to encrypt the client device identifier and the identity authentication signature using the shared key, generate the identity authentication request, and send the identity authentication request to the server device; and a fifth sending module, used to construct the chain establishment permission request based on the first random number and the client device identifier, and send the chain establishment permission request to the controller through a pre-agreed encryption management channel.

[0021] Further, the generation unit includes: a search module, used to, upon receiving the chain-building permission request, perform a search in the registration domain based on the client device identifier by the controller to obtain a search result, wherein the registration domain is used to record pre-registered qualified devices; a first setting module, used to set the client identity authentication result to authentication passed when the search result indicates that the registration domain contains the client device identifier; a second setting module, used to set the client identity authentication result to authentication failed when the search result indicates that the registration domain does not contain the client device identifier; a fifth generation module, used to generate the session real-time authentication result based on the first random number and the first current timestamp; a third packaging module, used to package the client identity authentication result and the session real-time authentication result into the chain-building permission response and generate a digital signature for the chain-building permission response; and a sixth sending module, used to send the chain-building permission response to the server device through a pre-agreed encrypted management channel.

[0022] Further, the establishment unit includes: a first verification module, used to parse the digital signature of the blockchain establishment permission response and verify the integrity of the digital signature to obtain a first verification result; a second verification module, used to parse the session real-time authentication result in the blockchain establishment permission response to obtain a first current timestamp, and compare the first current timestamp with a second current timestamp of the server's local clock based on a preset time window to obtain a second verification result; and a third verification module, used to confirm whether the client identity authentication result in the blockchain establishment permission response is consistent with the authentication signature in the identity authentication request to obtain a third verification result.

[0023] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the controller authentication-based encrypted tunnel establishment method described above.

[0024] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the controller authentication-based encrypted tunnel establishment method described above.

[0025] According to another aspect of the present invention, a computer program product is also provided, including computer instructions, wherein when the computer instructions are executed by a processor, they implement the steps of the controller authentication-based encrypted tunnel establishment method described in any one of the preceding embodiments.

[0026] This invention proposes a method for establishing an encrypted tunnel based on controller authentication. First, after the encrypted tunnel establishment process is initiated, the client device sends a security negotiation request to the server device, and the server device returns a security negotiation response. The security negotiation request carries encryption algorithm materials, and the security negotiation response includes initial key materials generated based on the encryption algorithm materials. Then, upon receiving the security negotiation response, the client device sends an authentication request to the server device and a chain-building permission request to the controller. The authentication request carries the client device identifier and authentication signature, and the chain-building permission request carries at least the client device identifier. The controller then generates a chain-building permission response based on the chain-building permission request and synchronizes it to the server device. The chain-building permission response includes the client authentication result and the real-time session authentication result. Finally, the server device verifies the authentication signature in the chain-building permission response and the authentication request. If all verifications are successful, an encrypted communication tunnel is established between the server device and the client device based on the authentication request.

[0027] This invention employs a parallel dual-track authentication method, integrating dynamic identity verification and real-time session authorization to comprehensively enhance the security and reliability of the encrypted tunnel establishment process. This achieves the technical effect of dynamically and in real-time defending against various attacks and ensuring stable and reliable tunnel connections. Furthermore, it solves the technical problem in related technologies where the encrypted tunnel establishment process relies on static authorization detection, which cannot cover real-time dynamic attacks and leads to insufficient security.

[0028] Specifically, this invention introduces an SD-WAN controller as a third-party authentication mechanism. At the beginning of the encrypted tunnel establishment process, a basic key material for protecting subsequent identity verification interactions is generated through standard security negotiation between the client and the server, further enhancing the device access threshold. When the client sends an identity authentication request, it initiates a chain-building permission request to the controller. The controller needs to perform dual verification of the device's registration status and real-time permissions. After confirming its legitimacy, it generates and issues a chain-building permission response to the server, ensuring that each tunnel establishment is an authorization for the currently legitimate device. After receiving the permission response, the server device performs multi-layered security audits of the client's request through digital signature verification, timestamp freshness checks, and device identifier consistency confirmation. Only when all verification steps are completed without error will the encrypted tunnel be formally established based on the client's identity authentication request, achieving highly dynamic and fine-grained tunnel access control.

[0029] The above mechanism effectively fills the gap in the existing technology where the encrypted tunnel establishment process relies on static authorization detection, overcomes the shortcomings of being unable to respond to real-time dynamic attacks in a timely manner, ensure the legitimacy of devices and the freshness of sessions, and greatly improves the level of network security protection. In particular, in the ever-changing distributed network environment, it provides a more robust barrier for data transmission encryption and solves the key technical problem of insufficient security caused by static authorization detection mechanism in related technologies. Attached Figure Description

[0030] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0031] Figure 1 This is a flowchart of an optional encrypted tunnel establishment method based on controller authentication according to an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram of an optional network architecture according to an embodiment of the present invention;

[0033] Figure 3 This is a schematic diagram of an optional controller authentication-based encrypted tunnel establishment device according to an embodiment of the present invention;

[0034] Figure 4 This is a structural block diagram of an electronic device for performing a controller authentication-based encrypted tunnel establishment method according to an embodiment of the present invention. Detailed Implementation

[0035] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0036] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0037] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0038] SD-WAN, Software Defined Wide Area Network, is a network technology that allows enterprises to optimize and manage the performance and resources of their wide area networks through a centralized controller. It can flexibly select the best path and adjust bandwidth allocation to improve network efficiency and reliability.

[0039] IPSec, or Internet Protocol Security, is a protocol used to provide secure packet delivery in Internet Protocol (IP) networks. It includes a range of technologies such as encryption, authentication, and key management to ensure the security and privacy of data transmission.

[0040] IKEv2, Internet Key Exchange version 2, is a protocol in the IPSec framework for key management and establishing security associations (SAs). It is responsible for all the key materials required to establish and manage a secure connection between two communication nodes.

[0041] Diffie-Hellman key exchange is a protocol that allows two parties to generate a shared key over an insecure channel. This shared key can then be used to encrypt and decrypt data, and it remains unobtainable even if a third party intercepts all transmitted data.

[0042] A nonce is a number or string that is used only once in a single transaction or session to ensure the uniqueness of an encrypted session and prevent replay attacks.

[0043] Digital signatures are a cryptographic technique used to verify the origin and integrity of digital messages or documents. They are typically implemented by encrypting the hash value of the data using the sender's private key.

[0044] SA, Security Association, created by IKEv2, defines the rules for secure communication between two nodes, including encryption and authentication algorithms, keys, and other security parameters.

[0045] Child SA is a type of SA in IPSec, which is established under IKE SA (Internet Key Exchange Security Association) between two nodes to encrypt and authenticate actual data packets.

[0046] The controller is a core management component in an SD-WAN environment. It is responsible for network configuration, policy enforcement, and dynamic verification of device identities. It is a third-party authentication authority introduced in the tunnel establishment process.

[0047] CPE, Customer Premises Equipment, refers to the network equipment at the customer's location. It can be a client-side or server-side device, responsible for interacting with the SD-WAN controller and performing tunnel establishment and data forwarding tasks.

[0048] TLS, Transport Layer Security, is a security protocol used to encrypt communications over the Internet, ensuring the privacy and integrity of data during network transmission.

[0049] PRF, or Pseudorandom Function, is a function whose output appears random but is actually determined by the key and input parameters. It is often used for key derivation.

[0050] The following embodiments of the present invention can be applied to various systems / applications / devices requiring dynamic authentication and real-time session authorization, enabling encrypted tunnel establishment technology based on SD-WAN controller authentication. The present invention uses a parallel dual-track authentication process for secure real-time communication between the client and server. The SD-WAN controller then verifies the registration status of the client device and generates a real-time session authentication result, which better ensures the security and legitimacy of the tunnel connection. Especially in distributed network environments, it strengthens identity management and communication security for network edge devices.

[0051] In practical implementation, this invention first initiates the encrypted tunnel establishment process by sending a security negotiation request carrying encryption algorithm materials to the server device. The server device generates initial key materials based on the request and returns a security negotiation response, ensuring a basic secure communication channel. Subsequently, upon receiving the server's security negotiation response, the client device immediately sends an authentication request to the server device and a chain establishment permission request to the SD-WAN controller. These request processes are performed in parallel, improving efficiency. Next, the SD-WAN controller generates a chain establishment permission response based on the client device's chain establishment permission request, which includes the client's authentication result and the real-time session authentication result, and synchronizes it to the server device, adding a dynamic factor to tunnel establishment. Finally, the server device verifies the authentication signature in the chain establishment permission response and the authentication request. Upon successful verification, an encrypted tunnel is established between the client and the server based on the authentication request and the real-time authorization result, ensuring that each communication is established based on the latest and most legitimate authentication, significantly enhancing network communication security.

[0052] This invention introduces an SD-WAN controller as a third-party authentication authority, avoiding the security risks of traditional static authorization detection mechanisms. It also overcomes the communication insecurity caused by the inability to verify device identity and session freshness in real time, significantly improving the dynamic security and fine-grained control capabilities of the encrypted tunnel establishment process. It is not only suitable for the secure communication needs of enterprise wide area network environments, but also provides solid security for cloud services, multi-branch networks, and remote access scenarios.

[0053] The present invention will now be described in detail with reference to various embodiments.

[0054] Example 1

[0055] According to an embodiment of the present invention, an embodiment of an encrypted tunnel establishment method based on controller authentication is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0056] The implementation of this invention can be based on an SD-WAN-based wide area network system, combining dynamic authentication and real-time session authorization technologies for the establishment of encrypted communication tunnels. Specifically, it addresses the issues of dynamic identity verification and legitimacy confirmation during tunnel establishment. Through a parallel dual-track authentication process—specifically, the parallel steps of standard security negotiation between the client and server and the client initiating a connection establishment permission request to the controller—it enhances the security and trustworthiness of encrypted tunnel connections. Applicable to enterprise-level distributed networks and remote office environments, it helps prevent the access of unauthorized or cross-domain devices, ensuring that each tunnel establishment is based on the latest dynamic authorization, thereby significantly improving the security level and compliance control of network communication.

[0057] The embodiments of the present invention will now be described in detail with reference to the specific implementation steps.

[0058] Figure 1 This is a flowchart of an optional controller authentication-based encrypted tunnel establishment method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes steps S101 to S104, with the starting point of the step execution being the initiation of the encrypted tunnel establishment process.

[0059] Figure 2 This is a schematic diagram of an optional network architecture according to an embodiment of the present invention. Figure 2 As shown, an SD-WAN controller sits at the top of the architecture, connected to network domains on both sides via the internet. In the left network domain, the server accesses the internet through a CPE device; in the right network domain, the client also accesses the internet through a CPE device. This architecture depicts the basic connection relationship where the controller centrally manages both the server and client via a public network, providing the underlying support for establishing an encrypted tunnel between them.

[0060] For example, an SD-WAN network environment consists of an SD-WAN controller and multiple sites. Each site includes an IPSec client CPE device and a corresponding IPSec server CPE device. The IPSec client CPE device exchanges device registration information and connection establishment permission with the controller through a secure control channel; the IPSec client CPE device initiates IKE negotiation with the IPSec server CPE device to establish an encrypted tunnel.

[0061] Optionally, before the encrypted tunnel establishment process begins, the process further includes: the controller sending server-side runtime configuration information to the server device through a pre-agreed encrypted management channel, wherein the server-side runtime configuration information includes: listening port parameters, encryption algorithm priority information, shared key exchange algorithm parameter set, and control identifier; after receiving the server-side runtime configuration information, the server device loads a daemon process based on the listening port parameters, and in the daemon process starts a device authentication program based on the control identifier, starts a listening program based on the listening port parameters, creates a secure association database based on the encryption algorithm priority information, and generates a server local key based on the shared key exchange algorithm parameter set.

[0062] It should be noted that the initial configuration between the controller and the server device before the encrypted tunnel establishment process begins forms the basis for all subsequent steps. The pre-agreed encrypted management channel refers to a secure control channel established via TLS encryption, whose purpose is to ensure that all configuration information issued by the controller is not eavesdropped on or tampered with during transmission.

[0063] The server-side configuration information issued by the controller includes several key parameters. Among these, the listening port parameter can be explicitly specified as UDP / 500 and UDP / 4500 ports; the former is the standard negotiation port for the IKEv2 protocol, while the latter is used to handle communication during network address translation. The encryption algorithm priority information refers to an ordered list of algorithms, such as AES-GCM and SHA-256, arranged by priority for both parties to choose from during negotiation to create a unified security environment. The shared key exchange algorithm parameter set specifically refers to the group parameters used in Diffie-Hellman key exchange, which determine the strength and basis of the key exchange. The control identifier is a switch parameter; in this embodiment, its core meaning is to enable device authentication, informing the server that subsequent enhanced security verification processes need to be activated.

[0064] Furthermore, after receiving and parsing this configuration information, the server-side device performs a series of initialization operations. Among these, loading the daemon refers to starting the IKEv2 protocol daemon in the system's kernel space, serving as the core engine for handling all IKE negotiation requests. The device authentication program started based on the control identifier is not a separate program, but rather refers to enabling an additional logic module within the IKE daemon process. This module provides a service outside the standard process of waiting for and verifying the chain-building permission issued by the controller. Starting the listening program means that the aforementioned daemon process enters a listening state on the specified UDP / 500 and UDP / 4500 ports, ready to receive connection requests from clients.

[0065] Creating a secure association database is a standard operation of the IKEv2 protocol stack. This database stores and manages the state information of all active secure association sessions. The rules for its creation and the range of available algorithms are determined by the previously issued encryption algorithm priority information. Finally, generating the server-local key involves the server generating a temporary asymmetric key pair based on the Diffie-Hellman parameter set in the configuration. The public key will be used for the first phase of secure key material exchange with the client.

[0066] The above pre-configuration steps implement a dynamic authorization mechanism of the SD-WAN controller embedded in the standard IPSec tunnel establishment process. The fundamental purpose is to realize real-time verification of the identity of devices attempting to establish a connection, ensuring that only legitimate devices successfully registered in the controller domain can ultimately complete the tunnel establishment. This effectively solves the security risks of unauthorized devices using static credentials to bypass security checks in traditional solutions, thereby greatly improving the security and controllability of the network access process.

[0067] In one specific implementation, the SD-WAN controller first sends complete IPSec server runtime parameters to the server via a TLS encrypted management channel established with the IPSec server CPE (hereinafter referred to as the Server). These parameters include not only the local IKEv2 listening port, cipher suite priority, and Diffie-Hellman group parameters, but also the "Enable Device Authentication" control flag. After receiving and verifying this configuration, the Server loads the IKEv2 daemon in the kernel space, creates a Security Association database, and starts listening on UDP / 500 and UDP / 4500 ports to capture subsequent IKE_SA_INIT requests. At this point, the Server is ready to conduct standard IKEv2 Phase 1 negotiation, generating initial key material based on the Diffie-Hellman key exchange and nonce exchange mechanism.

[0068] Furthermore, before the encrypted tunnel establishment process is initiated, the process includes: the controller sending client operation configuration information to the client device through a pre-agreed encrypted management channel. The client operation configuration information includes: security protocol parameters, shared key exchange algorithm parameter set, security policy, and network configuration parameters. After receiving the client operation configuration information, the client device generates an instantiated protocol stack based on the security protocol parameters, security policy, and network configuration parameters, and generates a client local key based on the shared key exchange algorithm parameter set.

[0069] It should be noted that, in another optional embodiment, while or after the controller sends the configuration to the server through the TLS encrypted management channel, it can also send the client running configuration information to the client device in parallel, to ensure that the client has obtained all the necessary parameters before initiating the connection and can construct a connection request that complies with the controller's security policy.

[0070] Specifically, the client configuration information includes several core components: security protocol parameters, which explicitly specify the use of the IKEv2 protocol as the standard for tunnel negotiation and specify the specific algorithms required for the protocol to run, such as algorithms for encryption (e.g., AES-GCM), algorithms for integrity verification (e.g., SHA-256), and pseudo-random functions (PRF) for key derivation. The shared key exchange algorithm parameter set needs to be consistent with the server configuration; here, it also refers to the group parameters for Diffie-Hellman key exchange. It should be noted that the client needs to use the same group as the server to successfully compute a consistent shared key. The security policy defines the rules for the connection, such as the types of tunnels allowed, the characteristics of the data streams that need to be protected, and whether to enable parallel controller authentication processes (i.e., subsequent ChainAuthRequests to the controller). Network configuration parameters, as basic connection information, mainly include the IP address or domain name of the target server device, so that the client knows where to initiate the IKE negotiation request.

[0071] After successfully receiving and parsing this configuration information, the client device will immediately perform two core operations:

[0072] Generating an instantiated protocol stack refers to the process by which the client software creates and initializes a complete IKEv2 protocol stack instance in memory based on the aforementioned security protocol parameters, security policies, and network configuration parameters. It should be noted that this protocol stack instance is a fully functional software module used to encapsulate all logic conforming to the IKEv2 standard for message processing, cryptographic calculations, and state management, preparing it for the subsequent tunnel establishment process.

[0073] Generate a client-local key: This refers to generating a temporary asymmetric key pair based on the Diffie-Hellman parameter set in the configuration. This temporary key serves as a temporary representation of the client's identity. The public key is sent to the server in a subsequent IKE_SA_INIT request for both parties to calculate the shared key.

[0074] The aforementioned pre-configuration and subsequent processes seamlessly embed a dynamic device identity authorization mechanism led by the SD-WAN controller within the standard IPSec IKEv2 tunnel negotiation framework. The fundamental purpose is to strictly limit tunnel establishment permissions to registered, legitimate devices within the same controller management domain. This completely resolves the significant security flaw in traditional solutions where unauthorized devices can bypass controller security boundaries and establish encrypted channels using valid static credentials (such as pre-shared keys or certificates). Ultimately, this achieves a comprehensive improvement in tunnel connection security, authentication binding, and operational traceability.

[0075] In one specific implementation, the SD-WAN controller also distributes the IPSec client configuration to the IPSec client CPE (hereinafter referred to as the Client) through the management channel. After parsing the configuration, the Client automatically instantiates the IKEv2 client protocol stack and sends the first negotiation message—an IKE_SA_INIT request—to the Server according to the standard procedure. In this request message, the Client sends the Initiator Nonce (Ni) generated by its local high-entropy pseudo-random number generator along with its own Diffie-Hellman public key, along with a list of encryption algorithms, pseudo-random functions (PRF), and message authentication code (MAC) algorithms. In this stage, the Server receives Ni and the public key, generates a shared key using its own private key, and returns an IKE_SA_INIT_RESP containing the Responder Nonce (Nr) and its own public key to complete the first stage of key negotiation and initial derivation of SKEYSEED.

[0076] Step S101: After the encrypted tunnel establishment process is started, the client device sends a security negotiation request to the server device, and the server device returns a security negotiation response. The security negotiation request carries encryption algorithm materials, and the security negotiation response includes: initial key materials generated based on the encryption algorithm materials.

[0077] Specifically, the above steps correspond to the first phase of negotiation in the IPSec tunnel establishment process, namely the IKE_SA_INIT exchange process. The security negotiation request is an IKE_SA_INIT request message sent by the client device (as the initiator) to the server device. This message carries cryptographic algorithm materials, including a Diffie-Hellman public key generated by the client, a high-entropy initiator random number, and a list of algorithm proposals consisting of client-supported cryptographic algorithms, pseudo-random functions, and integrity verification algorithms. Upon receiving this request, the server device selects a combination of algorithms supported by both parties from the algorithm list and calculates a shared key based on the Diffie-Hellman public key sent by the client and its own private key.

[0078] The security negotiation response is the IKE_SA_INIT response message returned by the server device. This response message contains initial key materials, which refer to a series of initial keys derived by the server from the exchanged Nonce value and Diffie-Hellman shared secret using a specified pseudo-random function. These keys form the basis for subsequent communication and specifically include a session key for generating other keys, an authentication key for protecting authentication messages between the initiator and responder, and a key for encrypting the Nonce. At this point, both parties have successfully established an IKE security association, preparing a protected channel for the second phase of identity authentication and sub-SA negotiation.

[0079] The above steps, by embedding the controller's dynamic authorization mechanism into the standard IPSec tunnel establishment process, achieve real-time and reliable verification of device identity, solving the security flaws of traditional solutions that rely on static credentials and cannot prevent unauthorized devices from impersonating legitimate credentials to establish tunnels. By introducing a secondary verification of device identity and session by the controller after the successful key negotiation in the first phase, it ensures that only legitimate devices under a specific management domain can successfully complete the entire tunnel establishment, ultimately enhancing connection security, binding, and traceability.

[0080] Furthermore, after the encrypted tunnel establishment process is initiated, the step of the client device sending a security negotiation request to the server device includes: the client device generating a first random number using a local random number generator; retrieving the client's public key from the client's local key, and packaging the first random number and the client's public key into a security negotiation request; retrieving the list of encryption algorithms to be negotiated, the list of message authentication code algorithms, and the pseudo-random function used for key derivation as encryption algorithm materials, and associating the encryption algorithm materials with the security negotiation request; and sending the associated security negotiation request and encryption algorithm materials to the server device.

[0081] It should be noted that after instantiating the IKEv2 protocol stack and generating the client's local key, the client device initiates the security negotiation. First, the client uses a local high-entropy pseudo-random number generator to generate an initiator nonce. Then, it retrieves the public key portion of the Diffie-Hellman key pair generated during the preparation phase, i.e., the client's public key. These two key pieces of data are packaged together to form the core payload of the security negotiation request.

[0082] Meanwhile, the client retrieves a series of cryptographic suite proposals from its configuration, collectively referred to as cryptographic algorithm materials. These include: a list of cryptographic algorithms, indicating the set of cryptographic algorithms supported by the client and their priority order, such as AES-GCM or AES-CBC, used for subsequent encryption of tunnel data; a list of message authentication code algorithms, indicating the set of integrity verification algorithms supported by the client, such as HMAC-SHA256 or HMAC-SHA384, used to ensure that data has not been tampered with during transmission; and a pseudo-random function for key derivation, used to securely derive various session keys actually used from the shared secret after key exchange.

[0083] The client associates this set of algorithm materials with the previously packaged core payload to form a complete IKE_SA_INIT request message, which is then sent to the server device.

[0084] The first random number serves two core functions: first, it ensures the freshness of the key, guaranteeing that each session key generated through negotiation is unique, effectively preventing replay attacks; second, it serves as a seed for key derivation, and together with the random number returned by the server and the shared secret generated by the Diffie-Hellman exchange, it is used by the pseudo-random function to calculate the final protection key.

[0085] The purpose of client-side public key exchange is to perform secure Diffie-Hellman key exchange. The client sends its public key to the server, which then uses its private key to perform calculations. Both parties can independently derive the same shared secret without revealing their individual private keys. This shared secret is the fundamental source for generating all subsequent encryption and authentication keys, achieving forward secrecy.

[0086] Additionally, after the client sends the IKE_SA_INIT request, it can wait for and process the server's response. The server will return an IKE_SA_INIT response message, which contains the algorithm suite selected by the server, its own Diffie-Hellman public key, and a random number. Upon receiving the response, the client uses this information to complete the first phase of key material derivation. Furthermore, if this phase of negotiation fails, the entire tunnel establishment process will be aborted without degrading to an insecure connection method.

[0087] The above steps, in the initial stage of IPSec tunnel establishment, establish a protected and verifiable channel (IKE SA) for subsequent communication through standard and secure cryptographic exchanges, and lay a solid foundation for the introduction of a dynamic authorization mechanism by the controller. The purpose is to ensure that even subsequent authorization information (such as chain establishment permission) needs to be transmitted in an encrypted channel, thereby achieving end-to-end security throughout the entire process, and ultimately enabling only authorized devices to successfully establish a tunnel.

[0088] Further, the steps for the server device to return a security negotiation response include: the server device parsing the security negotiation request and encryption algorithm materials, and calling a local random number generator to generate a second random number; retrieving the server's public key and private key from the server's local keys, and performing encryption operations based on the server's private key and the client's public key to generate a shared key; determining the target encryption algorithm from the list of encryption algorithms to be negotiated, obtaining a first-type algorithm identifier, and determining the target message authentication code algorithm from the list of message authentication code algorithms, obtaining a second-type algorithm identifier; performing key derivation operations based on the target encryption algorithm, a pseudo-random function, and the shared key to obtain a derived key set; and packaging the second random number, the server's public key, the first-type algorithm identifier, the second-type algorithm identifier, and the derived key set into a security negotiation response and returning it to the client device.

[0089] The above steps describe in detail the complete process by which the server device processes the IKE_SA_INIT request sent by the client and generates a response. After receiving the security negotiation request, the server first parses the encryption algorithm material, including the list of encryption algorithms supported by the client, the list of message authentication code algorithms, and the pseudo-random function proposal. Then, it calls the local high-entropy pseudo-random number generator to generate a second random number (Responder Nonce). Its core function is similar to the client's first random number, mainly used to ensure the freshness of the key. Together with the first random number, it serves as a seed in subsequent key derivation operations to prevent replay attacks.

[0090] Subsequently, the server retrieves the local key pair generated during the preparation phase, which includes the server's public key and private key. The shared key operation is based on the Diffie-Hellman key exchange protocol. The server uses its own private key and the client's public key carried in the client's request to perform mathematical operations, thereby independently deriving a shared secret known only to the two communicating parties, which serves as the basis for all subsequent key materials.

[0091] Furthermore, regarding algorithm selection, the server chooses a combination from the negotiation list provided by the client that it also supports and has the highest priority. This combination is designated as the target encryption algorithm (e.g., AES-GCM) and the target message authentication code algorithm (e.g., HMAC-SHA256). The message authentication code algorithm is a cryptographic tool used to verify data integrity and authenticity. The resulting first and second algorithm identifiers are essentially used to explicitly inform the client in the response message which algorithm will be used for communication in this session.

[0092] Furthermore, key derivation refers to using a pseudo-random function agreed upon by both parties, taking the shared secret, the client's first random number, and the server's second random number as inputs, to ultimately derive a specific set of derived keys, including encryption keys and authentication keys used to protect subsequent authentication messages. Finally, the server packages the second random number, its own public key, the selected algorithm identifier, and the derived initial key materials into an IKE_SA_INIT response message and returns it to the client.

[0093] The above steps securely complete the first phase of IKEv2 negotiation through rigorous cryptographic exchanges, establish a protected channel (IKE SA), and prepare an encrypted and authenticated communication foundation for the subsequent dynamic authorization process of the embedded controller. The purpose is to ensure that the entire authentication and tunneling process, including critical control commands, is carried out in a secure context, thereby achieving the final device identity binding and anti-spoofing access.

[0094] In one optional embodiment, after receiving the IKE_SA_INIT request from the Client, the Server's IKE processing module generates SKEYSEED based on the Diffie-Hellman group parameters and Nonce value negotiated by both parties, and further derives the key materials (SK_d, SK_ai, SK_ar, SK_ei, SK_er) used in the first phase through the specified PRF. After generating the necessary initial keys, the Server constructs an IKE_SA_INIT response message (i.e., a security negotiation response), including its own Nonce, Responder SPI, and the identifier of the selected encryption and MAC algorithms, and then sends it back to the Client. At this point, both parties have established a secure channel for protecting the IKE_AUTH message and enter the preparation for the second phase of identity authentication and sub-SA negotiation.

[0095] In step S102, after receiving the security negotiation response, the client device sends an authentication request to the server device and a chain establishment permission request to the controller. The authentication request carries the client device identifier and the authentication signature, and the chain establishment permission request carries at least the client device identifier.

[0096] It should be noted that step S102 describes a parallel processing phase, namely, in the second phase (IKE_AUTH) of the IKEv2 protocol, the client device simultaneously initiates two independent but logically related requests.

[0097] The authentication request is a component of the IKE_AUTH request message in the standard IKEv2 protocol. It is sent to the server device through the encrypted channel established in step S101 (protected by a set of derived keys). The client device identifier (i.e., device_id) is a unique identifier assigned when the device registers with the controller, used to clearly distinguish different devices within the controller domain. The authentication signature is a credential used to prove the legitimacy of the client device to the server. Depending on the pre-configuration, it can be a signature based on an X.509 certificate or a message authentication code generated using a pre-shared key. Its purpose is to complete peer authentication in the IKEv2 standard process.

[0098] The ChainAuthRequest is a new interaction independent of the IPSec / IKE protocol. The client device sends a request (ChainAuthRequest) to the SD-WAN controller via a pre-established, independent TLS management channel. The ChainAuthRequest carries at least the client device identifier (device_id) and an identifier strongly bound to the current IKE session, namely the Initiator Nonce (Ni). Ni's role is to associate this controller authorization request with a specific, ongoing IKE session.

[0099] The aforementioned parallel design aims to address the core issue of the lack of real-time, dynamic authorization verification of whether a device belongs to a legitimate management domain during the establishment of traditional IPSec tunnels. In existing technologies, even if a device possesses the correct pre-shared key or certificate (i.e., can pass the "authentication request"), it cannot be guaranteed that the device is authorized for access by the current controller. For example, an obsolete device with valid credentials, or a malicious device that has stolen credentials, can still successfully establish a tunnel.

[0100] This embodiment introduces parallel chain-building permission requests, delegating the final verification authority for device identity to a centralized controller. The controller, based on a global perspective, determines whether the device corresponding to the given device_id is still registered, online, and compliant, thereby deciding whether to issue a chain-building permission.

[0101] Furthermore, upon receiving the security negotiation response, the steps of the client device sending an authentication request to the server device and simultaneously sending a blockchain establishment permission request to the controller include: parsing the security negotiation response; performing encryption operations based on the server's public key and the client's private key to obtain a shared key; and storing the shared key along with a first-type algorithm identifier, a second-type algorithm identifier, and a derived key set; obtaining the client device identifier; generating an authentication signature based on the client's private key; encrypting the client device identifier and the authentication signature using the shared key to generate an authentication request; and sending the authentication request to the server device; and constructing a blockchain establishment permission request based on a first random number and the client device identifier, and sending the blockchain establishment permission request to the controller through a pre-agreed encryption management channel.

[0102] In one optional embodiment, after receiving the IKE_SA_INIT_RESP from the server, the client immediately enters the second phase of parallel interaction. Within the same Protected Payload channel, the client first constructs and sends an IKE_AUTH request message to the server, containing the device identifier (device_id) and its corresponding signature, to complete the certificate chain or pre-shared key verification of the client's identity. Simultaneously, the client's controller communication module initiates a ChainAuthRequest to the SD-WAN controller through a separate TLS management channel. This request only carries the Ni and device_id bound to the IKE session, requesting the controller to generate a chain establishment permission for this session. Although both are independent at the transport layer, they are logically synchronous, thus ensuring no order dependency and improving overall negotiation efficiency.

[0103] It should be noted that after successfully receiving and parsing the security negotiation response (IKE_SA_INIT response) returned by the server, the client first performs the same Diffie-Hellman key exchange operation as the server, based on the server's public key carried in the response and its own private key generated during the preparation phase, independently deriving the same shared key. Subsequently, the client securely stores this shared key along with the target encryption algorithm (first-type algorithm identifier), the target message authentication code algorithm (second-type algorithm identifier), and the initially derived key set selected by the server. Together, these form the encryption context for subsequent communication, preparing a protected channel for the upcoming authentication phase.

[0104] Next, the client begins constructing two core requests in parallel. The first is an authentication request (i.e., an IKE_AUTH request) sent to the server. The client first obtains a unique client device identifier, then uses its private key (usually the private key corresponding to an X.509 certificate) to sign specific data, generating an authentication signature to prove its authenticity. Finally, the client uses an encryption context (specifically, the derived encryption key and authentication algorithm) to encrypt and protect the device identifier and authentication signature, encapsulating them into a standard IKE_AUTH request message, which is then sent to the server via the IPSec channel.

[0105] Simultaneously, the client initiates a second crucial parallel operation: constructing and sending a ChainAuthRequest. This request contains two elements: a client device identifier to uniquely identify the device, and a first random number to uniquely identify the current IKE session. The client sends this request directly to the SD-WAN controller via a separate, secure TLS-encrypted management channel, requesting the controller to authorize this chain establishment.

[0106] In step S103, the controller generates a blockchain establishment permission response based on the blockchain establishment permission request and synchronizes it to the server device. The blockchain establishment permission response includes the client identity authentication result and the session real-time authentication result.

[0107] Further, the step of the controller generating a blockchain authorization response based on the blockchain authorization request and synchronizing it to the server device includes: upon receiving the blockchain authorization request, the controller searches in the registration domain based on the client device identifier to obtain the search result, wherein the registration domain is used to record pre-registered qualified devices; if the search result indicates that the registration domain contains the client device identifier, the client identity authentication result is set to authentication passed; if the search result indicates that the registration domain does not contain the client device identifier, the client identity authentication result is set to authentication failed; a session real-time authentication result is generated based on a first random number and a first current timestamp; the client identity authentication result and the session real-time authentication result are packaged into a blockchain authorization response, and a digital signature of the blockchain authorization response is generated; the blockchain authorization response is sent to the server device through a pre-agreed encrypted management channel.

[0108] In one optional embodiment, after receiving the ChainAuthRequest, the SD-WAN controller's authorization management unit first performs an identity query on the device_id to confirm that the device is registered in the controller's domain. Subsequently, the license generation unit uses the current system timestamp, Ni, and device_id as inputs to generate a ChainAuthResponse using a specified digital signature algorithm (such as ECDSA or RSA). The dual binding of the timestamp and random number ensures message freshness and session consistency. This signed response is returned to the Client through the management channel and synchronized to the Server via Client relay or direct controller connection, allowing the Server to perform unified verification locally.

[0109] It should be noted that upon receiving a connection establishment permission request from the client via an independent TLS management channel, the controller's authorization management unit is activated, initiating a rigorous verification and response generation process. The core of this process involves performing two key verification steps: device identity verification and session real-time verification.

[0110] First, the controller extracts the client device identifier from the request and performs a precise search in its maintained device registration domain database. The registration domain is a pre-configured security list that records all authorized device identifiers connected to the controller's managed network. The search result directly determines the client's authentication outcome: if the identifier exists in the registration domain, authentication is successful, indicating the device is "one of our own"; if it does not exist, authentication fails, and the controller considers it an unauthorized device.

[0111] Next, the controller performs real-time session verification to defend against replay attacks. It obtains the current system time to generate a first current timestamp and binds this timestamp to a first random number uniquely associated with this IKE session, carried in the chain-building permission request. Together, they constitute the real-time session authentication result. This mechanism ensures that the issued permission is temporarily generated for this specific session, possessing timeliness and uniqueness.

[0112] Subsequently, the controller packages the client authentication results and the real-time session authentication results to form a complete blockchain establishment permission response. To ensure that this response cannot be tampered with or forged during transmission to the server, the controller generates a digital signature on the response data using its private key.

[0113] Finally, the controller sends a digitally signed chain-building permission response to the server device through a separate, pre-established TLS encrypted management channel. The server maintains a waiting state in the IKE session until it receives this response and will not proceed with the final tunnel establishment. After generating and sending the response, the controller records a complete audit log, including but not limited to device identifier, timestamp, random number, authentication result, and signature information, aiming to provide the system with strong traceability and facilitate subsequent security audits and troubleshooting.

[0114] This invention binds the IPSec tunnel establishment permission to a dynamic and traceable authorization policy through the centralized decision-making and signature authorization mechanism of the controller. The purpose is to solve the security defects of traditional solutions that rely solely on static pre-shared keys or certificates and cannot reflect changes in device authorization status in real time. This ensures that only devices currently registered in the controller's domain and in a legitimate state can successfully establish an encrypted tunnel, thereby constructing a dynamic and reliable network access boundary.

[0115] In step S104, the server device verifies the authentication signature in the chain establishment permission response and the identity authentication request. If all verifications are successful, an encrypted communication tunnel is established between the server device and the client device based on the identity authentication request.

[0116] Furthermore, the step of verifying the authentication signature in the blockchain establishment permission response and the identity authentication request by the server-side device includes: parsing the digital signature of the blockchain establishment permission response and verifying the integrity of the digital signature to obtain a first verification result; parsing the session real-time authentication result in the blockchain establishment permission response to obtain a first current timestamp, comparing the first current timestamp with the second current timestamp of the server's local clock based on a preset time window to obtain a second verification result; and confirming whether the identity information is consistent between the client identity authentication result in the blockchain establishment permission response and the authentication signature in the identity authentication request to obtain a third verification result.

[0117] In one optional implementation, upon receiving the ChainAuthResponse, the Server's permission verification module first verifies the integrity of the signature using the public key issued by the controller. Next, the Server compares the timestamp with the local clock to confirm the valid time window of the certificate response. Subsequently, the Server precisely matches the Ni in the ChainAuthResponse with the Initiator Nonce received in the first phase to ensure that this permission corresponds to the same IKE_SA_INIT negotiation. Finally, the Server confirms that the device_id matches the identity information in the previous IKE_AUTH message. After all verifications pass, the Server constructs and sends an IKE_CHILD_SA_INIT message based on the derived first-phase key, using the negotiated child SA algorithm, completing the key exchange and security association establishment for the Child SA, and ultimately deploying the IPSec tunnel. If no valid permission is received within the timeout period specified by the controller, or if any verification fails, the Server immediately terminates the current IKE instance and clears the relevant session entries from the SA database to ensure no security vulnerabilities remain.

[0118] It should be noted that the server-side device, as the final arbiter of the entire authentication process, performs a series of rigorous verification operations to decide whether to establish an encrypted tunnel. The server-side device first verifies the received blockchain establishment permission response, using the public key in the controller's publicly disclosed digital certificate to parse and verify the digital signature attached to the response, confirming that the response indeed comes from a trusted controller and has not been tampered with during transmission, thus obtaining the first verification result regarding the authenticity and integrity of the response.

[0119] Subsequently, the server parses the session real-time authentication result in the response body, extracts the first current timestamp when the controller issued the response, compares this timestamp with the second current timestamp generated by its own local clock, and checks whether it falls within a preset reasonable time window to defend against replay attacks. This ensures that the received connection permission is newly generated for this session and not old data replayed by the attacker, thus obtaining a second verification result regarding the timeliness of the response.

[0120] After verifying the controller's response, the server will also associate the client authentication result (i.e. whether the device is in the registered domain) given by the controller in the chain establishment permission response with the authentication signature generated by the client's private key parsed from the IKE_AUTH request. This is to ensure that the device undergoing cryptographic authentication is the same entity as the device authorized by the controller, thereby obtaining a third verification result regarding the consistency of the device's identity.

[0121] The server device will only confirm that the client is a legitimate and authorized device if and only if all three verification results are successful. At this point, the server will continue the standard IKEv2 process based on the parameters and keys negotiated in the previous IKE_SA_INIT phase, construct and send the IKE_CHILD_SA_INIT message, and finally establish an encrypted communication tunnel with the server device.

[0122] Additionally, the server can be configured with a timeout mechanism. After sending the IKE_SA_INIT response, the server starts a timer to wait for the controller's chain establishment permission response. If no response is received within the preset timeout period or any of the above verifications fails, the server will immediately terminate the current IKE session instance and clear all temporary states from the security association database, ensuring that no semi-open connection vulnerabilities remain.

[0123] This embodiment achieves dynamic, real-time, and reliable binding of device identity and tunnel establishment permissions through mandatory dual verification of controller authorization results and client identity credentials by the server. The aim is to completely solve the security risks caused by the lag in authorization status updates in traditional static credential authentication schemes, and ensure that the establishment of each tunnel connection strictly follows the latest security policy of the controller, thereby ultimately building an advanced security network boundary that can resist device spoofing and credential misuse.

[0124] Through steps S101 to S104 above, after the encrypted tunnel establishment process is initiated, the client device sends a security negotiation request to the server device, and the server device returns a security negotiation response. The security negotiation request carries encryption algorithm materials, and the security negotiation response includes initial key materials generated based on the encryption algorithm materials. After receiving the security negotiation response, the client device sends an authentication request to the server device and a chain establishment permission request to the controller. The authentication request carries the client device identifier and authentication signature, and the chain establishment permission request carries at least the client device identifier. Then, the controller generates a chain establishment permission response based on the chain establishment permission request and synchronizes it to the server device. The chain establishment permission response includes the client authentication result and the session real-time authentication result. Finally, the server device verifies the authentication signature in the chain establishment permission response and the authentication request. If all verifications are successful, an encrypted communication tunnel between the server device and the client device is established based on the authentication request.

[0125] In this embodiment of the invention, a parallel dual-track authentication method is adopted. By integrating dynamic identity verification and real-time session authorization, the security and reliability of the encrypted tunnel establishment process are comprehensively improved. This achieves the technical effect of dynamically and in real-time defending against various attacks and ensuring the stable and reliable tunnel connection. It also solves the technical problem in related technologies where the encrypted tunnel establishment process relies on static authorization detection, which cannot cover real-time dynamic attacks and leads to insufficient security.

[0126] Specifically, this embodiment of the invention introduces an SD-WAN controller as a third-party authentication mechanism. At the beginning of the encrypted tunnel establishment process, a basic key material for protecting subsequent identity verification interactions is generated through standard security negotiation between the client and the server, further enhancing the device access threshold. When the client sends an identity authentication request, it initiates a chain establishment permission request to the controller. The controller needs to perform dual verification of the device's registration status and real-time permissions. After confirming its legitimacy, it generates and issues a chain establishment permission response to the server, ensuring that each tunnel establishment is an authorization for the currently legitimate device. After receiving the permission response, the server device performs multi-layered security audits of the client's request through digital signature verification, timestamp freshness checks, and device identifier consistency confirmation. Only when all verification steps are completed without error will the encrypted tunnel be formally established based on the client's identity authentication request, achieving highly dynamic and fine-grained tunnel access control.

[0127] The above mechanism effectively fills the gap in the existing technology where the encrypted tunnel establishment process relies on static authorization detection, overcomes the shortcomings of being unable to respond to real-time dynamic attacks in a timely manner, ensure the legitimacy of devices and the freshness of sessions, and greatly improves the level of network security protection. In particular, in the ever-changing distributed network environment, it provides a more robust barrier for data transmission encryption and solves the key technical problem of insufficient security caused by static authorization detection mechanism in related technologies.

[0128] The invention will now be described in conjunction with another alternative embodiment.

[0129] Example 2

[0130] The encrypted tunnel establishment device based on controller authentication provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above.

[0131] Figure 3 This is a schematic diagram of an optional controller-authentication-based encrypted tunnel establishment device according to an embodiment of the present invention, such as... Figure 3 As shown, the device is applied to a target network environment that includes a controller, a server device, and a client device. The encrypted tunnel establishment device may include: a first sending unit 31, a second sending unit 32, a generation unit 33, and an establishment unit 34.

[0132] The first sending unit 31 is used to send a security negotiation request from the client device to the server device after the encrypted tunnel establishment process is started, and the server device returns a security negotiation response. The security negotiation request carries encryption algorithm materials, and the security negotiation response includes: initial key materials generated based on the encryption algorithm materials.

[0133] The second sending unit 32 is used to send an authentication request from the client device to the server device and a chain establishment permission request to the controller after receiving the security negotiation response. The authentication request carries the client device identifier and the authentication signature, and the chain establishment permission request carries at least the client device identifier.

[0134] The generation unit 33 is used by the controller to generate a chain-building permission response based on the chain-building permission request and synchronize it to the server device. The chain-building permission response includes the client identity authentication result and the session real-time authentication result.

[0135] Establishment unit 34 is used for the server device to verify the authentication signature in the chain establishment permission response and identity authentication request. If all verifications are successful, an encrypted communication tunnel is established between the server device and the client device based on the identity authentication request.

[0136] The aforementioned encrypted tunnel establishment device based on controller authentication can first send a security negotiation request from the client device to the server device after the encrypted tunnel establishment process is initiated via the first sending unit 31, and the server device returns a security negotiation response. The security negotiation request carries encryption algorithm materials, and the security negotiation response includes initial key materials generated based on the encryption algorithm materials. After receiving the security negotiation response via the second sending unit 32, the client device sends an identity authentication request to the server device and a chain establishment permission request to the controller. The identity authentication request carries the client device identifier and identity authentication signature, and the chain establishment permission request carries at least the client device identifier. Then, the controller generates a chain establishment permission response based on the chain establishment permission request via the generation unit 33 and synchronizes it to the server device. The chain establishment permission response includes the client identity authentication result and the session real-time authentication result. Finally, the server device verifies the authentication signature in the chain establishment permission response and the identity authentication request via the establishment unit 34. If all verifications are successful, an encrypted communication tunnel between the server device and the client device is established based on the identity authentication request.

[0137] In this embodiment of the invention, a parallel dual-track authentication method is adopted. By integrating dynamic identity verification and real-time session authorization, the security and reliability of the encrypted tunnel establishment process are comprehensively improved. This achieves the technical effect of dynamically and in real-time defending against various attacks and ensuring the stable and reliable tunnel connection. It also solves the technical problem in related technologies where the encrypted tunnel establishment process relies on static authorization detection, which cannot cover real-time dynamic attacks and leads to insufficient security.

[0138] Specifically, this embodiment of the invention introduces an SD-WAN controller as a third-party authentication mechanism. At the beginning of the encrypted tunnel establishment process, a basic key material for protecting subsequent identity verification interactions is generated through standard security negotiation between the client and the server, further enhancing the device access threshold. When the client sends an identity authentication request, it initiates a chain establishment permission request to the controller. The controller needs to perform dual verification of the device's registration status and real-time permissions. After confirming its legitimacy, it generates and issues a chain establishment permission response to the server, ensuring that each tunnel establishment is an authorization for the currently legitimate device. After receiving the permission response, the server device performs multi-layered security audits of the client's request through digital signature verification, timestamp freshness checks, and device identifier consistency confirmation. Only when all verification steps are completed without error will the encrypted tunnel be formally established based on the client's identity authentication request, achieving highly dynamic and fine-grained tunnel access control.

[0139] The above mechanism effectively fills the gap in the existing technology where the encrypted tunnel establishment process relies on static authorization detection, overcomes the shortcomings of being unable to respond to real-time dynamic attacks in a timely manner, ensure the legitimacy of devices and the freshness of sessions, and greatly improves the level of network security protection. In particular, in the ever-changing distributed network environment, it provides a more robust barrier for data transmission encryption and solves the key technical problem of insufficient security caused by static authorization detection mechanism in related technologies.

[0140] Furthermore, the encrypted tunnel establishment device also includes: a first sending module, used to send server-side operation configuration information to the server-side device through a pre-agreed encrypted management channel before the encrypted tunnel establishment process starts, wherein the server-side operation configuration information includes: listening port parameters, encryption algorithm priority information, shared key exchange algorithm parameter set, and control identifier; and a configuration module, used by the server-side device to load a daemon process based on the listening port parameters after receiving the server-side operation configuration information, and in the daemon process to start a device authentication program based on the control identifier, start a listening program based on the listening port parameters, create a security association database based on the encryption algorithm priority information, and generate a server local key based on the shared key exchange algorithm parameter set.

[0141] Furthermore, the encrypted tunnel establishment device also includes: a second sending module, used to send client operation configuration information to the client device through a pre-agreed encrypted management channel before the encrypted tunnel establishment process starts, wherein the client operation configuration information includes: security protocol parameters, shared key exchange algorithm parameter set, security policy and network configuration parameters; and a first generation module, used to generate an instantiated protocol stack based on the security protocol parameters, security policy and network configuration parameters, and generate a client local key based on the shared key exchange algorithm parameter set, after receiving the client operation configuration information.

[0142] Further, the first sending unit includes: a second generation module, used by the client device to generate a first random number using a local random number generator; a first packaging module, used to retrieve the client's public key from the client's local key and package the first random number and the client's public key into a security negotiation request; an association module, used to retrieve a list of encryption algorithms to be negotiated, a list of message authentication code algorithms, and a pseudo-random function used for key derivation as encryption algorithm materials, and associate the encryption algorithm materials with the security negotiation request; and a third sending module, used to send the associated security negotiation request and encryption algorithm materials to the server device.

[0143] Furthermore, the first sending unit also includes: a third generation module, used by the server device to parse the security negotiation request and encryption algorithm material, and call a local random number generator to generate a second random number; a first calculation module, used to retrieve the server's public key and private key from the server's local key, and perform encryption calculations based on the server's private key and the client's public key to generate a shared key; a determination module, used to determine the target encryption algorithm from the list of encryption algorithms to be negotiated, to obtain a first type of algorithm identifier, and to determine the target message authentication code algorithm from the list of message authentication code algorithms, to obtain a second type of algorithm identifier; a second calculation module, used to perform key derivation operations based on the target encryption algorithm, a pseudo-random function, and the shared key to obtain a derived key set; and a second packaging module, used to package the second random number, the server's public key, the first type of algorithm identifier, the second type of algorithm identifier, and the derived key set into a security negotiation response and return it to the client device.

[0144] Furthermore, the second sending unit includes: a third operation module, used to parse the security negotiation response, perform encryption operations based on the server's public key and the client's private key to obtain a shared key, and store the shared key along with a first type of algorithm identifier, a second type of algorithm identifier, and a derived key set; a fourth generation module, used to obtain the client device identifier and generate an authentication signature based on the client's private key; a fourth sending module, used to encrypt the client device identifier and the authentication signature using the shared key, generate an authentication request, and send the authentication request to the server device; and a fifth sending module, used to construct a chain-building permission request based on a first random number and the client device identifier, and send the chain-building permission request to the controller through a pre-agreed encryption management channel.

[0145] Further, the generation unit includes: a lookup module, used to, upon receiving a blockchain establishment permission request, perform a lookup in the registration domain based on the client device identifier to obtain a lookup result, wherein the registration domain is used to record pre-registered qualified devices; a first setting module, used to set the client identity authentication result to authentication passed if the lookup result indicates that the registration domain contains the client device identifier; a second setting module, used to set the client identity authentication result to authentication failed if the lookup result indicates that the registration domain does not contain the client device identifier; a fifth generation module, used to generate a session real-time authentication result based on a first random number and a first current timestamp; a third packaging module, used to package the client identity authentication result and the session real-time authentication result into a blockchain establishment permission response and generate a digital signature for the blockchain establishment permission response; and a sixth sending module, used to send the blockchain establishment permission response to the server device through a pre-agreed encrypted management channel.

[0146] Furthermore, the establishment unit includes: a first verification module, used to parse the digital signature of the blockchain establishment permission response and verify the integrity of the digital signature to obtain a first verification result; a second verification module, used to parse the session real-time authentication result in the blockchain establishment permission response to obtain a first current timestamp, and compare the first current timestamp with the second current timestamp of the server's local clock based on a preset time window to obtain a second verification result; and a third verification module, used to confirm whether the client identity authentication result in the blockchain establishment permission response is consistent with the authentication signature in the identity authentication request to obtain a third verification result.

[0147] The aforementioned encrypted tunnel establishment device based on controller authentication may also include a processor and a memory. The first sending unit 31, the second sending unit 32, the generation unit 33, the establishment unit 34, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0148] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured; by adjusting kernel parameters, an encrypted communication tunnel can be established between the server and client devices based on the authentication request, provided all authentications are successful.

[0149] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0150] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: After the encrypted tunnel establishment process is initiated, the client device sends a security negotiation request to the server device, and the server device returns a security negotiation response, wherein the security negotiation request carries encryption algorithm materials, and the security negotiation response includes: initial key materials generated based on the encryption algorithm materials; upon receiving the security negotiation response, the client device sends an authentication request to the server device and simultaneously sends a chain establishment permission request to the controller, wherein the authentication request carries a client device identifier and an authentication signature, and the chain establishment permission request carries at least the client device identifier; the controller generates a chain establishment permission response based on the chain establishment permission request and synchronizes it to the server device, wherein the chain establishment permission response includes the client authentication result and the session real-time authentication result; the server device verifies the authentication signature in the chain establishment permission response and the authentication request, and if all verifications are successful, establishes an encrypted communication tunnel between the server device and the client device based on the authentication request.

[0151] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute any of the controller authentication-based encrypted tunnel establishment methods in Embodiment 1 above.

[0152] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the controller authentication-based encrypted tunnel establishment method of any one of the above embodiments.

[0153] Figure 4 This is a structural block diagram of an electronic device for executing a controller authentication-based encrypted tunnel establishment method according to an embodiment of the present invention, such as... Figure 4 As shown, the electronic device may include: one or more ( Figure 4 (Only one is shown) Processor 402, memory 404, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0154] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the controller authentication-based encrypted tunnel establishment method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned controller authentication-based encrypted tunnel establishment method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0155] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 4 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0156] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0157] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

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

[0159] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, 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 coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0160] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0161] Furthermore, the functional units in the various embodiments of the present invention 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.

[0162] 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 medium. Based on this understanding, the technical solution of the present invention, 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 storage medium 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 the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0163] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for establishing an encrypted tunnel based on controller authentication, characterized in that, The encrypted tunnel establishment method, applied to a target network environment including controllers, server devices, and client devices, includes: After the encrypted tunnel establishment process is initiated, the client device sends a security negotiation request to the server device, and the server device returns a security negotiation response. The security negotiation request carries encryption algorithm materials, and the security negotiation response includes: initial key materials generated based on the encryption algorithm materials. Upon receiving the security negotiation response, the client device sends an authentication request to the server device and a chain establishment permission request to the controller. The authentication request carries the client device identifier and the authentication signature, and the chain establishment permission request carries at least the client device identifier. The controller generates a blockchain creation permission response based on the blockchain creation permission request and synchronizes it to the server device. The blockchain creation permission response includes the client identity authentication result and the session real-time authentication result. The server device verifies the authentication signature in the chain establishment permission response and the identity authentication request. If all verifications are successful, an encrypted communication tunnel is established between the server device and the client device based on the identity authentication request.

2. The encrypted tunnel establishment method based on controller authentication according to claim 1, characterized in that, Before the encrypted tunnel establishment process is initiated, the encrypted tunnel establishment method further includes: The controller sends server-side operation configuration information to the server-side device through a pre-agreed encryption management channel. The server-side operation configuration information includes: listening port parameters, encryption algorithm priority information, shared key exchange algorithm parameter set, and control identifier. After receiving the server running configuration information, the server device loads a daemon process based on the listening port parameters, starts a device authentication program based on the control identifier in the daemon process, starts a listening program based on the listening port parameters, creates a security association database based on the encryption algorithm priority information, and generates a server local key based on the shared key exchange algorithm parameter set.

3. The method for establishing an encrypted tunnel based on controller authentication according to claim 1, characterized in that, Before the encrypted tunnel establishment process is initiated, the encrypted tunnel establishment method further includes: The controller sends client operation configuration information to the client device through a pre-agreed encrypted management channel. The client operation configuration information includes: security protocol parameters, shared key exchange algorithm parameter set, security policy, and network configuration parameters. After receiving the client's runtime configuration information, the client device generates an instantiated protocol stack based on the security protocol parameters, the security policy, and the network configuration parameters, and generates a client-local key based on the shared key exchange algorithm parameter set.

4. The encrypted tunnel establishment method based on controller authentication according to claim 1, characterized in that, After the encrypted tunnel establishment process is initiated, the steps for the client device to send a security negotiation request to the server device include: The client device generates a first random number using a local random number generator; Retrieve the client's public key from the client's local key, and package the first random number and the client's public key into the security negotiation request; Retrieve the list of encryption algorithms to be negotiated, the list of message authentication code algorithms, and the pseudo-random function used for key derivation as encryption algorithm materials, and associate the encryption algorithm materials with the security negotiation request; The associated security negotiation request and the encryption algorithm material are sent to the server device.

5. The method for establishing an encrypted tunnel based on controller authentication according to claim 4, characterized in that, The steps for the server device to return a security negotiation response include: The server device parses the security negotiation request and the encryption algorithm material, and calls a local random number generator to generate a second random number; Retrieve the server's public key and private key from the server's local key, and perform encryption operations based on the server's private key and the client's public key to generate a shared key; The target encryption algorithm is determined from the list of encryption algorithms to be negotiated, and the first type of algorithm identifier is obtained. The target message authentication code algorithm is determined from the list of message authentication code algorithms, and the second type of algorithm identifier is obtained. Based on the target encryption algorithm, the pseudo-random function, and the shared key, a key derivation operation is performed to obtain a derived key set; The second random number, the server public key, the first type of algorithm identifier, the second type of algorithm identifier, and the derived key set are packaged into the security negotiation response and returned to the client device.

6. The encrypted tunnel establishment method based on controller authentication according to claim 5, characterized in that, Upon receiving the security negotiation response, the client device sends an authentication request to the server device and simultaneously sends a chain establishment permission request to the controller, comprising the following steps: Parse the security negotiation response, perform encryption operations based on the server public key and client private key to obtain the shared key, and store the shared key along with the first type of algorithm identifier, the second type of algorithm identifier, and the derived key set; Obtain the client device identifier and generate the authentication signature based on the client private key; The shared key is used to encrypt the client device identifier and the authentication signature to generate the authentication request, which is then sent to the server device. The chain establishment permission request is constructed based on the first random number and the client device identifier, and sent to the controller through a pre-agreed encrypted management channel.

7. The method for establishing an encrypted tunnel based on controller authentication according to claim 6, characterized in that, The step of the controller generating a blockchain establishment permission response based on the blockchain establishment permission request and synchronizing it to the server device includes: Upon receiving the chain establishment permission request, the controller searches the registration domain based on the client device identifier to obtain the search result. The registration domain is used to record pre-registered qualified devices. If the search results indicate that the registration domain contains the client device identifier, the client authentication result is set to successful. If the search results indicate that the client device identifier is not included in the registration domain, the client authentication result will be set to authentication failed. The session real-time authentication result is generated based on the first random number and the first current timestamp; The client authentication result and the session real-time authentication result are packaged into the chain-building permission response, and a digital signature of the chain-building permission response is generated. The chain establishment permission response is sent to the server device through a pre-agreed encrypted management channel.

8. The method for establishing an encrypted tunnel based on controller authentication according to claim 7, characterized in that, The steps for the server-side device to verify the authentication signature in the chain establishment permission response and the identity authentication request include: Parse the digital signature of the chain establishment permission response and verify the integrity of the digital signature to obtain a first verification result; The session real-time authentication result in the chain establishment permission response is parsed to obtain a first current timestamp. Based on a preset time window, the first current timestamp is compared with the second current timestamp of the server's local clock to obtain a second verification result. A third verification result is obtained by comparing the client identity authentication result in the chain establishment permission response with the authentication signature confirmation information in the identity authentication request.

9. A device for establishing an encrypted tunnel based on controller authentication, characterized in that, The encrypted tunnel establishment device is applied to a target network environment that includes controllers, server devices, and client devices. The first sending unit is configured to send a security negotiation request from the client device to the server device after the encrypted tunnel establishment process is initiated, and the server device returns a security negotiation response, wherein the security negotiation request carries encryption algorithm materials, and the security negotiation response includes: initial key materials generated based on the encryption algorithm materials; The second sending unit is used to send an authentication request from the client device to the server device and a chain establishment permission request to the controller after receiving the security negotiation response. The authentication request carries the client device identifier and the authentication signature, and the chain establishment permission request carries at least the client device identifier. A generation unit is used to generate a blockchain creation permission response based on the blockchain creation permission request by the controller and synchronize it to the server device, wherein the blockchain creation permission response includes client identity authentication result and session real-time authentication result; The establishment unit is used to verify the authentication signature in the chain establishment permission response and the identity authentication request by the server device. If all verifications are successful, the unit establishes an encrypted communication tunnel between the server device and the client device based on the identity authentication request.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the encrypted tunnel establishment method based on controller authentication as described in any one of claims 1 to 8.

11. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the controller authentication-based encrypted tunnel establishment method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The method includes computer instructions, wherein when executed by a processor, the computer instructions implement the steps of the controller authentication-based encrypted tunnel establishment method according to any one of claims 1 to 8.

Images