Communication Method and Device

Abstract

The present application provides a communication method and apparatus. The method includes: sending a first message to a central device through a first IPSec tunnel, where the first message includes a public key generated by a first branch device and identity information of a second branch device, so that when the central device determines that a second IPSec tunnel has been established with the second branch device, sending a second message to the second branch device through the second IPSec tunnel, where the second message includes the public key generated by the first branch device; receiving, through the first IPSec tunnel, a third message forwarded by the central device and sent by the second branch device, where the third message is sent by the second branch device to the central device after calculating a private key using the public key and verifying all messages exchanged between the first branch device and the second branch device using the private key; and generating a first IPSec SA if the private key calculated using the public key can decrypt the third message and verify all messages.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a communication method and apparatus. Background Art

[0002] Currently, an IP Security (IPSec) Virtual Private Network (VPN) can conveniently connect network devices located at different geographical locations. A common networking mode is a hub-and-spoke networking. As Figure 1 shown, Figure 1 is a schematic diagram of an existing hub-and-spoke networking.

[0003] In Figure 1 , after IKE negotiation between the hub and the spokes, an IPSec tunnel is negotiated and established. In the Internet Key Exchange (IKE) negotiation, IKE first negotiates and establishes a secure channel (IKE Security Association (SA)) between the two communication parties, and negotiates and establishes an IPSec SA under the protection of this secure channel, thus reducing the complexity of manual configuration and simplifying the configuration and maintenance work of IPSec. The essence of IKE lies in the Diffie-Hellman (DH) exchange technology, which enables the two communication parties to finally calculate a shared key through a series of exchanges.

[0004] In the DH exchange process of IKE, each calculated and generated result is irrelevant. Since the DH exchange process is run every time an IKE SA is established, the keys used by each IPSec SA established through IKE negotiation are ensured to be irrelevant to each other.

[0005] After an IPSec tunnel is established between the hub and the spokes, no tunnels are negotiated between the spokes. When the spokes need to access each other, a dynamic tunnel is re-negotiated and established between the spokes. During the tunnel establishment process, the spokes need to execute the IKE negotiation again. If the IKE negotiation is successful, an IPSec tunnel is negotiated and established again. After the IPSec tunnel is successfully established, encrypted and decrypted transmission of private network traffic is achieved between the spokes.

[0006] During the inter-branch communication process, the security advantages of IKE negotiation are retained. However, it is still not flexible enough. In actual use, if there is a lot of encrypted traffic between branches, the CPU pressure of each branch will be high, and IPSec tunnel negotiation will be relatively slow. Moreover, due to IKE's DH exchange, multiple handshakes will be required between branches, consuming more time. Especially in large-scale networks, the dynamic negotiation of IPsec tunnels between branches takes more time, resulting in excessive pressure on the center (traffic is forwarded from the center) and high packet loss of private network traffic between branches, affecting user experience. Summary of the Invention

[0007] In view of this, the present application provides a communication method and device to solve the problems of inflexibility of IKE negotiation between different branches; high CPU pressure on each branch and slow IPsec tunnel negotiation; and multiple handshakes between branches due to IKE's DH exchange, which consumes more time.

[0008] In a first aspect, the present application provides a communication method, which is applied to a first branch device, wherein the first branch device accesses a central device and establishes a first IPSec tunnel with the central device, the method comprising:

[0009] Sending a first message to the central device through the first IPSec tunnel, the first message including the public key generated by the first branch device and the identity information of the second branch device, so that when the central device determines that a second IPSec tunnel has been established with the second branch device based on the identity information of the second branch device, the central device sends a second message to the second branch device through the second IPSec tunnel, the second message including the public key generated by the first branch device;

[0010] receiving, through the first IPSec tunnel, a third message sent by the second branch device and forwarded by the central device, wherein the third message is sent to the central device after the second branch device calculates a private key using the public key and verifies all messages exchanged between the first branch device and the second branch device using the private key;

[0011] If the private key calculated using the public key can be used to decrypt the third message and all the messages can be verified, a first IPSec SA is generated.

[0012] In a second aspect, the present application provides a communication method, which is applied to a second branch device, wherein the second branch device accesses a central device and establishes a second IPSec tunnel with the central device, the method comprising:

[0013] Receive a second message sent by the central device through the second IPSec tunnel, where the second message includes a public key generated by a first branch device;

[0014] After verifying that all messages exchanged between the first branch device and the second branch device pass using the private key calculated from the public key, send a third message to the central device through the second IPSec tunnel. The third message is encrypted using the private key so that the central device forwards the third message to the first branch device through the first IPSec tunnel established with the first branch device. The first branch device can decrypt the third message using the private key calculated from the public key and generate a first IPSec SA after verifying that all messages exchanged between the first branch device and the second branch device pass.

[0015] In a third aspect, the present application provides a communication method. The method is applied to a central device. The central device has a first branch device and a second branch device connected to it. The central device establishes a first IPSec tunnel with the first branch device. The method includes:

[0016] Receive a first message sent by the first branch device through the first IPSec tunnel. The first message includes a public key generated by the first branch device and the identity information of the second branch device;

[0017] Determine whether to establish a second IPSec tunnel with the second branch device according to the identity information of the second branch device;

[0018] If so, send a second message to the second branch device through the second IPSec tunnel. The second message includes the public key generated by the first branch device;

[0019] Receive a third message sent by the second branch device through the second IPSec tunnel. The third message is sent by the second branch device after calculating a private key from the public key and verifying that all messages exchanged between the first branch device and the second branch device pass using the private key;

[0020] Forward the third message to the first branch device through the first IPSec tunnel so that the first branch device can decrypt the third message using the private key calculated from the public key and generate a first IPSec SA after verifying that all messages pass.

[0021] In a fourth aspect, the present application provides a communication device. The device is applied to a first branch device. The first branch device is connected to a central device and establishes a first IPSec tunnel with the central device. The device includes:

[0022] A sending unit, configured to send a first message to the central device through the first IPSec tunnel, where the first message includes a public key generated by the first branch device and identity information of a second branch device, so that when the central device determines, according to the identity information of the second branch device, that a second IPSec tunnel has been established with the second branch device, a second message is sent to the second branch device through the second IPSec tunnel, and the second message includes the public key generated by the first branch device;

[0023] A receiving unit, configured to receive, through the first IPSec tunnel, a third message forwarded by the central device and sent by the second branch device, where the third message is sent by the second branch device to the central device after calculating a private key by using the public key and verifying all messages exchanged between the first branch device and the second branch device by using the private key;

[0024] A generating unit, configured to generate a first IPSec SA if the private key calculated by using the public key can decrypt the third message and verify all the messages.

[0025] In a fifth aspect, the present application provides a communication device, which is applied to a second branch device. The second branch device accesses a central device and establishes a second IPSec tunnel with the central device. The device includes:

[0026] A receiving unit, configured to receive, through the second IPSec tunnel, a second message sent by the central device, where the second message includes a public key generated by a first branch device;

[0027] A sending unit, configured to, after verifying that all messages exchanged between the first branch device and the second branch device pass by using the private key calculated by using the public key, send a third message to the central device through the second IPSec tunnel, where the third message is encrypted by using the private key, so that the central device forwards the third message to the first branch device through a first IPSec tunnel established with the first branch device, and the first branch device generates a first IPSec SA after decrypting the third message by using the private key calculated by using the public key and verifying all messages exchanged between the first branch device and the second branch device.

[0028] In a sixth aspect, the present application provides a communication device, which is applied to a central device. The central device accesses a first branch device and a second branch device, and the central device establishes a first IPSec tunnel with the first branch device. The device includes:

[0029] A receiving unit, configured to receive a first message sent by the first branch device through the first IPSec tunnel, where the first message includes a public key generated by the first branch device and identity information of a second branch device;

[0030] A determining unit, configured to determine whether to establish a second IPSec tunnel with the second branch device according to the identity information of the second branch device;

[0031] A sending unit, configured to, if so, send a second message to the second branch device through the second IPSec tunnel, where the second message includes the public key generated by the first branch device;

[0032] The receiving unit is further configured to receive a third message sent by the second branch device through the second IPSec tunnel, where the third message is sent by the second branch device after calculating a private key using the public key and verifying all messages exchanged between the first branch device and the second branch device using the private key;

[0033] The sending unit is further configured to forward the third message to the first branch device through the first IPSec tunnel, so that the first branch device can decrypt the third message using the private key calculated from the public key and generate a first IPSec SA after verifying all the messages.

[0034] In a seventh aspect, the present application provides a network device, including a processor and a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0035] In an eighth aspect, the present application provides a network device, including a processor and a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the second aspect of the present application.

[0036] In a ninth aspect, the present application provides a network device, including a processor and a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the third aspect of the present application.

[0037] Therefore, by applying the communication method and device provided in this application, through the first IPSec tunnel, the first branch device sends a first message to the central device, and the first message includes the public key generated by the first branch device and the identity information of the second branch device, so that when the central device determines that the second IPSec tunnel has been established with the second branch device according to the identity information of the second branch device, it sends a second message to the second branch device through the second IPSec tunnel, and the second message includes the public key generated by the first branch device; through the first IPSec tunnel, the first branch device receives a third message forwarded by the central device and sent by the second branch device. The third message is sent by the second branch device to the central device after calculating the private key using the public key and verifying all the messages exchanged between the first branch device and the second branch device using the private key; if the private key calculated using the public key can decrypt the third message and verify all the messages, the first branch device generates the first IPSec SA.

[0038] In this way, when the Spoke-Spoke networking is performed between branch devices, the traffic for tunnel key negotiation is transmitted between each other through the IPSec tunnels established with the central device, without passing through the public network, improving security; the public keys of the tunnels between branch devices do not need to perform discrete logarithm calculations in the DH algorithm again, saving computing resources. It solves the problems of inflexible IKE negotiation between existing different branches; high CPU pressure on each branch and slow IPSec tunnel negotiation; moreover, due to the DH exchange of IKE, multiple handshakes occur between branches, consuming more time. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 It is a schematic diagram of the existing central-branch networking;

[0040] Figure 2 It is a flowchart of a communication method provided by an embodiment of this application;

[0041] Figure 3 It is a flowchart of another communication method provided by an embodiment of this application;

[0042] Figure 4 It is a flowchart of yet another communication method provided by an embodiment of this application;

[0043] Figure 5 It is a structural diagram of a communication device provided by an embodiment of this application;

[0044] Figure 6 It is a structural diagram of another communication device provided by an embodiment of this application;

[0045] Figure 7 It is a structural diagram of yet another communication device provided by an embodiment of this application;

[0046] Figure 8 This is the hardware structure of the network device provided by the embodiment of the present application. Specific implementation manners

[0047] Here, exemplary embodiments will be described in detail, and examples thereof are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0048] The terms used in the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. The singular forms "a", "the", and "said" used in the present application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0049] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0050] Next, a communication method provided by the embodiment of the present application will be described in detail. Refer to Figure 2 , Figure 2 This is a flowchart of a communication method provided by the embodiment of the present application. This method is applied to the first branch device. The communication method provided by the embodiment of the present application may include the following steps.

[0051] Step 210: Send a first message to the central device through the first IPSec tunnel. The first message includes the public key generated by the first branch device and the identity information of the second branch device, so that when the central device determines that a second IPSec tunnel has been established with the second branch device according to the identity information of the second branch device, send a second message to the second branch device through the second IPSec tunnel. The second message includes the public key generated by the first branch device;

[0052] Specifically, the first branch device is within a hub-and-spoke network and is connected to the hub device. The hub-and-spoke network also includes a second branch device. Each device included in the hub-and-spoke network performs IPSec && IKE configuration, and each device between the branches performs Spoke-Spoke IPSec configuration, including specifying the address of the peer branch, sharing the private key from the hub device, etc.

[0053] The first branch device has established a first IPSec tunnel with the hub device. At this time, the first branch device establishes a Spoke-Spoke network with the second branch device connected to the hub device and intends to communicate with the second branch device.

[0054] Optionally, before performing step 210, the first branch device first performs IKE security policy negotiation with the second branch device; when the IKE security policy negotiation is successful, the first branch device generates a public key.

[0055] Furthermore, the first branch device first generates a random number using a random number generator. Then, based on the random number and the system time, the first branch device generates a public key.

[0056] After the first branch device generates the public key, it obtains the identity information of the second branch device configured locally. The first branch device generates a first message, which includes the public key generated by the first branch device and the identity information of the second branch device.

[0057] Through the first IPSec tunnel, the first branch device sends the first message to the hub device.

[0058] It should be noted that when the first branch device and the second branch device perform IKE security policy negotiation, it can be carried out according to the existing IKE security policy negotiation process, which will not be repeated here. The first branch device generates the public key according to the existing public key generation process, which will not be repeated here.

[0059] Optionally, after the first branch device generates the public key, it also calculates the corresponding private key using the public key. This private key is used as the key for IPSec encryption and authentication when subsequently reusing the IPSec tunnel established between it and the hub device to transmit messages. The process for the first branch device to calculate the private key is the same as the existing process of calculating the private key using the public key, which will not be repeated here.

[0060] It can be understood that since the first branch device has established a trusted first IPSec tunnel with the hub device, before the first branch device sends the first message to the hub device through the first IPSec tunnel, it also encrypts the first message using the key corresponding to the first IPSec tunnel and sends it through the first IPSec tunnel after encryption.

[0061] After the central device receives the first message, it first decrypts the first message using the key corresponding to the first IPSec tunnel. Then, the central device obtains the public key generated by the first branch device and the identity information of the second branch device from the first message.

[0062] According to the identity information of the second branch device, the central device searches for the second branch device locally and determines whether to establish a second IPSec tunnel with the second branch device. If the central device determines that it has established a second IPSec tunnel with the second branch device, the central device generates a second message, which includes the public key generated by the first branch device.

[0063] Through the second IPSec tunnel, the central device sends the second message to the second branch device.

[0064] It can be understood that since the central device has established a trusted second IPSec tunnel with the second branch device, before the central device sends the second message to the second branch device through the second IPSec tunnel, it also encrypts the second message using the key corresponding to the second IPSec tunnel and sends it through the second IPSec tunnel after encryption.

[0065] Optionally, in the process of the central device searching for the second branch device locally and determining whether to establish a second IPSec tunnel with the second branch device, there is also another situation, that is, if the central device determines that it has not established a second IPSec tunnel with the second branch device, the central device generates a fourth message (referred to as the fourth message here for distinction from other messages), which includes an error message indicating that the second branch device is not online.

[0066] Through the first IPSec tunnel, the central device sends the fourth message to the first branch device. It can be understood that before the central device sends the fourth message to the first branch device through the first IPSec tunnel, it also encrypts the fourth message using the key corresponding to the first IPSec tunnel and sends it through the first IPSec tunnel after encryption.

[0067] After the first branch device receives the fourth message sent by the central device, it determines that the second branch device is not online according to the fourth message. The first branch device negotiates keys with the second branch device. This key negotiation is the key for establishing an IPSec tunnel through the DH exchange technology existing.

[0068] Step 220: Receive, via the first IPSec tunnel, the third message forwarded by the central device and sent by the second branch device. The third message is sent by the second branch device to the central device after the second branch device calculates the private key using the public key and verifies all the messages exchanged between the first branch device and the second branch device using the private key.

[0069] Specifically, according to the description in Step 210, after receiving the second message, the second branch device obtains the public key generated by the first branch device therefrom. Using the public key, the second branch device calculates the private key. This private key is used as the key for IPSec encryption and authentication when subsequently reusing the IPSec tunnel established between it and the central device to transmit messages.

[0070] Meanwhile, after calculating the private key, the second branch device uses the private key to authenticate all the messages exchanged between the first branch device and the second branch device before this (policy matching messages during the prior IKE security policy negotiation process, the second message forwarded by the central device, etc.).

[0071] After the second branch device verifies all the messages using the private key, it generates the third message and sends the third message to the central device via the second IPSec tunnel. It should be noted that before sending the third message, the second branch device encrypts the third message using the calculated private key.

[0072] After receiving the third message sent by the second branch device, the central device forwards the third message to the first branch device via the first IPSec tunnel.

[0073] Step 230: If the private key calculated using the public key can decrypt the third message and passes the verification of all the messages, generate the first IPSec SA.

[0074] Specifically, according to the description in Step 220, after receiving the third message, the first branch device attempts to decrypt the third message using the calculated private key. Meanwhile, it also authenticates all the messages exchanged before this using the private key.

[0075] If the private key can decrypt the third message and passes the verification of all the messages, the first branch device generates the first IPSec SA.

[0076] After the first branch device generates the first IPSec SA, it waits for the second branch device to generate the second IPSec SA. After both end devices have established the IPSec SAs, they reuse the IPSec tunnels established with the central device respectively to achieve interactive communication between the branch devices.

[0077] Therefore, by applying the communication method provided in this application, through the first IPSec tunnel, the first branch device sends a first message to the central device. The first message includes the public key generated by the first branch device and the identity information of the second branch device, so that when the central device determines that a second IPSec tunnel has been established with the second branch device according to the identity information of the second branch device, it sends a second message to the second branch device through the second IPSec tunnel. The second message includes the public key generated by the first branch device; through the first IPSec tunnel, the first branch device receives a third message forwarded by the central device and sent by the second branch device. The third message is sent by the second branch device to the central device after calculating the private key using the public key and verifying all the messages exchanged between the first branch device and the second branch device using the private key; if the private key calculated using the public key can decrypt the third message and verify all the messages, the first branch device generates a first IPSec SA.

[0078] In this way, when the Spoke-Spoke networking is performed between branch devices, the traffic for tunnel key negotiation is mutually transmitted between the branch devices and the central device through the established IPSec tunnels, without passing through the public network, improving security; the public keys of the tunnels between branch devices do not need to perform discrete logarithm calculations in the DH algorithm again, saving computing resources. It solves the problems of inflexible IKE negotiation between existing different branches; the CPU pressure of each branch is relatively large, and the IPSec tunnel negotiation is slow; moreover, due to the DH exchange of IKE, multiple handshakes occur between branches, consuming more time.

[0079] Optionally, in the embodiment of this application, it further includes the process of the first branch device sending a fifth message to the central device.

[0080] Specifically, after the first branch device generates the first IPSec SA, it generates a fifth message. The fifth message is encrypted using the calculated private key. Through the first IPSec tunnel, the first branch device sends the fifth message to the central device.

[0081] After receiving the fifth message, the central device forwards the fifth message to the second branch device through the second IPSec tunnel.

[0082] After receiving the fifth message, the second branch device attempts to decrypt the fifth message using the calculated private key, and at the same time, authenticates the identity of the first branch device. If the private key can decrypt the fifth message and the identity verification of the first branch device is successful, the second branch device generates a second IPSec SA.

[0083] In this way, both ends of the device have generated IPSec SAs, and the two ends of the device negotiate and establish an IPSec tunnel using the IPSec SAs generated by each of them, realizing the interactive communication between branch devices.

[0084] The following provides a detailed description of a communication method provided by an embodiment of the present application. Refer to Figure 3 , Figure 3 which is a flowchart of another communication method provided by an embodiment of the present application. This method is applied to a second branch device. The communication method provided by the embodiment of the present application may include the following steps.

[0085] Step 310: Receive, through the second IPSec tunnel, a second message sent by the central device, where the second message includes a public key generated by a first branch device;

[0086] Specifically, according to the foregoing embodiment, it can be known that the first branch device and the second branch device establish a Spoke-Spoke network and intend to interact and communicate with the second branch device.

[0087] The first branch device generates and sends a first message to the central device through the first IPSec tunnel. After receiving the first message, the central device generates and sends a second message to the second branch device through the second IPSec tunnel. The second message includes the public key generated by the first branch device.

[0088] After receiving the second message, the second branch device obtains the public key generated by the first branch device from it.

[0089] Optionally, using the public key, the second branch device calculates a private key. This private key is used as the key for IPSec encryption and authentication when subsequently reusing the IPSec tunnel established between it and the central device to transmit messages.

[0090] Optionally, before sending the second message to the second branch device, the central device also encrypts the second message using the key corresponding to the second IPSec tunnel and sends it to the second branch device through the second IPSec tunnel after encryption.

[0091] It can be understood that the process of the first branch device generating the public key and the first message, sending the first message to the central device, and the central device determining whether the second IPSec tunnel has been established with the second branch device can be referred to the description of the previous embodiment and will not be repeated here.

[0092] Step 320: After verifying that all the messages exchanged between the first branch device and the second branch device pass using the private key calculated from the public key, send a third message to the central device through the second IPSec tunnel. The third message is encrypted using the private key, so that the central device forwards the third message to the first branch device through the first IPSec tunnel established with the first branch device. The first branch device can decrypt the third message using the private key calculated from the public key and generate a first IPSec SA after verifying all the messages exchanged between the first branch device and the second branch device.

[0093] Specifically, according to the description of step 310, the second branch device obtains the public key generated by the first branch device, calculates the corresponding private key using the public key, and then uses the private key to authenticate all the messages exchanged between the first branch device and the second branch device before (policy matching messages in the prior IKE security policy negotiation process, the second message forwarded by the central device, etc.).

[0094] After the second branch device verifies all the messages using the private key, it generates a third message and sends the third message to the central device through the second IPSec tunnel. It should be noted that before sending the third message, the second branch device encrypts the third message using the calculated private key.

[0095] After receiving the third message sent by the second branch device, the central device forwards the third message to the first branch device through the first IPSec tunnel.

[0096] After receiving the third message, the first branch device attempts to decrypt the third message using the calculated private key. At the same time, it also authenticates all the messages exchanged before using the private key.

[0097] If the private key can decrypt the third message and verify all the messages, the first branch device generates a first IPSec SA.

[0098] After the first branch device generates the first IPSec SA, it waits for the second branch device to generate the second IPSec SA. After both end devices establish the IPSec SAs, they reuse the IPSec tunnels established with the central device respectively to achieve the interactive communication between the branch devices.

[0099] Optionally, before executing step 310, the second branch device also performs IKE security policy negotiation with the first branch device.

[0100] It should be noted that when the first branch device and the second branch device perform IKE security policy negotiation, they can follow the existing IKE security policy negotiation process, which will not be repeated here.

[0101] Optionally, in the embodiments of the present application, it further includes a process in which the first branch device negotiates a key with the second branch device when the second branch device fails to establish a second IPSec tunnel with the central device.

[0102] Specifically, after receiving the first message sent by the first branch device, the central device obtains the public key generated by the first branch device and the identity information of the second branch device therefrom.

[0103] According to the identity information of the second branch device, the central device searches for the second branch device locally and determines whether to establish a second IPSec tunnel with the second branch device. If the central device determines that it has not established a second IPSec tunnel with the second branch device, the central device generates a fourth message (referred to as the fourth message here for distinction from other messages), and the fourth message includes an error message indicating that the second branch device is not online.

[0104] Through the first IPSec tunnel, the central device sends the fourth message to the first branch device. It can be understood that before sending the fourth message to the first branch device through the first IPSec tunnel, the central device also encrypts the fourth message using the key corresponding to the first IPSec tunnel and sends it to the first branch device after encryption.

[0105] After receiving the fourth message sent by the central device, the first branch device determines that the second branch device is not online. The first branch device negotiates a key with the second branch device. This key negotiation is the key for negotiating and establishing an IPSec tunnel through the existing DH exchange technology.

[0106] Optionally, in the embodiments of the present application, it further includes the second branch device receiving the fifth message forwarded by the central device.

[0107] Specifically, after generating the first IPSec SA, the first branch device generates a fifth message. The fifth message is encrypted using the calculated private key. Through the first IPSec tunnel, the first branch device sends the fifth message to the central device.

[0108] After receiving the fifth message, the central device forwards the fifth message to the second branch device through the second IPSec tunnel.

[0109] After receiving the fifth message, the second branch device attempts to decrypt the fifth message using the calculated private key, and at the same time, authenticates the identity of the first branch device. If the private key can decrypt the fifth message and the identity verification of the first branch device is successful, the second branch device generates a second IPSec SA.

[0110] In this way, both end devices have generated IPSec SAs. The two end devices use the IPSec SAs they generated respectively to negotiate and establish an IPSec tunnel, realizing the interactive communication between branch devices.

[0111] Next, a communication method provided by an embodiment of the present application will be described in detail. Refer to Figure 4 , Figure 4 which is a flowchart of another communication method provided by an embodiment of the present application. This method is applied to a central device. The communication method provided by an embodiment of the present application may include the following steps.

[0112] Step 410: Receive a first message sent by the first branch device through the first IPSec tunnel. The first message includes a public key generated by the first branch device and the identity information of the second branch device.

[0113] Specifically, the first branch device is within a central-branch network and is connected to the central device. The central-branch network also includes a second branch device. Each device included in the central-branch network performs IPSec && IKE configuration, and each device between branches performs Spoke-Spoke IPSec configuration, including specifying the address of the peer branch, sharing the private key from the central device, etc.

[0114] The first branch device has established a first IPSec tunnel with the central device. At this time, the first branch device establishes a Spoke-Spoke network with the second branch device connected to the central device and intends to communicate with the second branch device interactively.

[0115] The first branch device first negotiates IKE security policies with the second branch device; when the IKE security policy negotiation is successful, the first branch device generates a public key.

[0116] Further, the first branch device first generates a random number using a random number generator. Then, based on the random number and the system time, the first branch device generates a public key.

[0117] After the first branch device generates the public key, it obtains the identity information of the second branch device configured locally. The first branch device generates a first message, and the first message includes the public key generated by the first branch device and the identity information of the second branch device.

[0118] Through the first IPSec tunnel, the first branch device sends the first message to the central device.

[0119] It can be understood that since the first branch device has established a trusted first IPSec tunnel with the central device, before the first branch device sends the first message to the central device through the first IPSec tunnel, it also encrypts the first message using the key corresponding to the first IPSec tunnel and sends it to the central device through the first IPSec tunnel after encryption.

[0120] After receiving the first message, the central device first decrypts the first message using the key corresponding to the first IPSec tunnel. Then, the central device obtains the public key generated by the first branch device and the identity information of the second branch device from the first message.

[0121] Step 420: Determine whether to establish a second IPSec tunnel with the second branch device according to the identity information of the second branch device;

[0122] Specifically, according to the description of step 410, after the central device obtains the public key generated by the first branch device and the identity information of the second branch device from the first message, according to the identity information of the second branch device, the central device searches for the second branch device locally and determines whether to establish a second IPSec tunnel with the second branch device.

[0123] If the central device determines that it has established a second IPSec tunnel with the second branch device, the central device executes step 430.

[0124] Optionally, if the central device determines that it has not established a second IPSec tunnel with the second branch device, the central device generates a fourth message (referred to as the fourth message here for the sake of distinguishing it from other messages), and the fourth message includes an error message, which is used to indicate that the second branch device is not online.

[0125] Through the first IPSec tunnel, the central device sends the fourth message to the first branch device. It can be understood that before the central device sends the fourth message to the first branch device through the first IPSec tunnel, it also encrypts the fourth message using the key corresponding to the first IPSec tunnel and sends it to the first branch device through the first IPSec tunnel after encryption.

[0126] After receiving the fourth message sent by the central device, the first branch device determines that the second branch device is not online. The first branch device negotiates keys with the second branch device. This key negotiation is the key for establishing an IPSec tunnel through the DH exchange technology existing.

[0127] Step 430: If so, send a second message to the second branch device through the second IPSec tunnel, and the second message includes the public key generated by the first branch device;

[0128] Specifically, according to the description of step 420, if the central device determines that a second IPSec tunnel has been established with the second branch device, the central device generates a second message, which includes the public key generated by the first branch device.

[0129] Through the second IPSec tunnel, the central device sends the second message to the second branch device.

[0130] It can be understood that since the central device has established a trusted second IPSec tunnel with the second branch device, before sending the second message to the second branch device through the second IPSec tunnel, the central device also encrypts the second message using the key corresponding to the second IPSec tunnel and sends it through the second IPSec tunnel after encryption.

[0131] Step 440: Receive, through the second IPSec tunnel, a third message sent by the second branch device, where the third message is sent by the second branch device after calculating the private key using the public key and verifying all messages exchanged between the first branch device and the second branch device using the private key;

[0132] Specifically, according to the description of step 430, after receiving the second message, the second branch device obtains the public key generated by the first branch device from it. Using the public key, the second branch device calculates the private key. This private key is used as the key for IPSec encryption and authentication when subsequently reusing the IPSec tunnel established between it and the central device to transmit messages.

[0133] Meanwhile, after calculating the private key, the second branch device uses the private key to authenticate all messages exchanged between the first branch device and the second branch device before (policy matching messages during the prior IKE security policy negotiation process, the second message forwarded by the central device, etc.).

[0134] After the second branch device verifies all messages using the private key, it generates a third message and sends the third message to the central device through the second IPSec tunnel. It should be noted that before sending the third message, the second branch device encrypts the third message using the calculated private key.

[0135] The central device receives the third message.

[0136] Step 450: Forward the third message to the first branch device through the first IPSec tunnel, so that the first branch device can decrypt the third message using the private key calculated from the public key and generate a first IPSec SA after verifying all messages.

[0137] Specifically, according to the description in step 440, after receiving the third message sent by the second branch device, the central device forwards the third message to the first branch device through the first IPSec tunnel.

[0138] After receiving the third message, the first branch device attempts to decrypt the third message with the calculated private key. At the same time, it also authenticates all the messages exchanged previously using the private key.

[0139] If the private key can decrypt the third message and all the messages pass the verification, the first branch device generates the first IPSec SA.

[0140] After the first branch device generates the first IPSec SA, it waits for the second branch device to generate the second IPSec SA. After both end devices have established the IPSec SAs, they reuse the IPSec tunnels established with the central device respectively to achieve the interactive communication between the branch devices.

[0141] Optionally, in the embodiment of the present application, it further includes the process of the central device receiving the fifth message sent by the first branch device.

[0142] Specifically, after the first branch device generates the first IPSec SA, it generates the fifth message. The fifth message is encrypted with the calculated private key. Through the first IPSec tunnel, the first branch device sends the fifth message to the central device.

[0143] After receiving the fifth message, the central device forwards the fifth message to the second branch device through the second IPSec tunnel.

[0144] After receiving the fifth message, the second branch device attempts to decrypt the fifth message with the calculated private key. At the same time, it also authenticates the identity of the first branch device. If the private key can decrypt the fifth message and the identity verification of the first branch device is successful, the second branch device generates the second IPSec SA.

[0145] In this way, both end devices have generated the IPSec SAs. The two end devices negotiate and establish an IPSec tunnel using the IPSec SAs generated by them respectively to achieve the interactive communication between the branch devices.

[0146] For example, as Figure 1As shown, Branch A, Branch B, and Branch C are all connected to the central device. Each device performs IPSec && IKE configuration, and each device between branches performs Spoke-Spoke IPSec configuration, including specifying the address of the peer branch, sharing the private key from the central device, etc. Each branch establishes a branch IPSec tunnel with the central device, namely Tunnel 1, Tunnel 2, and Tunnel 3. At this time, Branch A and Branch B establish a Spoke-Spoke network and want to communicate with Branch B.

[0147] Branch A first negotiates the IKE security policy with Branch B; when the IKE security policy negotiation is successful, Branch A generates a public key. After Branch A generates the public key, it obtains the identity information of Branch B configured locally. Branch A generates a first message, which includes the public key generated by Branch A and the identity information of Branch B.

[0148] Branch A encrypts the first message using the key corresponding to Tunnel 1 and sends it to the central device through Tunnel 1 after encryption. After Branch A generates the public key, it also calculates the corresponding private key using the public key.

[0149] After receiving the first message, the central device first decrypts the first message using the key corresponding to Tunnel 1. Then, the central device obtains the public key generated by Branch A and the identity information of Branch B from the first message.

[0150] According to the identity information of Branch B, the central device searches for Branch B locally and determines whether to establish Tunnel 2 with Branch B. If the central device determines that Tunnel 2 has been established with Branch B, the central device generates a second message, which includes the public key generated by Branch A.

[0151] The central device encrypts the second message using the key corresponding to Tunnel 2 and sends it to Branch B through Tunnel 2 after encryption.

[0152] After receiving the second message, Branch B obtains the public key generated by Branch A from it. Using the public key, Branch B calculates the private key. At the same time, after Branch B calculates the private key, it uses the private key to authenticate all the messages exchanged between Branch A and Branch B before (the policy matching messages in the prior IKE security policy negotiation process, the second message forwarded by the central device, etc.).

[0153] After Branch B verifies all the messages using the private key and passes, it generates a third message. Branch B encrypts the third message using the private key and sends it to the central device through Tunnel 2 after encryption.

[0154] After receiving the third message sent by Branch B, the central device forwards the third message to Branch A through Tunnel 1.

[0155] After receiving the third message, Branch A attempts to decrypt the third message using the calculated private key. At the same time, it also authenticates all the messages exchanged previously using the private key.

[0156] If the private key can decrypt the third message and all the messages pass the verification, Branch A generates the first IPSec SA.

[0157] After generating the first IPSec SA, Branch A generates the fifth message. Branch A encrypts the fifth message using the private key and sends the encrypted fifth message to the central device through Tunnel 1.

[0158] After receiving the fifth message, the central device forwards the fifth message to Branch B through Tunnel 2.

[0159] After receiving the fifth message, Branch B attempts to decrypt the fifth message using the calculated private key. At the same time, it also authenticates the identity of Branch A. If the private key can decrypt the fifth message and the identity verification of Branch A is successful, Branch B generates the second IPSec SA.

[0160] In this way, both end devices have generated IPSec SAs. The two end devices use the IPSec SAs they generated respectively to negotiate and establish an IPSec tunnel (as shown by the dotted line in Figure 1 ) to achieve the interactive communication between branch devices.

[0161] Based on the same inventive concept, the embodiments of the present application also provide a communication device corresponding to the communication method. Refer to Figure 5 , Figure 5 A communication device provided by an embodiment of the present application. The device is applied to the first branch device. The first branch device accesses the central device and establishes a first IPSec tunnel with the central device. The device includes;

[0162] A sending unit 510, configured to send a first message to the central device through the first IPSec tunnel. The first message includes the public key generated by the first branch device and the identity information of the second branch device, so that when the central device determines that a second IPSec tunnel has been established with the second branch device according to the identity information of the second branch device, the central device sends a second message to the second branch device through the second IPSec tunnel. The second message includes the public key generated by the first branch device;

[0163] A receiving unit 520, configured to receive, through the first IPSec tunnel, a third message forwarded by the central device and sent by the second branch device, where the third message is sent by the second branch device to the central device after calculating a private key using the public key and verifying all messages exchanged between the first branch device and the second branch device using the private key;

[0164] A generating unit 530, configured to generate a first IPSec SA if the private key calculated using the public key can decrypt the third message and verify all the messages;

[0165] Optionally, the device further includes: a first negotiation unit (not shown in the figure), configured to perform IKE security policy negotiation with the second branch device;

[0166] A generating unit (not shown in the figure), configured to generate the public key when the IKE security policy negotiation is successful;

[0167] Optionally, the receiving unit 520 is further configured to receive, through the first IPSec tunnel, a fourth message sent by the central device, where the fourth message is sent by the central device when it is determined that the second IPSec tunnel has not been established with the second branch device according to the identity information of the second branch device;

[0168] The device further includes: a second negotiation unit (not shown in the figure), configured to perform key negotiation with the second branch device according to the fourth message;

[0169] Optionally, the sending unit 510 is further configured to send, through the first IPSec tunnel, a fifth message to the central device, where the fifth message is encrypted using the private key, so that the central device forwards the fifth message to the second branch device through the second IPSec tunnel, and the second branch device decrypts the fifth message using the calculated private key and generates a second IPSec SA after successfully authenticating the identity of the first branch device;

[0170] Optionally, the first message and the fourth message are encrypted and decrypted using the key corresponding to the first IPSec tunnel; the second message is encrypted and decrypted using the key corresponding to the second IPSec tunnel.

[0171] Therefore, by applying the communication device provided in this application, through the first IPSec tunnel, the first branch device sends a first message to the central device. The first message includes the public key generated by the first branch device and the identity information of the second branch device, so that when the central device determines that the second IPSec tunnel has been established with the second branch device according to the identity information of the second branch device, it sends a second message to the second branch device through the second IPSec tunnel. The second message includes the public key generated by the first branch device; through the first IPSec tunnel, the first branch device receives the third message forwarded by the central device and sent by the second branch device. The third message is sent by the second branch device to the central device after calculating the private key using the public key and verifying all the messages exchanged between the first branch device and the second branch device using the private key; if the private key calculated using the public key can decrypt the third message and verify all the messages, the first branch device generates the first IPSec SA.

[0172] In this way, when the Spoke-Spoke networking is carried out between branch devices, the traffic for tunnel key negotiation is mutually transmitted through the IPSec tunnels established with the central device respectively, without passing through the public network, improving security; the public keys of the tunnels between branch devices do not need to perform discrete logarithm calculations in the DH algorithm again, saving computing resources. It solves the problems of inflexible IKE negotiation between existing different branches; the CPU pressure of each branch is relatively large, and the IPsec tunnel negotiation is slow; moreover, due to the DH exchange of IKE, multiple handshakes occur between branches, consuming more time.

[0173] Based on the same inventive concept, the embodiments of this application also provide a communication device corresponding to the communication method. Refer to Figure 6 , Figure 6 Another communication device provided in the embodiments of this application, the device is applied to the second branch device, the second branch device accesses the central device and establishes a second IPSec tunnel with the central device, and the device includes;

[0174] A receiving unit 610, configured to receive, through the second IPSec tunnel, a second message sent by the central device, where the second message includes the public key generated by the first branch device;

[0175] A sending unit 620, configured to, after verifying that all messages interacted between the first branch device and the second branch device pass by using a private key calculated from the public key, send a third message to the central device through the second IPSec tunnel, where the third message is encrypted by using the private key, so that the central device forwards the third message to the first branch device through a first IPSec tunnel established with the first branch device, and the first branch device can decrypt the third message by using the private key calculated from the public key and generate a first IPSec SA after verifying all messages interacted between the first branch device and the second branch device.

[0176] Optionally, the device further includes: a negotiation unit (not shown in the figure), configured to perform IKE security policy negotiation with the first branch device.

[0177] Optionally, the receiving unit 610 is further configured to receive, through the second IPSec tunnel, a fifth message forwarded by the central device and sent by the first branch device, where the fifth message is encrypted by using the private key calculated by the first branch device.

[0178] The device further includes: a generating unit (not shown in the figure), configured to generate a second IPSec SA if the private key can decrypt the fifth message and the identity authentication of the first branch device is successful.

[0179] Optionally, the second message is encrypted and decrypted by using a key corresponding to the second IPSec tunnel.

[0180] Based on the same inventive concept, an embodiment of the present application further provides a communication device corresponding to the communication method. Refer to Figure 7 , Figure 7 which is another communication device provided by an embodiment of the present application. The device is applied to a central device, where a first branch device and a second branch device are connected to the central device, and a first IPSec tunnel is established between the central device and the first branch device. The device includes:

[0181] A receiving unit 710, configured to receive, through the first IPSec tunnel, a first message sent by the first branch device, where the first message includes a public key generated by the first branch device and identity information of the second branch device;

[0182] A determining unit 720, configured to determine whether to establish a second IPSec tunnel with the second branch device according to the identity information of the second branch device;

[0183] A sending unit 730, configured to, if so, send a second message to the second branch device through the second IPSec tunnel, where the second message includes a public key generated by the first branch device;

[0184] The receiving unit 710 is further configured to receive a third message sent by the second branch device through the second IPSec tunnel, where the third message is sent by the second branch device after calculating a private key by using the public key and verifying all messages exchanged between the first branch device and the second branch device by using the private key;

[0185] The sending unit 730 is further configured to forward the third message to the first branch device through the first IPSec tunnel, so that after the first branch device decrypts the third message by using the private key calculated by using the public key and verifies all the messages, a first IPSec SA is generated.

[0186] Optionally, the sending unit 730 is further configured to, if not, send a fourth message to the first branch device through the first IPSec tunnel, so that the first branch device negotiates a key with the second branch device according to the fourth message.

[0187] Optionally, the sending unit 710 is further configured to receive a fifth message sent by the first branch device through the first IPSec tunnel, where the fifth message is encrypted by using the private key;

[0188] The sending unit 730 is further configured to forward the fifth message to the second branch device through the second IPSec tunnel, so that after the second branch device decrypts the fifth message by using the private key calculated by using the public key and successfully authenticates the identity of the first branch device, a second IPSec SA is generated.

[0189] Optionally, the first message and the fourth message are encrypted and decrypted by using a key corresponding to the first IPSec tunnel; the second message is encrypted and decrypted by using a key corresponding to the second IPSec tunnel.

[0190] Based on the same inventive concept, an embodiment of the present application further provides a network device, as Figure 8 shown, including a processor 810, a transceiver 820, and a machine-readable storage medium 830. The machine-readable storage medium 830 stores machine-executable instructions that can be executed by the processor 810. The processor 810 is prompted by the machine-executable instructions to execute the communication method provided by the embodiment of the present application. The foregoing Figure 5 、 Figure 6 、 Figure 7 shown communication device may be adopted asFigure 8 Implementation of the network device hardware structure shown.

[0191] The above computer-readable storage medium 830 may include a random access memory (abbreviation: RAM in English: Random Access Memory), and may also include a non-volatile memory (abbreviation: NVM in English: Non-volatile Memory), such as at least one disk memory. Optionally, the computer-readable storage medium 830 may also be at least one storage device located far from the aforementioned processor 810.

[0192] The above processor 810 may be a general-purpose processor, including a central processing unit (abbreviation: CPU in English: Central Processing Unit), a network processor (abbreviation: NP in English: Network Processor), etc.; it may also be a digital signal processor (abbreviation: DSP in English: Digital Signal Processor), an application-specific integrated circuit (abbreviation: ASIC in English: Application Specific Integrated Circuit), a field-programmable gate array (abbreviation: FPGA in English: Field-Programmable Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0193] In the embodiments of the present application, the processor 810 is caused by the machine-executable instructions read from the machine-readable storage medium 830 to be able to implement itself and call the transceiver 820 to execute the communication method described in the foregoing embodiments of the present application.

[0194] In addition, the embodiments of the present application provide a machine-readable storage medium 830. The machine-readable storage medium 830 stores machine-executable instructions. When called and executed by the processor 810, the machine-executable instructions cause the processor 810 itself and call the transceiver 82,0 to execute the communication method described in the foregoing embodiments of the present application.

[0195] For the specific implementation process of the functions and effects of each unit in the above device, please refer to the implementation process of the corresponding steps in the above method, which will not be elaborated here.

[0196] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the descriptions in the method embodiments. The device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this application. A person of ordinary skill in the art can understand and implement it without creative work.

[0197] For the communication device and machine-readable storage medium embodiments, since the method content involved is basically similar to the foregoing method embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions in the method embodiments.

[0198] The above are only the preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A communication method, characterized in that: The method is applied to a first branch device, the first branch device accesses a central device, and establishes a first IPSec tunnel with the central device, the method comprising: Sending a first message to the central device through the first IPSec tunnel, the first message including the public key generated by the first branch device and the identity information of the second branch device, so that when the central device determines that a second IPSec tunnel has been established with the second branch device based on the identity information of the second branch device, the central device sends a second message to the second branch device through the second IPSec tunnel, the second message including the public key generated by the first branch device; receiving, through the first IPSec tunnel, a third message sent by the second branch device and forwarded by the central device, wherein the third message is sent to the central device after the second branch device calculates a private key using the public key and verifies all messages exchanged between the first branch device and the second branch device using the private key; If the private key calculated using the public key can be used to decrypt the third message and all the messages can be verified, a first IPSec SA is generated.

2. The method according to claim 1, characterized in that Before sending the first message to the central device through the first IPSec tunnel, the method further includes: Performing IKE security policy negotiation with the second branch device; When the IKE security policy negotiation is successful, the public key is generated.

3. The method according to claim 1, characterized in that The method further comprises: receiving, through the first IPSec tunnel, a fourth message sent by the central device, where the fourth message is sent when the central device determines, based on the identity information of the second branch device, that the second IPSec tunnel is not established with the second branch device; Perform key negotiation with the second branch device according to the fourth message.

4. The method according to claim 1, wherein The method further comprises: A fifth message is sent to the central device through the first IPSec tunnel, and the fifth message is encrypted by the private key, so that the central device forwards the fifth message to the second branch device through the second IPSec tunnel. The second branch device uses the calculated private key to decrypt the fifth message and generates a second IPSec SA after successfully authenticating the identity of the first branch device.

5. The method according to claim 3, characterized in that The first message and the fourth message are encrypted and decrypted using the key corresponding to the first IPSec tunnel; the second message is encrypted and decrypted using the key corresponding to the second IPSec tunnel.

6. A communication method, characterized in that: The method is applied to a second branch device, the second branch device accesses a central device, and establishes a second IPSec tunnel with the central device, the method comprising: receiving, through the second IPSec tunnel, a second message sent by the central device, where the second message includes a public key generated by the first branch device; After verifying that all messages interacting between the first branch device and the second branch device have passed using the private key calculated using the public key, a third message is sent to the central device through the second IPSec tunnel. The third message is encrypted using the private key, so that the central device forwards the third message to the first branch device through the first IPSec tunnel established with the first branch device. The first branch device can decrypt the third message using the private key calculated using the public key and generate a first IPSec SA after verifying that all messages interacting between the first branch device and the second branch device have passed.

7. The method according to claim 6, characterized in that Before receiving the second encrypted message sent by the central device through the second IPSec tunnel, the method further includes: Perform IKE security policy negotiation with the first branch device.

8. The method according to claim 6, characterized in that The method further comprises: receiving, through the second IPSec tunnel, a fifth message sent by the first branch device and forwarded by the central device, where the fifth message is encrypted by the first branch device using the calculated private key; If the private key can decrypt the fifth message and the identity authentication of the first branch device is successful, a second IPSec SA is generated.

9. The method according to claim 6, characterized in that The second message is encrypted and decrypted using the key corresponding to the second IPSec tunnel.

10. A communication method, characterized in that: The method is applied to a central device, a first branch device and a second branch device are connected to the central device, and a first IPSec tunnel is established between the central device and the first branch device. The method includes: receiving, through the first IPSec tunnel, a first message sent by the first branch device, where the first message includes a public key generated by the first branch device and identity information of the second branch device; determining, based on the identity information of the second branch device, whether to establish a second IPSec tunnel with the second branch device; If yes, sending a second message to the second branch device through the second IPSec tunnel, where the second message includes the public key generated by the first branch device; Receiving, through the second IPSec tunnel, a third message sent by the second branch device, where the third message is sent after the second branch device calculates a private key using the public key and verifies all messages exchanged between the first branch device and the second branch device using the private key; The third message is forwarded to the first branch device through the first IPSec tunnel, so that the first branch device can decrypt the third message using the private key calculated by the public key and generate a first IPSec SA after verifying all the messages.

11. The method according to claim 10, characterized in that The method further comprises: If not, a fourth message is sent to the first branch device through the first IPSec tunnel, so that the first branch device performs key negotiation with the second branch device according to the fourth message.

12. The method according to claim 10, characterized in that The method further comprises: receiving, through the first IPSec tunnel, a fifth message sent by the first branch device, where the fifth message is encrypted using the private key; The fifth message is forwarded to the second branch device through the second IPSec tunnel, so that the second branch device decrypts the fifth message using the private key calculated from the public key and generates a second IPSec SA after successfully authenticating the identity of the first branch device.

13. The method according to claim 11, characterized in that The first message and the fourth message are encrypted and decrypted using the key corresponding to the first IPSec tunnel; the second message is encrypted and decrypted using the key corresponding to the second IPSec tunnel.

14. A communication device, characterized in that: The device is applied to a first branch device, the first branch device is connected to a central device, and a first IPSec tunnel is established with the central device, the device comprising: a sending unit, configured to send a first message to the central device through the first IPSec tunnel, where the first message includes a public key generated by the first branch device and identity information of the second branch device, so that when the central device determines, based on the identity information of the second branch device, that a second IPSec tunnel has been established with the second branch device, the central device sends a second message to the second branch device through the second IPSec tunnel, where the second message includes the public key generated by the first branch device; a receiving unit, configured to receive, through the first IPSec tunnel, a third message sent by the second branch device and forwarded by the central device, wherein the third message is sent to the central device after the second branch device calculates a private key using the public key and verifies all messages exchanged between the first branch device and the second branch device using the private key; The generating unit is configured to generate a first IPSec SA if the private key calculated using the public key can be used to decrypt the third message and verify all the messages.

15. A communication device, characterized in that: The device is applied to a second branch device, the second branch device accesses a central device, and establishes a second IPSec tunnel with the central device, the device comprising: a receiving unit, configured to receive, through the second IPSec tunnel, a second message sent by the central device, where the second message includes a public key generated by the first branch device; A sending unit is used to verify that all messages interacting between the first branch device and the second branch device have passed the private key calculated by the public key, and then send a third message to the central device through the second IPSec tunnel. The third message is encrypted by the private key, so that the central device forwards the third message to the first branch device through the first IPSec tunnel established with the first branch device. The first branch device can decrypt the third message using the private key calculated by the public key and generate a first IPSec SA after verifying that all messages interacting between the first branch device and the second branch device have passed.

16. A communication device, characterized in that: The device is applied to a central device, a first branch device and a second branch device are connected to the central device, and a first IPSec tunnel is established between the central device and the first branch device. The device includes: a receiving unit, configured to receive, through the first IPSec tunnel, a first message sent by the first branch device, where the first message includes a public key generated by the first branch device and identity information of the second branch device; a determining unit, configured to determine whether to establish a second IPSec tunnel with the second branch device according to the identity information of the second branch device; a sending unit, configured to send a second message to the second branch device through the second IPSec tunnel, where the second message includes the public key generated by the first branch device; The receiving unit is further configured to receive, through the second IPSec tunnel, a third message sent by the second branch device, where the third message is sent after the second branch device calculates a private key using the public key and verifies all messages exchanged between the first branch device and the second branch device using the private key; The sending unit is further configured to forward the third message to the first branch device through the first IPSec tunnel, so that the first branch device can decrypt the third message using the private key calculated from the public key and generate a first IPSec SA after verifying all the messages.

Images