An efficient and secure communication method between IPsec branch nodes
By pre-storing the correspondence of IPsec branch nodes in the central node and using the IKE protocol negotiation key, the problem that branch nodes that only support the IKE protocol cannot conduct key negotiation is solved, improving communication security.
Patent Information
- Application Number
- CN202510192476.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-20
- Publication Date
- 2025-05-02
- Estimated Expiration
- 2045-02-20
AI Technical Summary
IPsec branch nodes that only support IKE protocol cannot conduct key negotiation through GDOI or GKM protocols, resulting in low communication security.
The corresponding relationships of each IPsec branch node are pre-stored in the central node. By modifying the source and destination addresses of the communication messages, only branch nodes that support IKE protocol can negotiate the key with the central node and forward the messages through the central node.
Key negotiation between branch nodes that only support IKE protocol is implemented, which improves communication security and reduces the possibility of plain text leakage during key negotiation.
Smart Images

Figure CN119676000B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of data transmission security, and in particular to an efficient and secure communication method between IPsec branch nodes. Background Art
[0002] In an IPsec (Internet Protocol Security) communication scenario including multiple branch nodes, in order to ensure the communication security between branch nodes, the branch nodes usually negotiate the communication key through GDOI (The Group Domain of Interpretation) or GKM (Group Key Management). In addition, when negotiating the key between branch nodes in the above manner, the branch nodes need to support GDOI or GKM. However, for branch nodes that only support the IKE (Internet Key Exchange) protocol, the above manner cannot be used to negotiate the key between branch nodes, resulting in low communication security between branch nodes that only support the IKE protocol. Summary of the invention
[0003] The purpose of the embodiment of the present application is to provide an efficient and secure communication method between IPsec branch nodes to achieve key negotiation between branch nodes that only support the IKE protocol and improve the communication security between branch nodes that only support the IKE protocol. The specific technical solution is as follows:
[0004] The embodiment of the present application provides an efficient and secure communication method between IPsec branch nodes, which is applied to a central node, wherein the central node pre-stores a corresponding relationship between each IPsec branch node; the method includes:
[0005] Receive a first communication message sent by a first branch node among the IPsec branch nodes; wherein the first communication message includes a first communication ciphertext, and the first communication ciphertext is a first communication ciphertext obtained by encrypting the first communication plaintext by the first branch node using a first key;
[0006] According to the corresponding relationship, determine the IPsec branch node corresponding to the first branch node as the second branch node;
[0007] Modify the source address of the first communication message to the central network address of the central node itself, and modify the destination address of the first communication message to the first network address of the second branch node, to obtain a modified first communication message;
[0008] Sending the modified first communication message to the second branch node;
[0009] The first key is obtained through negotiation in the following manner:
[0010] receiving a first message sent by the first branch node; wherein the first message includes a first ciphertext, the first ciphertext is obtained by the first branch node encrypting a first plaintext using a second key, the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes a plaintext generated by the first branch node;
[0011] Decrypting the first ciphertext using the second key to obtain the first plaintext;
[0012] According to the corresponding relationship, determining a branch node corresponding to the first branch node as a second branch node;
[0013] Encrypt the first plaintext by using a third key to obtain a second ciphertext, and send a second message including the second ciphertext to the second branch node, so that the second branch node decrypts the second ciphertext by using the third key to obtain the first plaintext, and generates a first key for communicating with the first branch node according to the first plaintext and the second plaintext, wherein the third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node;
[0014] receiving a third message sent by the second branch node; wherein the third message includes a third ciphertext, and the third ciphertext is obtained by the second branch node encrypting the second plaintext using the third key;
[0015] Decrypting the third ciphertext using the third key to obtain the second plaintext;
[0016] The second plaintext is encrypted using the second key to obtain a fourth ciphertext, and a fourth message including the fourth ciphertext is sent to the first branch node, so that the first branch node decrypts the fourth ciphertext using the second key to obtain the second plaintext, and generates a first key for communicating with the second branch node based on the first plaintext and the second plaintext.
[0017] The embodiment of the present application also provides a key negotiation method, which is applied to a central node, wherein the central node pre-stores a corresponding relationship between each branch node; the method includes:
[0018] Receive a first message sent by a first branch node; wherein the first message includes a first ciphertext, the first ciphertext is obtained by the first branch node encrypting a first plaintext using a second key, the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes a plaintext generated by the first branch node;
[0019] Decrypting the first ciphertext using the second key to obtain the first plaintext;
[0020] According to the corresponding relationship, determining a branch node corresponding to the first branch node as a second branch node;
[0021] Encrypt the first plaintext by using a third key to obtain a second ciphertext, and send a second message including the second ciphertext to the second branch node, so that the second branch node decrypts the second ciphertext by using the third key to obtain the first plaintext, and generates a first key for communicating with the first branch node according to the first plaintext and the second plaintext, wherein the third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node;
[0022] receiving a third message sent by the second branch node; wherein the third message includes a third ciphertext, and the third ciphertext is obtained by the second branch node encrypting the second plaintext using the third key;
[0023] Decrypting the third ciphertext using the third key to obtain the second plaintext;
[0024] The second plaintext is encrypted using the second key to obtain a fourth ciphertext, and a fourth message including the fourth ciphertext is sent to the first branch node, so that the first branch node decrypts the fourth ciphertext using the second key to obtain the second plaintext, and generates a first key for communicating with the second branch node based on the first plaintext and the second plaintext.
[0025] The embodiment of the present application further provides a communication system, the communication system comprising: a central node, a plurality of branch nodes, the branch nodes comprising a first branch node and a second branch node; the central node pre-stores a correspondence between the branch nodes;
[0026] The first branch node is used to encrypt the first plaintext with the second key to obtain a first ciphertext, and send a first message including the first ciphertext to the central node; wherein the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes the plaintext generated by the first branch node;
[0027] The central node is configured to receive a first message sent by the first branch node; decrypt the first ciphertext using the second key to obtain the first plaintext; determine, according to the corresponding relationship, a branch node corresponding to the first branch node as a second branch node; encrypt the first plaintext using a third key to obtain a second ciphertext, and send a second message including the second ciphertext to the second branch node;
[0028] The second branch node is configured to receive the first message, decrypt the second ciphertext using the third key to obtain the first plaintext, generate a first key for communicating with the first branch node based on the first plaintext and the second plaintext, encrypt the second plaintext using the third key to obtain a third ciphertext, and send a third message including the third ciphertext to the central node; wherein the third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node;
[0029] The central node is further configured to receive a third message sent by the second branch node; decrypt the third ciphertext using the third key to obtain the second plaintext; encrypt the second plaintext using the second key to obtain a fourth ciphertext, and send a fourth message including the fourth ciphertext to the first branch node;
[0030] The first branch node is further configured to receive the fourth message, decrypt the fourth ciphertext using the second key to obtain the second plaintext, and generate a first key for communicating with the second branch node based on the first plaintext and the second plaintext; encrypt the first communication plaintext using the first key to obtain a first communication ciphertext, and send a first communication message including the first communication ciphertext to the central node;
[0031] The central node is further used to receive a first communication message sent by the first branch node; according to the corresponding relationship, determine a branch node corresponding to the first branch node as a second branch node; modify the source address of the first communication message to the central network address of the central node itself, and modify the destination address of the first communication message to the first network address of the second branch node, to obtain a modified first communication message; and send the modified first communication message to the second branch node;
[0032] The central node sends the message to the branch node in the following manner: the central node sends the message to the branch node according to the network address of the branch node.
[0033] The present application also provides an electronic device, including:
[0034] Memory, used to store computer programs;
[0035] The processor is used to implement any of the above-mentioned efficient and secure communication methods or key negotiation methods between IPsec branch nodes when executing the program stored in the memory.
[0036] An embodiment of the present application also provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute any of the above-mentioned efficient and secure communication methods or key negotiation methods between IPsec branch nodes.
[0037] Beneficial effects of the embodiments of the present application:
[0038] The embodiment of the present application provides an efficient and secure communication method between IPsec branch nodes, wherein the first branch node encrypts the first plaintext with the second key to obtain the first ciphertext, and sends the first message including the first ciphertext to the central node, and the central node can receive the first message, decrypt the first ciphertext with the second key to obtain the first plaintext, and encrypt the first plaintext with the third key to obtain the second ciphertext, and send the second message including the second ciphertext to the second branch node. The second branch node receives the second message, and decrypts the second ciphertext in the second message with the third key to obtain the first plaintext, and the second branch node knows the second plaintext used for key negotiation, then the second branch node can generate the first key according to the first plaintext and the second plaintext, and the first key can be used for communication between the first branch node and the second branch node. Similarly, the second branch node encrypts the second plaintext using the third key to obtain the third ciphertext, and sends the third message including the third ciphertext to the central node. The central node can receive the third message, decrypt the third ciphertext using the third key to obtain the second plaintext, and encrypt the second plaintext using the second key to obtain the fourth ciphertext, and send the fourth message including the fourth ciphertext to the first branch node. The first branch node receives the fourth message, decrypts the fourth ciphertext in the fourth message using the second key to obtain the second plaintext, and the first branch node knows the first plaintext used for key negotiation. The first branch node can generate the first key based on the first plaintext and the second plaintext, and the first key can be used for communication between the first branch node and the second branch node. That is, both the first branch node and the second branch node can obtain the first plaintext and the second plaintext, and generate the first key used for communication between the first branch node and the second branch node based on the first plaintext and the second plaintext, thereby realizing the key negotiation between the first branch node and the second branch node. Moreover, in the above process, the first branch node and the second branch node only communicate with the central node. The security of communication between the first branch node and the central node can be ensured by the second key, and the security of communication between the second branch node and the central node can be ensured by the third key, thereby reducing the possibility of leakage of the first plaintext and the second plaintext required for key negotiation between the first branch node and the second branch node, thereby reducing the possibility of other devices generating the first key based on the leaked first plaintext and the second plaintext, that is, reducing the possibility of leakage of the first key, and improving the security of communication between the first branch node and the second branch node based on the first key.In addition, the second key and the third key required for the first branch node, the second branch node to communicate with the central node are obtained through negotiation based on the IKE protocol. Therefore, the branch nodes that only support the IKE protocol can also implement the above process. It can be seen that the embodiment of the present application can realize key negotiation between branch nodes that only support the IKE protocol, thereby improving the communication security between branch nodes that only support the IKE protocol.
[0039] Of course, implementing any product or method of the present application does not necessarily require achieving all of the above advantages at the same time. BRIEF DESCRIPTION OF THE DRAWINGS
[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other embodiments can also be obtained based on these drawings.
[0041] Figure 1a It is a structural diagram of the OSI model and the TCP / IP model;
[0042] Figure 1b A flow chart of an efficient and secure communication method between IPsec branch nodes provided in an embodiment of the present application;
[0043] Figure 2 A schematic diagram of a key negotiation method provided in an embodiment of the present application;
[0044] Figure 3 Another schematic diagram of a key negotiation method according to an embodiment of the present invention;
[0045] Figure 4 A schematic diagram of a network structure provided for an embodiment of the present application;
[0046] Figure 5 A schematic diagram of another flow chart of the key negotiation method provided in the embodiment of the present application;
[0047] Figure 6 A schematic diagram of another flow chart of the key negotiation method provided in the embodiment of the present application;
[0048] Figure 7 A schematic diagram of another process of the key negotiation method provided in the embodiment of the present application;
[0049] Figure 8 Another flow chart of the efficient and secure communication method between IPsec branch nodes provided in the embodiment of the present application;
[0050] Fig. 9A schematic diagram of an interactive process of a key negotiation method and a communication method provided in an embodiment of the present application;
[0051] Fig.10 A schematic diagram of the structure of a key agreement device provided in an embodiment of the present application;
[0052] Fig.11 A schematic diagram of a structure of an efficient and secure communication device between IPsec branch nodes provided in an embodiment of the present application;
[0053] Fig.12 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0054] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field based on the present application belong to the scope of protection of the present application.
[0055] In order to more clearly explain a key agreement method, communication method, device, system and electronic device provided by the present application, some terms appearing in this document are explained below:
[0056] National cryptographic algorithm: National cryptographic algorithm is the national commercial cryptographic algorithm. The national cryptographic algorithm is the cryptographic algorithm standard and its application specification recognized and announced by the State Cryptography Administration.
[0057] IPsec: IPsec is a security and confidentiality architecture proposed by the Internet Engineering Task Force (IETF) to protect IP (Internet Protocol) layer communications using cryptography. IPsec is a protocol suite that protects IP protocols by encrypting and authenticating IP protocol packets. IPsec is applied to the network layer in the OSI (Open System Interconnection) model.
[0058] AH (Authentication Header): AH is an encapsulation mode of IPsec. AH can provide connectionless integrity, message authentication, and anti-replay attack protection for IP data packets.
[0059] ESP (Encapsulating Security Payload): ESP is an encapsulation mode of IPsec. ESP can provide confidentiality, data source authentication, connectionless integrity, transport stream confidentiality, and anti-replay attack protection for IP datagrams.
[0060] SA (Security Association): SA is used to record algorithms and data packets. It can provide parameters required for encapsulation operations when AH and / or ESP encapsulation modes are used for encapsulation operations.
[0061] IKE (Internet Key Exchange): IKE is a communication protocol used to establish SA. IKE can be used to manage the survival and exchange of symmetric keys required for encapsulation in ESP or AH encapsulation mode.
[0062] SP (Security Policy): SP is a rule used to determine whether a transmission flow needs to be processed by IPsec.
[0063] SAD (SA Database): SAD is used to store SA related information.
[0064] SPI (Security Parameter Index): SPI is the unique identifier of SA and is used to find the SA corresponding to a node in SAD.
[0065] SPD (SP Database): SPD is used to store SP related information.
[0066] TCP (Transmission Control Protocol): TCP is a communication protocol.
[0067] VPN (Virtual Private Network): VPN is an extension of a private network. A tunnel established in a public network to connect multiple LANs is called a VPN. VPN can be used to send data between two computers through a shared or public network in a way that simulates a point-to-point private link, and to ensure the integrity of the data through security protocols (such as IPsec, etc.).
[0068] DPD (Dead Peer Detection): DPD messages are used to detect whether the peer end is alive.
[0069] HASH (hash value): HASH can be used to verify data integrity and authenticate identity of messages.
[0070] Hardware cryptographic devices: hardware devices based on cryptographic algorithms, including but not limited to PCIE (peripheral component interconnect express, a high-speed serial computer expansion bus standard) cryptographic cards, USB (Universal Serial Bus) cryptographic devices, cryptographic processors in CPUs (Central Processing Units), hardware cryptographic acceleration engines, and other devices.
[0071] In order to more clearly illustrate the key negotiation method provided in the present application, the possible application scenarios of the key negotiation method provided in the present application will be exemplified below. It can be understood that the following examples are only possible application scenarios of the key negotiation method provided in the present application. In other possible embodiments, the key negotiation method provided in the present application can be applied to other possible application scenarios, and the following examples do not impose any limitations on this.
[0072] See also Figure 1a , Figure 1a The left side is a schematic diagram of the structure of the OSI model (i.e., the open system interconnection model), and the right side is a schematic diagram of the structure of the TCP / IP model (i.e., the transmission control protocol / Internet protocol model). The OSI model includes seven layers, namely: application layer, presentation layer, session layer, transport layer, network layer, data link layer, and physical layer. The TCP / IP model includes four layers, namely: application layer, transport layer, IP layer (i.e., Internet protocol layer), and network interface layer. Among them, the application layer, presentation layer, and session layer in the OSI model correspond to the application layer in the TCP / IP model, the transport layer in the OSI model corresponds to the transport layer in the TCP / IP model, the network layer in the OSI model corresponds to the IP layer in the TCP / IP model, and the data link layer and physical layer in the OSI model correspond to the network interface layer in the TCP / IP model. As explained above, IPsec is applied to the network layer in the OSI model, so correspondingly, IPsec can also be applied to the IP layer in the TCP / IP model.
[0073] In the VPN architecture of the corporate headquarters and branches, it usually includes a central node and multiple branch nodes. The communication between the central node and the branch nodes is carried out through the IPsec protocol. In addition, in order to ensure the security of communication between the branch nodes, each branch node needs to first negotiate a key before communicating.
[0074] The communication keys between branch nodes are usually negotiated through the GDOI protocol or the GKM protocol, which requires the branch nodes to support the GDOI protocol or the GKM protocol. However, for branch nodes that only support the IKE protocol, it is impossible to negotiate keys between branch nodes in the above manner, resulting in low communication security between branch nodes that only support the IKE protocol. In addition, both the GDOI protocol and the GKM protocol are relatively complex, and when a branch node joins or leaves the architecture, it will affect all other nodes in the architecture, making the key negotiation cost between branch nodes high.
[0075] Based on this, in order to realize key negotiation between branch nodes that only support the IKE protocol, reduce the key negotiation cost between branch nodes, and improve the communication security between branch nodes that only support the IKE protocol, the present application provides an efficient and secure communication method between IPsec branch nodes, which is applied to the central node, and the corresponding relationship between each IPsec branch node is pre-stored in the central node; see Figure 1b , the efficient and secure communication method between IPsec branch nodes includes:
[0076] S101: Receive a first communication message sent by a first branch node among the IPsec branch nodes.
[0077] The first communication message includes a first communication ciphertext, and the first communication ciphertext is the first communication ciphertext obtained after the first branch node encrypts the first communication plaintext by using the first key. Figure 1b The Internet Protocol Security branch node in is the IPsec branch node.
[0078] S102: Determine, according to the corresponding relationship, an IPsec branch node corresponding to the first branch node as a second branch node.
[0079] S103, modifying the source address of the first communication message to the central network address of the central node itself, and modifying the destination address of the first communication message to the first network address of the second branch node, to obtain a modified first communication message.
[0080] S104: Send the modified first communication message to the second branch node.
[0081] In the application of the embodiment of the present application, the first branch node encrypts the first plaintext with the second key to obtain the first ciphertext, and sends the first message including the first ciphertext to the central node. The central node can receive the first message, decrypt the first ciphertext with the second key to obtain the first plaintext, and encrypt the first plaintext with the third key to obtain the second ciphertext, and send the second message including the second ciphertext to the second branch node. The second branch node receives the second message, decrypts the second ciphertext in the second message with the third key to obtain the first plaintext, and the second branch node knows the second plaintext used for key negotiation. Then, the second branch node can generate the first key according to the first plaintext and the second plaintext, and the first key can be used for communication between the first branch node and the second branch node. Similarly, the second branch node encrypts the second plaintext using the third key to obtain the third ciphertext, and sends the third message including the third ciphertext to the central node. The central node can receive the third message, decrypt the third ciphertext using the third key to obtain the second plaintext, and encrypt the second plaintext using the second key to obtain the fourth ciphertext, and send the fourth message including the fourth ciphertext to the first branch node. The first branch node receives the fourth message, decrypts the fourth ciphertext in the fourth message using the second key to obtain the second plaintext, and the first branch node knows the first plaintext used for key negotiation. The first branch node can generate the first key based on the first plaintext and the second plaintext, and the first key can be used for communication between the first branch node and the second branch node. That is, both the first branch node and the second branch node can obtain the first plaintext and the second plaintext, and generate the first key used for communication between the first branch node and the second branch node based on the first plaintext and the second plaintext, thereby realizing the key negotiation between the first branch node and the second branch node. Moreover, in the above process, the first branch node and the second branch node only communicate with the central node, then the security of the communication between the first branch node and the central node can be ensured by the second key, and the security of the communication between the second branch node and the central node can be ensured by the third key, thereby reducing the possibility of the first plaintext and the second plaintext required for the key negotiation between the first branch node and the second branch node being leaked, thereby reducing the possibility of other devices generating the first key based on the leaked first plaintext and the second plaintext, that is, reducing the possibility of the first key being leaked, and improving the security of the first branch node and the second branch node communicating according to the first key. In addition, the second key and the third key required for the first branch node and the second branch node to communicate with the central node are obtained through negotiation based on the IKE protocol. Therefore, the branch nodes that only support the IKE protocol can also implement the above process. It can be seen that the embodiment of the present application can realize key negotiation between branch nodes that only support the IKE protocol, and improve the communication security between branch nodes that only support the IKE protocol.
[0082] The above S101-S104 will be described exemplarily below:
[0083] In S101, the first communication plaintext is data that the first branch node needs to send to the second branch node. The first branch node can encrypt the first communication plaintext using the first key negotiated by the aforementioned key negotiation method to obtain a first communication ciphertext, encapsulate the first communication ciphertext to obtain a first communication message including the first communication ciphertext, and send the first communication message to the central node, and the central node receives the first communication message.
[0084] In S102, when the central node receives the first communication message sent by the first branch node, it cannot know the IPsec branch node that the first branch node needs to communicate with, and also cannot know to which IPsec branch node the first communication message needs to be forwarded. Therefore, the central node needs to determine the IPsec branch node corresponding to the first branch node as the second branch node based on the pre-stored correspondence between branch nodes that can communicate, and forward the first communication message to the second branch node.
[0085] In S103, the first communication message is sent from the first branch node to the central node, and the source address and destination address of the first communication message can be recorded as IP1_0, wherein 1 means that the source address of the first communication message is the second network address of the first branch node, and 0 means that the destination address of the first communication message is the central network address of the central node.
[0086] If the modified first communication message is sent from the central node to the second branch node, the source address and destination address of the modified first communication message can be recorded as IP0_2, where 0 means that the source address of the modified first communication message is the central network address of the central node, and 2 means that the destination address of the modified first communication message is the first network address of the second branch node.
[0087] In S104, the modified first communication message is sent to the second branch node according to the destination address in the modified first communication message.
[0088] The second branch node sends a communication message to the first branch node in the same manner as Figure 1b The method in the illustrated embodiment is the same and will not be described again here.
[0089] The above S101-S104 have been described exemplarily, see Figure 1bIn the embodiment shown, the efficient and secure communication method between IPsec branch nodes provided by the present application relies on the first key obtained through negotiation. Based on this, the present application also provides a key negotiation method. The key negotiation method provided by the present application will be first exemplarily described below. The key negotiation method provided by the present application is applied to the central node, and the corresponding relationship between each branch node is pre-stored in the central node; see Figure 2 , the key negotiation methods include:
[0090] S201: Receive a first message sent by a first branch node.
[0091] Among them, the first message includes a first ciphertext, the first ciphertext is obtained by the first branch node using the second key to encrypt the first plaintext, the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes the plaintext generated by the first branch node.
[0092] S202: Decrypt the first ciphertext using the second key to obtain a first plaintext.
[0093] S203: Determine, according to the corresponding relationship, a branch node corresponding to the first branch node as the second branch node.
[0094] S204, encrypt the first plaintext using the third key to obtain the second ciphertext, and send the second message including the second ciphertext to the second branch node, so that the second branch node decrypts the second ciphertext using the third key to obtain the first plaintext, and generates a first key for communicating with the first branch node based on the first plaintext and the second plaintext.
[0095] The third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node.
[0096] S205: Receive a third message sent by the second branch node.
[0097] The third message includes a third ciphertext, and the third ciphertext is obtained by encrypting the second plaintext by the second branch node using a third key.
[0098] S206: Decrypt the third ciphertext using the third key to obtain the second plaintext.
[0099] S207, encrypt the second plaintext using the second key to obtain a fourth ciphertext, and send the fourth message including the fourth ciphertext to the first branch node, so that the first branch node decrypts the fourth ciphertext using the second key to obtain the second plaintext, and generates a first key for communicating with the second branch node based on the first plaintext and the second plaintext.
[0100] By selecting this embodiment, on the one hand, the first branch node encrypts the first plaintext with the second key to obtain the first ciphertext, and sends the first message including the first ciphertext to the central node. The central node can receive the first message, decrypt the first ciphertext with the second key to obtain the first plaintext, and encrypt the first plaintext with the third key to obtain the second ciphertext, and send the second message including the second ciphertext to the second branch node. The second branch node receives the second message, decrypts the second ciphertext in the second message with the third key to obtain the first plaintext, and the second branch node knows the second plaintext used for key negotiation. Then, the second branch node can generate the first key according to the first plaintext and the second plaintext, and the first key can be used for communication between the first branch node and the second branch node. Similarly, the second branch node encrypts the second plaintext using the third key to obtain the third ciphertext, and sends the third message including the third ciphertext to the central node. The central node can receive the third message, decrypt the third ciphertext using the third key to obtain the second plaintext, and encrypt the second plaintext using the second key to obtain the fourth ciphertext, and send the fourth message including the fourth ciphertext to the first branch node. The first branch node receives the fourth message, decrypts the fourth ciphertext in the fourth message using the second key to obtain the second plaintext, and the first branch node knows the first plaintext used for key negotiation. The first branch node can generate the first key based on the first plaintext and the second plaintext, and the first key can be used for communication between the first branch node and the second branch node. That is, both the first branch node and the second branch node can obtain the first plaintext and the second plaintext, and generate the first key used for communication between the first branch node and the second branch node based on the first plaintext and the second plaintext, thereby realizing the key negotiation between the first branch node and the second branch node. Moreover, in the above process, the first branch node and the second branch node only communicate with the central node, then the security of the communication between the first branch node and the central node can be ensured by the second key, and the security of the communication between the second branch node and the central node can be ensured by the third key, thereby reducing the possibility of the first plaintext and the second plaintext required for the key negotiation between the first branch node and the second branch node being leaked, thereby reducing the possibility of other devices generating the first key based on the leaked first plaintext and the second plaintext, that is, reducing the possibility of the first key being leaked, and improving the security of the first branch node and the second branch node communicating according to the first key. In addition, the second key and the third key required for the first branch node and the second branch node to communicate with the central node are obtained through negotiation based on the IKE protocol. Therefore, the branch nodes that only support the IKE protocol can also implement the above process. It can be seen that the embodiment of the present application can realize key negotiation between branch nodes that only support the IKE protocol, and improve the communication security between branch nodes that only support the IKE protocol.
[0101] On the other hand, since the IKE protocol is simpler than the GDOI protocol and the GKM protocol, and the embodiment of the present application can realize key negotiation between branch nodes that only support the IKE protocol, compared with the key negotiation method based on the GDOI protocol and the GKM protocol, the cost of negotiating the first key in the embodiment of the present application is lower, that is, the embodiment of the present application can reduce the key negotiation cost between branch nodes.
[0102] The above S201-S207 will be described exemplarily below:
[0103] In S201, the naming of the central node and the branch node is set according to the function of each node in the network architecture. In different network architectures, the naming of the central node and the branch node may be different. For example, the branch node may be called GM (Group Member) and the central node may be called KS (Key Server).
[0104] The correspondence between the branch nodes refers to the correspondence between two branch nodes that need to perform key negotiation and establish a communication connection. For example, assuming that branch node 1 needs to perform key negotiation with branch node 2, and branch node 5 needs to perform key negotiation with branch node 10, the correspondence pre-stored in the central node is: the correspondence between branch node 1 and branch node 2, and the correspondence between branch node 5 and branch node 10. The correspondence can be stored in the central node in any form such as a table, array, etc.
[0105] The user can configure the correspondence between the branch nodes through the correspondence configuration interface of the central node. Specifically, the user can enter the relevant information of the two branch nodes that need to establish a communication connection in the correspondence configuration interface to establish a correspondence between the two branch nodes. The relevant information may include: the identification of each branch node, the network address of each branch node used to establish a communication connection with another branch node; the relevant information may also include: the identification of each branch node, the network address of each branch node used to establish a communication connection with another branch node, and the key obtained in advance by each branch node and the central node through IKE key negotiation.
[0106] The central node and the first branch node perform key negotiation in advance through the IKE protocol to obtain a second key for communication between the central node and the first branch node, and establish a communication connection between the central node and the first branch node. The communication connection between the central node and the first branch node is hereinafter referred to as tunnel IKE_SA1, and the second key is referred to as key 1. The first branch node can be any branch node in the network architecture. The IKE protocol in this application may refer to the IKEv1 version of the protocol, the IKEv2 version of the protocol, or an IKE protocol that complies with the national encryption algorithm standard 0022-2014 / 2024. This application does not impose any restrictions on the type and version of the IKE protocol.
[0107] The plaintext generated by the first branch node is a plaintext that conforms to the IKE protocol format. The first plaintext including the plaintext generated by the first branch node may refer to: the first plaintext only includes the plaintext generated by the first branch node. The first plaintext including the plaintext generated by the first branch node may also refer to: in addition to the plaintext generated by the first branch node, the first plaintext also includes one or more of the hash value of the first message, the security association of the first branch node, and the ID load. Exemplarily, the first plaintext may include: the plaintext generated by the first branch node, the hash value of the first message, the security association of the first branch node, and the ID load; or, the first plaintext may include: the plaintext generated by the first branch node, the hash value of the first message; or, the first plaintext may include: the plaintext generated by the first branch node, the hash value of the first message, and the security association of the first branch node.
[0108] The first branch node can use key 1 to encrypt the first plaintext to obtain a first ciphertext, encapsulate the first ciphertext to obtain a first message including the first ciphertext, and send the first message to the central node, and the central node receives the first message.
[0109] In S202, after receiving the first message, the central node may use key 1 to decrypt the first ciphertext in the first message to obtain the first plaintext.
[0110] In S203, since the central node pre-stores the correspondence between the branch nodes that need to perform key negotiation, the central node can determine the branch node corresponding to the first branch node through the correspondence stored in itself, that is, determine the branch node that needs to perform key negotiation with the first branch node as the second branch node.
[0111] In S204, the central node and the second branch node perform key negotiation in advance through the IKE protocol to obtain a third key used for communication between the central node and the second branch node, and establish a communication connection between the central node and the second branch node. Hereinafter, the communication connection between the central node and the second branch node is recorded as tunnel IKE_SA2, and the third key is recorded as key 2.
[0112] Since the first branch node needs to negotiate a key with the second branch node, it is necessary to enable both the first branch node and the second branch node to obtain the plaintext used by both parties for key negotiation, and the second branch node knows the second plaintext used by itself for key negotiation. Therefore, the central node needs to send the first plaintext to the second branch node so that the second branch node can obtain the plaintext used by both parties for key negotiation. The central node can encrypt the first plaintext with key 2 to obtain the second ciphertext, encapsulate the second ciphertext, obtain the second message including the second ciphertext, and send the second message to the second branch node.
[0113] The second branch node receives the second message, and uses key 2 to decrypt the second ciphertext in the second message to obtain the first plaintext. At this time, the second branch node has obtained the first plaintext, and knows the second plaintext used for key negotiation. Then the second branch node can generate a first key based on the first plaintext and the second plaintext, and the first key can be used for communication between the first branch node and the second branch node. In the present application, the first branch node and the second branch node can generate the first key based on the first plaintext and the second plaintext by using the AES (Advanced Encryption Standard) key generation algorithm to generate the first key based on the first plaintext and the second plaintext. The first branch node and the second branch node can also generate the first key based on the first plaintext and the second plaintext by using the RSA (Rivest-Shamir-Adleman, an asymmetric encryption algorithm) key generation algorithm to generate the first key based on the first plaintext and the second plaintext.
[0114] The plaintext generated by the second branch node is a plaintext that conforms to the IKE protocol format. The second plaintext including the plaintext generated by the second branch node may refer to: the second plaintext only includes the plaintext generated by the second branch node. The second plaintext including the plaintext generated by the second branch node may also refer to: in addition to the plaintext generated by the second branch node, the second plaintext also includes one or more of the hash value of the third message, the security association of the second branch node, and the ID load. Exemplarily, the second plaintext may include: the plaintext generated by the second branch node, the hash value of the third message, the security association of the second branch node, and the ID load; or, the second plaintext may include: the plaintext generated by the second branch node, the hash value of the third message; or, the second plaintext may include: the plaintext generated by the second branch node, the hash value of the third message, and the security association of the second branch node.
[0115] In S205, as described in S204, the first branch node and the second branch node both obtain the plaintext used by both parties for key negotiation, and in S204, the second branch node has obtained the plaintext used by both parties for key negotiation. The first branch node knows its own first plaintext used for key negotiation. Therefore, the second branch node needs to send its second plaintext used for key negotiation to the central node, so that the central node sends the second plaintext to the first branch node, so that the first branch node can obtain the plaintext used by both parties for key negotiation.
[0116] The second branch node can use key 2 to encrypt the second plaintext to obtain a third ciphertext, encapsulate the third ciphertext to obtain a third message including the third ciphertext, and send the third message to the central node, which receives the third message.
[0117] In S206, after receiving the third message, the central node may use key 2 to decrypt the third ciphertext in the third message to obtain the second plaintext.
[0118] In S207, as described in S205, the central node needs to send the second plaintext to the first branch node so that the first branch node can obtain the plaintext used by both parties for key negotiation. The central node can use key 1 to encrypt the second plaintext to obtain a fourth ciphertext, encapsulate the fourth ciphertext to obtain a fourth message including the fourth ciphertext, and send the fourth message to the first branch node.
[0119] The first branch node receives the fourth message, and decrypts the fourth ciphertext in the fourth message using key 1 to obtain the second plaintext. At this point, the first branch node has obtained the second plaintext, and knows the first plaintext used for key negotiation, so the first branch node can generate a first key based on the first plaintext and the second plaintext, and the first key can be used for communication between the first branch node and the second branch node.
[0120] The aforementioned S201-S207 has been exemplarily described above. It can be understood that a message sent by a branch node to the central node may be for key negotiation with other branch nodes, or may be for communication with the central node. Therefore, when the central node receives the first message sent by the first branch node and the third message sent by the second branch node, it needs to determine whether the received message is a message for key negotiation.
[0121] Based on this, in a possible embodiment, see Figure 3 , the key negotiation methods include:
[0122] S201: Receive a first message sent by a first branch node.
[0123] S202: Decrypt the first ciphertext using the second key to obtain a first plaintext.
[0124] S208: Determine whether the first message is a message used for key negotiation between the first branch node and the second branch node.
[0125] If the judgment result is yes, that is, the first message is a message used for key negotiation between the first branch node and the second branch node, S2031 is executed; if the judgment result is no, that is, the first message is not a message used for key negotiation between the first branch node and the second branch node, the process is ended, that is, the subsequent S2031-S2073 is not executed.
[0126] S2031: If the first message is a message used for key negotiation between the first branch node and the second branch node, determine, according to the corresponding relationship, a branch node corresponding to the first branch node as the second branch node.
[0127] S2041, encrypt the first plaintext using the third key to obtain a second ciphertext.
[0128] S2042: Set the source address of the second message to the central network address of the central node itself, and set the destination address of the second message to the first network address of the second branch node.
[0129] The second message includes a second ciphertext.
[0130] S2043: Send the second message to the second branch node.
[0131] S205: Receive a third message sent by the second branch node.
[0132] S206: Decrypt the third ciphertext using the third key to obtain the second plaintext.
[0133] S209: Determine whether the third message is a message used for key negotiation between the first branch node and the second branch node.
[0134] If the judgment result is yes, that is, the third message is a message used for key negotiation between the first branch node and the second branch node, execute S2071; if the judgment result is no, that is, the third message is not a message used for key negotiation between the first branch node and the second branch node, then the process ends, that is, the subsequent S2071-S2073 are not executed.
[0135] S2071: If the second message is a message used for key negotiation between the first branch node and the second branch node, encrypt the second plaintext using the second key to obtain a fourth ciphertext.
[0136] S2072: Set the source address of the fourth message to the central network address of the central node itself, and set the destination address of the fourth message to the second network address of the first branch node.
[0137] The fourth message includes a fourth ciphertext.
[0138] S2073: Send the fourth message to the first branch node.
[0139] By selecting this embodiment, the central node can determine whether the received message is a message used for key negotiation between the first branch node and the second branch node when receiving the first message and the third message, thereby avoiding the situation where the communication message between the branch node and the central node is sent to other branch nodes, thereby ensuring the communication security between the branch node and the central node.
[0140] Figure 3 The process shown is similar to Figure 2 The only difference is that S208 is added between S202 and S203, S203 is replaced by S2031, S204 is refined into S2041, S2042, S2043, S209 is added between S206 and S207, and S207 is refined into S2071, S2072, S2073. Since S201-S202, S205-S206 have been mentioned above, Figure 2The relevant instructions are explained in detail and will not be repeated here. Only S208, S2031, S2041-S2043, S209 and S2071-S2073 will be explained below.
[0141] In S208, see Figure 4 The network structure diagram shown in Figure 4 The branch node 1 in the figure is the first branch node, the branch node 2 is the second branch node, the subnet 0 is the network address of the central node, the subnet 1_0 is the network address used when the first branch node communicates with the central node, that is, the second network address of the aforementioned first branch node, the subnet 1_1 is the network address used when the first branch node and the second branch node negotiate keys, that is, the first network address of the aforementioned second branch node, the subnet 2_0 is the network address used when the second branch node communicates with the central node, the subnet 2_1 is the network address used when the second branch node and the first branch node negotiate keys, the communication connection 1 is the communication connection between the central node and the first branch node, denoted as IKE_SA1, the communication connection 2 is the communication connection between the central node and the second branch node, denoted as IKE_SA2, and the tunnel 1_2 is the communication connection between the first branch node and the second branch node.
[0142] If the central node stores the corresponding relationship in a table in advance, the structure of the cache table for storing the corresponding relationship in the central node may be as follows, which is hereinafter referred to as cache table 1:
[0143] | Sequence number | IP1 | IP2 | Subnet segment 1 | Subnet segment 2 | Derived key index bit 1 | Derived key index bit 2 |
[0144] Among them, IP1 is the IP information of the first branch node, IP2 is the IP information of the second branch node, and subnet segment 1 is the network address used by the first branch node and the second branch node for key negotiation. Figure 4 Subnet 1_1 in the subnet, subnet segment 2 is the network address used by the second branch node and the first branch node for key negotiation, that is, Figure 4 In subnet 2_1, derived key index bit 1 is an identifier used to find the second key in the hardware cryptographic device, and derived key index bit 2 is an identifier used to find the third key in the hardware cryptographic device.
[0145] Since cache table 1 only includes the correspondence between branch nodes that require key negotiation, and the network address used by the branch node to communicate with the central node is different from the network address used by the branch node to negotiate keys with other branch nodes, if after receiving the first message, the network address included in the first message can be found in the pre-stored correspondence, then the first message can be considered to be a message used for key negotiation between the first branch node and the second branch node, and the following S2031-S2043 can be executed.
[0146] Exemplarily, assuming that subnet segment 1 is subnet 1_1 and subnet segment 2 is subnet 2_1, if the network address included in the first message is subnet 1_1, then it can be considered that the first message is a message used for key negotiation between the first branch node and the second branch node. If the network address included in the first message is subnet 1_0, then it can be considered that the first message is not a message used for key negotiation between the first branch node and the second branch node.
[0147] In the example of cache table 1, the second key is stored in the hardware cryptographic device, and only the index bit of the second key is stored in cache table 1. In other possible embodiments, if the system does not have high security requirements, the second key can also be directly stored in the software database of the central node in ciphertext form. The second key in this application refers to the set of all keys obtained through IKE negotiation, including but not limited to protection keys, session keys, integrity verification keys, etc.
[0148] In S2031, it can be understood that if the first message is not a message for key negotiation between the first branch node and the second branch node, the central node does not need to forward the first message to the second branch node, and does not need to determine the second branch node that needs to negotiate the key with the first branch node according to the corresponding relationship. Therefore, in this embodiment, the central node determines the branch node corresponding to the first branch node as the second branch node according to the corresponding relationship only when the first message is a message for key negotiation between the first branch node and the second branch node. In the case where the first message is not a message for key negotiation between the first branch node and the second branch node, there is no need to perform subsequent steps.
[0149] In S2041, the central node obtains the second ciphertext in the same manner as the central node obtains the second ciphertext in the aforementioned S204. Please refer to the relevant description in the aforementioned S204, which will not be repeated here.
[0150] In S2042, the first message is sent from the first branch node to the central node, and the source address and destination address of the first message can be recorded as IP1_0, where 1 means that the source address of the first message is the second network address of the first branch node, and 0 means that the destination address of the first message is the central network address of the central node.
[0151] If the second message is sent from the central node to the second branch node, the source address and destination address of the second message can be recorded as IP0_2, where 0 means that the source address of the second message is the central network address of the central node, and 2 means that the destination address of the second message is the first network address of the second branch node.
[0152] In S2043, the second message is sent to the second branch node according to the subnet segment 2 stored in the above cache table.
[0153] In S209, the method of determining whether the third message is a message for key negotiation between the first branch node and the second branch node is the same as the method of determining whether the first message is a message for key negotiation between the first branch node and the second branch node in S208. The only difference is that the first message is sent by the first branch node and the third message is sent by the second branch node. The determination methods in S209 and S208 are exactly the same, so they are not repeated here. If it is determined that the third message is a message for key negotiation between the first branch node and the second branch node, the following S2071-S2073 can be executed.
[0154] In S2071, it can be understood that if the third message is not a message for key negotiation between the first branch node and the second branch node, the central node does not need to forward the third message to the first branch node, and there is no need to encrypt the second plaintext with the second key. Therefore, in this embodiment, the central node encrypts the second plaintext with the second key to obtain the fourth ciphertext only when the third message is a message for key negotiation between the first branch node and the second branch node. In the case where the third message is not a message for key negotiation between the first branch node and the second branch node, there is no need to perform subsequent steps.
[0155] The way in which the central node obtains the fourth ciphertext is the same as the way in which the central node obtains the fourth ciphertext in the aforementioned S207. Please refer to the relevant instructions in the aforementioned S207 and will not be repeated here.
[0156] In S2072, the third message is sent from the second branch node to the central node, and the source address and destination address of the third message can be recorded as IP2_0, where 2 means that the source address of the third message is the first network address of the second branch node, and 0 means that the destination address of the first message is the central network address of the central node.
[0157] If the fourth message is sent from the central node to the first branch node, the source address and destination address of the fourth message can be recorded as IP0_1, where 0 means that the source address of the fourth message is the central network address of the central node, and 1 means that the destination address of the fourth message is the second network address of the first branch node.
[0158] In S2073, the fourth message is sent to the first branch node according to the subnet segment 1 stored in the above cache table.
[0159] The above has been Figure 3 The illustrated embodiment is explained, and it can be understood that when using the IKE protocol for communication between a branch node and a central node, it is necessary to comply with the specifications of the IKE protocol: the branch node needs to send three messages to the central node. In the above example, the first message is the first message sent by the branch node to the central node, and the third message is the second message sent by the branch node to the central node. Based on this, in order to comply with the specifications of the IKE protocol and improve the applicability of the key negotiation method provided by this application, in a possible embodiment, see Figure 5 After executing S201-S207, the key agreement method provided by the present application further includes:
[0160] S501: Receive a fifth message sent by a first branch node.
[0161] The fifth message includes a fifth ciphertext; the fifth ciphertext is obtained by encrypting the third plaintext by the first branch node using the second key;
[0162] It can be understood that after executing S201-S207, the first branch node and the second branch node have negotiated to obtain the first key for communication between the first branch node and the second branch node. Therefore, the third plaintext may include data that has no practical meaning, or may be empty.
[0163] The first branch node can use key 1 to encrypt the third plaintext to obtain a fifth ciphertext, encapsulate the fifth ciphertext to obtain a fifth message including the fifth ciphertext, and send the fifth message to the central node, which receives the fifth message.
[0164] S502, decrypt the fifth ciphertext using the second key to obtain a third plaintext.
[0165] After receiving the fifth message, the central node can use key 1 to decrypt the fifth ciphertext in the fifth message to obtain the third plaintext.
[0166] S503: Encrypt the third plaintext using the third key to obtain a sixth ciphertext, and send a sixth message including the sixth ciphertext to the second branch node.
[0167] The central node can use key 2 to encrypt the third plaintext to obtain a sixth ciphertext, encapsulate the sixth ciphertext to obtain a sixth message including the sixth ciphertext, and send the sixth message to the second branch node.
[0168] This embodiment is selected to implement the step of sending the third message from the branch node to the central node by receiving the fifth message including the fifth ciphertext sent by the first branch node, where the fifth ciphertext is obtained by encrypting the third plaintext by the first branch node using the second key; decrypting the fifth ciphertext using the second key to obtain the third plaintext, encrypting the third plaintext using the third key to obtain the sixth ciphertext, and sending the sixth message including the sixth ciphertext to the second branch node, so as to implement the step of sending the third message from the branch node to the central node, so that the key negotiation method provided in the present application complies with the specifications of the IKE protocol, thereby improving the applicability of the key negotiation method provided in the present application.
[0169] The above has been Figure 5 The embodiment shown is described. In one possible embodiment, Figure 5 Based on the embodiment shown, the first plain text also includes: the first security parameter index of the first branch node and the second network address of the first branch node; the second plain text also includes: the second security parameter index of the second branch node and the first network address of the second branch node. Figure 6 , the key negotiation method provided in this application includes:
[0170] S201: Receive a first message sent by a first branch node.
[0171] S2021. Decrypt the first ciphertext using the second key to obtain a first plaintext, and store a first security parameter index included in the first plaintext.
[0172] S203: Determine, according to the corresponding relationship, a branch node corresponding to the first branch node as the second branch node.
[0173] S204: Encrypt the first plaintext using the third key to obtain a second ciphertext, and send a second message including the second ciphertext to the second branch node.
[0174] S205: Receive a third message sent by the second branch node.
[0175] S2061. Decrypt the third ciphertext using the third key to obtain a second plaintext, and store a second security parameter index included in the second plaintext.
[0176] S207: Encrypt the second plaintext using the second key to obtain a fourth ciphertext, and send a fourth message including the fourth ciphertext to the first branch node.
[0177] S501: Receive a fifth message sent by a first branch node.
[0178] S502, decrypt the fifth ciphertext using the second key to obtain a third plaintext.
[0179] S503: Encrypt the third plaintext using the third key to obtain a sixth ciphertext, and send a sixth message including the sixth ciphertext to the second branch node.
[0180] S504: Store the first network address of the second branch node corresponding to the first security parameter index.
[0181] S505 , storing the second network address of the first branch node corresponding to the second security parameter index.
[0182] Figure 6 The process shown is similar to Figure 5 The only difference is that S202 is replaced by S2021, S206 is replaced by S2061, and S504 and S505 are added after S503. Since S201, S203-S205, and S207 have been Figure 2 S501-S503 have been described in the previous Figure 5 The relevant descriptions are explained in detail, so they will not be repeated here. Only S2021, S2061, S504-S505 will be explained below.
[0183] In S2021, the first security parameter index is an identifier of the SA of the first branch node, which can be used to find the SA of the first branch node in the SAD. After obtaining the first plaintext, the central node stores the first security parameter index in the first plaintext.
[0184] In S2061, the second security parameter index is an identifier of the SA of the second branch node, which can be used to find the SA of the second branch node in the SAD. After obtaining the second plaintext, the central node stores the second security parameter index in the second plaintext.
[0185] In S504, the correspondence between the security parameter index and the network address can be stored in any form such as a table, an array, etc. If the correspondence between the security parameter index and the network address is stored in the form of a table, the structure of the table can be as follows, and the table is hereinafter referred to as cache table 2:
[0186] | Serial Number | SPI | IP dst |
[0187] Since the first security parameter index and the second security parameter index have been stored in the central node in the aforementioned S2021 and S2061, when S504 is executed, the cache table 2 may be as follows:
[0188] | Serial Number | SPI | IP dst |
[0189] | 1 | SPI_i | |
[0190] | 2 | SPI_r | |
[0191] Wherein, SPI_i is the first security parameter index, and SPI_r is the second security parameter index. After executing S504, cache table 2 may be as follows:
[0192] | Serial Number | SPI | IP dst |
[0193] | 1 | SPI_i | IP2 |
[0194] | 2 | SPI_r | |
[0195] Among them, IP2 is the first network address of the second branch node.
[0196] In S505, as in the cache table 2 in S504, after executing S505, the cache table 2 may be as follows:
[0197] | Serial Number | SPI | IP dst |
[0198] | 1 | SPI_i | IP 2 |
[0199] | 2 | SPI_r | IP 1 |
[0200] Among them, IP1 is the second network address of the first branch node.
[0201] The above has been Figure 6The example shown is explained. It is understandable that due to network fluctuations or environmental influences, the first branch node or the second branch node may be offline and unable to communicate normally, resulting in the branch node not receiving a response and repeatedly sending messages, thereby wasting resources. Based on this, in order to be able to detect whether the branch node is in a normal communication state to avoid the branch node repeatedly sending messages due to not receiving a response, resulting in a waste of resources, in a possible embodiment, see Figure 7 The key negotiation method provided in this application also includes:
[0202] S701: Receive a first DPD message sent by a first branch node.
[0203] The first DPD message is encrypted using the second key.
[0204] S702: Decrypt the first DPD message using the second key to obtain a decrypted first DPD message.
[0205] S703, encrypt the decrypted first DPD message using the third key to obtain a second DPD message, and send the second DPD message to the second branch node, so that the second branch node sends a third DPD message to the central node in response to the second DPD message; the third DPD message is encrypted using the third key.
[0206] S704: Receive a third DPD message sent by the second branch node.
[0207] S705: Decrypt the third DPD message using the third key to obtain a decrypted third DPD message.
[0208] S706: Use the second key to encrypt the decrypted third DPD message to obtain a fourth DPD message, and send the fourth DPD message to the first branch node, so that the first branch node responds to the fourth DPD message and determines that the second branch node is in a normal communication state.
[0209] Figure 7 The first peer survival detection message in is the first DPD message; the second peer survival detection message is the second DPD message; the third peer survival detection message is the third DPD message; and the fourth peer survival detection message is the fourth DPD message. Figure 7In the illustrated embodiment, it can be understood that the first branch node sends a first DPD message to the central node so that the central node can forward the first DPD message to the second central node for detecting whether the second central node is in a normal communication state. The central node decrypts the first DPD message using the second key and re-encrypts it using the third key to obtain the second DPD message, and sends the second DPD message to the second branch node, thereby forwarding the first DPD message.
[0210] If the first branch node can receive the third DPD message sent by the second branch node in response to the second DPD message, it can be considered that the second branch node is in a normal communication state. The central node decrypts the third DPD message using the third key and re-encrypts it using the second key to obtain the fourth DPD message, and sends the fourth DPD message to the first branch node to forward the third DPD message. Therefore, the first branch node receiving the fourth DPD message is equivalent to receiving the third DPD message.
[0211] The second branch node detects whether the first branch node is in a normal communication state. Figure 7 The execution method in the illustrated embodiment is the same and will not be described again here.
[0212] The key negotiation method provided in this application has been described above as an example. Figure 1b The efficient and secure communication method between IPsec branch nodes shown in the present application is further described by way of example.
[0213] according to Figure 1b It can be seen from the efficient and secure communication method between IPsec branch nodes shown in the embodiment that the communication method between the first branch node and the second branch node is not direct communication between the two branch nodes, but communication through forwarding by the central node, that is, the first branch node and the second branch node communicate by sending a communication message to the central node through one branch node, and the central node forwards it to another branch node. In other words, the communication connection established between the first branch node and the second branch node is composed of the communication connection between the first branch node and the central node, and the communication connection between the second branch node and the central node. If the communication connection established between the first branch node and the second branch node is recorded as tunnel 1_2, the communication connection between the first branch node and the central node is recorded as sub-tunnel 1_0, and the communication connection between the second branch node and the central node is recorded as sub-tunnel 0_2, then tunnel 1_2 is composed of sub-tunnel 1_0 and sub-tunnel 0_2.
[0214] In one possible embodiment, Figure 1b The corresponding relationship in the illustrated embodiment may refer to the corresponding relationship between the security parameter index of the branch node and the network address; the first communication message also includes the first security parameter index of the first branch node, see Figure 8 , the communication methods include:
[0215] S101: Receive a first communication message sent by a first branch node among the IPsec branch nodes.
[0216] S1021: Extract a first security parameter index from a first communication message.
[0217] S1022: Search for a network address corresponding to the first security parameter index as the target network address.
[0218] S1031, modifying the source address of the first communication message to the central network address of the central node itself, and modifying the destination address of the first communication message to the target network address, to obtain a modified first communication message.
[0219] S104: Send the modified first communication message to the second branch node.
[0220] Figure 8 The process shown is similar to Figure 1b The only difference is that S102 is subdivided into S1021 and S1022, and S103 is replaced by S1031. Figure 1b The relevant descriptions are explained in detail, so they will not be repeated here. Only S1021, S1022, and S1031 will be explained below.
[0221] In S1021, Figure 8 In the illustrated embodiment, the correspondence between the security parameter index of the branch node and the network address may be stored in the form of the aforementioned cache table 2.
[0222] The first communication message includes the first security parameter index, and the central node can extract the first security parameter index from the first communication message.
[0223] In S1022, referring to cache table 2 shown in S505, the network address corresponding to the first security parameter index SPI_i is IP2, and IP2 is used as the target network address, which is the network address of the branch node with which the first branch node needs to communicate.
[0224] In S1031, as described above, the target network address is the network address of the branch node with which the first branch node needs to communicate. Therefore, when the central node forwards the first communication message, it is necessary to modify the destination address of the first communication message to the target network address, and modify the source address of the first communication message to the central network address of the central node itself, so as to realize the forwarding of the first communication message and send the first communication message to the branch node with which the first branch node needs to communicate.
[0225] In order to facilitate understanding of the key agreement method and communication method in the present application, the present application provides a schematic diagram of the interaction process between a first branch node, a central node and a second branch node, such as Fig. 9 As shown, the key negotiation process and communication process between the first branch node and the second branch node include:
[0226] S901, the central node writes the IP information and subnet segments of the first branch node and the second branch node into cache table 1.
[0227] S902: The central node and the first branch node obtain a second key through IKE protocol negotiation and establish a communication connection.
[0228] S903: The central node and the second branch node obtain a third key through IKE negotiation and establish a communication connection.
[0229] S904, the central node writes the derived key index bit into cache table 1.
[0230] S904 is that the central node writes the identifier of the second key: derived key index bit 1 in cache table 1, and stores the identifier of the third key: derived key index bit 1.
[0231] S905: The first branch node sends a first message to the central node.
[0232] The structure of the first message is: HDR, K1{HASH (1), SA, Ni, IDci, IDcr}.
[0233] Wherein, HDR (header) is the message header of the first message; K1{·} represents the first ciphertext obtained by encrypting the first plaintext with the second key; HASH (1) is the hash value of the first message; SA is the security association of the first branch node; Ni is the plaintext included in the first plaintext and generated by the first branch node; IDci and IDcr are both ID payloads.
[0234] S906: The central node uses the second key to decrypt the first ciphertext in the first message to obtain a first plaintext.
[0235] S907: The central node determines, according to the ID field included in the first plaintext, whether the first message is a message used for key negotiation between the first branch node and the second branch node.
[0236] If yes, then S908 is executed; if no, then the process ends. The ID field is the subnet segment information. The central node searches in cache table 1 according to the ID field in the first plaintext. If cache table 1 includes the ID field in the first plaintext, the first message is a message for key negotiation between the first branch node and the second branch node; if cache table 1 does not include the ID field in the first plaintext, the first message is not a message for key negotiation between the first branch node and the second branch node.
[0237] In this embodiment, the ID field in the first plaintext is the subnet segment 1 in cache table 1.
[0238] S908: If the first message is a message used for key negotiation between the first branch node and the second branch node, the central node records the first security parameter index SPI_i included in the SA of the first message in cache table 2.
[0239] S909, the central node encrypts the first plaintext using the third key to obtain a second ciphertext.
[0240] S910, the central node sets the source address of the second message including the second ciphertext to the central network address of the central node itself, sets the destination address of the second message to the subnet segment 2 in the cache table 1, and sends the second message to the second branch node.
[0241] The structure of the second message is: HDR, K2{HASH(1), SA, Ni, IDci, IDcr}.
[0242] Wherein, HDR is the message header of the second message; K2{·} represents the second ciphertext obtained by encrypting the first plaintext using the third key; HASH(1) is the hash value of the second message; SA is the security association of the first branch node; Ni is the plaintext included in the first plaintext and generated by the first branch node; IDci and IDcr are both ID payloads.
[0243] At this time, after receiving the second message, the second branch node can generate the first key according to the first plaintext and the second plaintext.
[0244] S911, the second branch node sends a third message to the central node.
[0245] The structure of the third message is: HDR, K2{HASH (2), SA, Nr, IDci, IDcr}.
[0246] Wherein, HDR is the message header of the third message; K2{·} represents the third ciphertext obtained by encrypting the second plaintext using the third key; HASH(2) is the hash value of the third message; SA is the security association of the second branch node; Ni is the plaintext included in the second plaintext and generated by the second branch node; IDci and IDcr are both ID payloads.
[0247] S912: The central node decrypts the third ciphertext in the third message using the third key to obtain a second plaintext.
[0248] S913: The central node determines, according to the ID field included in the second plaintext, whether the third message is a message used for key negotiation between the first branch node and the second branch node.
[0249] If yes, then S914 is executed; if no, then the process ends. The ID field is the subnet segment information. The central node searches in cache table 1 according to the ID field in the second plaintext. If cache table 1 includes the ID field in the second plaintext, the third message is a message for the first branch node and the second branch node to perform key negotiation; if cache table 1 does not include the ID field in the second plaintext, the third message is not a message for the first branch node and the second branch node to perform key negotiation.
[0250] In this embodiment, the ID field in the second plaintext is the subnet segment 2 in cache table 1.
[0251] S914: If the third message is a message used for key negotiation between the first branch node and the second branch node, the central node records the second security parameter index SPI_r included in the SA of the third message in cache table 2.
[0252] S915, the central node encrypts the second plaintext using the second key to obtain a fourth ciphertext.
[0253] S916, the central node sets the source address of the fourth message including the fourth ciphertext to the central network address of the central node itself, sets the destination address of the fourth message to subnet segment 1 in cache table 1, and sends the fourth message to the first branch node.
[0254] The structure of the fourth message is: HDR, K1{HASH(2), SA, Nr, IDci, IDcr}.
[0255] Wherein, HDR is the message header of the fourth message; K1{·} represents the fourth ciphertext obtained by encrypting the second plaintext by using the second key; HASH(2) is the hash value of the fourth message; SA is the security association of the second branch node; Ni is the plaintext included in the second plaintext and generated by the second branch node; IDci and IDcr are both ID payloads.
[0256] At this time, after receiving the fourth message, the first branch node can generate the first key according to the first plaintext and the second plaintext.
[0257] S917: The first branch node sends a fifth message to the central node.
[0258] The structure of the fifth message is: HDR, K1{HASH(3)}.
[0259] Wherein, HDR is the message header of the fifth message; K1{·} represents the fifth ciphertext obtained by encrypting the third plaintext by using the second key; and HASH(3) is the hash value of the fifth message.
[0260] S918: The central node decrypts the fifth ciphertext in the fifth message using the second key to obtain a third plaintext.
[0261] S919, the central node encrypts the third plaintext using the third key to obtain a sixth ciphertext.
[0262] S920: The central node records the second network address of the first branch node and the first network address of the second branch node in cache table 2.
[0263] S921, the central node sets the source address of the sixth message including the sixth ciphertext to the central network address of the central node itself, sets the destination address of the sixth message to the subnet segment 2 in the cache table 1, and sends the sixth message to the second branch node.
[0264] The structure of the sixth message is: HDR, K2{HASH(3)}.
[0265] Wherein, HDR is the message header of the sixth message; K2{·} represents the sixth ciphertext obtained by encrypting the third plaintext using the third key; and HASH(3) is the hash value of the sixth message.
[0266] S922, the second branch node sends the communication message 1 to the central node.
[0267] The structure of communication message 1 is: IP2_0, ESP / AH{SPI_r, SEQ, Kr{DATA}}.
[0268] Among them, IP2_0 is the source address and destination address of the communication message 1; ESP / AH{·} represents the encapsulation mode of the communication message 1; SPI_r is the security parameter index of the second branch node, that is, the aforementioned second security parameter index; SEQ is the anti-replay sequence number; Kr{DATA} represents the ciphertext obtained by encrypting the communication data DATA using the first key Kr.
[0269] S923, the central node searches cache table 2 according to SPI_r in communication message 1, determines that communication message 1 needs to be sent to the first branch node, modifies the source address and destination address of communication message 1, obtains communication message 2, and sends communication message 2 to the first branch node.
[0270] The structure of communication message 2 is: IP0_1, ESP / AH{SPI_r, SEQ, Kr{DATA}}.
[0271] Among them, IP0_1 is the source address and destination address of the communication message 2; ESP / AH{·} represents the encapsulation mode of the communication message 2; SPI_r is the security parameter index of the second branch node, that is, the aforementioned second security parameter index; SEQ is the anti-replay sequence number; Kr{DATA} represents the ciphertext obtained by encrypting the communication data DATA using the first key Kr.
[0272] S924, the first branch node sends the communication message 3 to the central node.
[0273] The structure of communication message 3 is: IP1_0, ESP / AH{SPI_i, SEQ, Ki{DATA}}.
[0274] Among them, IP1_0 is the source address and destination address of the communication message 3; ESP / AH{·} represents the encapsulation mode of the communication message 3; SPI_i is the security parameter index of the first branch node, that is, the aforementioned first security parameter index; SEQ is the anti-replay sequence number; Ki{DATA} represents the ciphertext obtained by encrypting the communication data DATA using the first key Ki.
[0275] S925, the central node searches cache table 2 according to SPI_i in communication message 3, determines that communication message 3 needs to be sent to the second branch node, modifies the source address and destination address of communication message 3, obtains communication message 4, and sends communication message 4 to the first branch node.
[0276] The structure of communication message 4 is: IP0_2, ESP / AH{SPI_i, SEQ, Ki{DATA}}.
[0277] Among them, IP0_2 is the source address and destination address of the communication message 4; ESP / AH{·} represents the encapsulation mode of the communication message 4; SPI_i is the security parameter index of the first branch node, that is, the aforementioned first security parameter index; SEQ is the anti-replay sequence number; Ki{DATA} represents the ciphertext obtained by encrypting the communication data DATA using the first key Ki.
[0278] This embodiment is selected. Since the IPsec protocol itself is not modified in this embodiment, no additional configuration is required for the branch nodes. Only the source address and destination address of the message need to be modified and configured at the central node. Therefore, this embodiment can be compatible with multiple devices and multiple types of IKE protocols. In addition, the central node only performs cryptographic operations through the IKE protocol during the key negotiation phase, and during the communication process, only matching queries need to be performed in cache table 2, as well as the modification of the source address and destination address of the message, thereby reducing the amount of calculation of the central node and improving the processing efficiency of the central node. Compared with the solution of establishing two tunnels for the central node and two branch nodes respectively, the embodiment of the present application does not require calculation when performing data protection, which can reduce the load of the central node. Compared with the method of establishing a tunnel within a tunnel, additional message overhead can be saved, a single message can accommodate more load data, and the actual bandwidth can be improved.
[0279] Currently, branch nodes usually exchange public IP addresses through the central node, and finally establish IPsec tunnels between branch nodes through the public IP addresses. However, in the above method, the IPsec tunnel needs to be established through the public network, which cannot cope with the scenario where none of the branch nodes have public IP addresses.
[0280] In the embodiment of the present application, the branch node establishes a tunnel with the central node. For the branch node, it only needs to know the subnet address of other branch nodes to access the subnet resources of other branch nodes through the central node, without the need to establish a tunnel through the public network. Therefore, in the embodiment of the present application, the branch nodes do not need to have public network addresses, and can cope with scenarios such as intranet penetration, which is fully practical. At the same time, the branch node only establishes a tunnel with a trusted central node, reducing the risk of being attacked in public network communications.
[0281] Corresponding to the above-mentioned efficient and secure communication method between IPsec branch nodes, the embodiment of the present application further provides a communication system, the communication system comprising: a central node, a plurality of branch nodes, the branch nodes comprising a first branch node and a second branch node; the central node pre-stores the corresponding relationship between the branch nodes;
[0282] The first branch node is used to encrypt the first plaintext with the second key to obtain the first ciphertext, and send the first message including the first ciphertext to the central node; wherein the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes the plaintext generated by the first branch node;
[0283] The central node is used to receive a first message sent by a first branch node; decrypt the first ciphertext using a second key to obtain a first plaintext; determine a branch node corresponding to the first branch node as a second branch node according to the corresponding relationship; encrypt the first plaintext using a third key to obtain a second ciphertext, and send a second message including the second ciphertext to the second branch node;
[0284] The second branch node is used to receive the first message, decrypt the second ciphertext using the third key to obtain the first plaintext, generate the first key for communicating with the first branch node according to the first plaintext and the second plaintext, encrypt the second plaintext using the third key to obtain the third ciphertext, and send the third message including the third ciphertext to the central node; wherein the third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node;
[0285] The central node is further configured to receive a third message sent by the second branch node; decrypt the third ciphertext using the third key to obtain a second plaintext; encrypt the second plaintext using the second key to obtain a fourth ciphertext, and send a fourth message including the fourth ciphertext to the first branch node;
[0286] The first branch node is further configured to receive a fourth message, decrypt the fourth ciphertext using the second key to obtain a second plaintext, and generate a first key for communicating with the second branch node based on the first plaintext and the second plaintext; encrypt the first communication plaintext using the first key to obtain a first communication ciphertext, and send the first communication message including the first communication ciphertext to the central node;
[0287] The central node is further used to receive the first communication message sent by the first branch node; determine the branch node corresponding to the first branch node as the second branch node according to the corresponding relationship; modify the source address of the first communication message to the central network address of the central node itself, and modify the destination address of the first communication message to the first network address of the second branch node to obtain the modified first communication message; and send the modified first communication message to the second branch node;
[0288] The central node sends the message to the branch node in the following manner: the central node sends the message to the branch node according to the network address of the branch node.
[0289] Corresponding to the aforementioned key negotiation method, the embodiment of the present application further provides a key negotiation device, which is applied to a central node, and the corresponding relationship between each branch node is pre-stored in the central node; see Fig.10 , the device comprises:
[0290] The first message receiving module 101 is used to receive a first message sent by a first branch node; wherein the first message includes a first ciphertext, the first ciphertext is obtained by the first branch node encrypting the first plaintext using the second key, the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes the plaintext generated by the first branch node;
[0291] A first plaintext obtaining module 102, configured to decrypt the first ciphertext using the second key to obtain the first plaintext;
[0292] A branch node determination module 103, configured to determine, according to the corresponding relationship, a branch node corresponding to the first branch node as a second branch node;
[0293] The second message sending module 104 is used to encrypt the first plaintext by using the third key to obtain the second ciphertext, and send the second message including the second ciphertext to the second branch node, so that the second branch node decrypts the second ciphertext by using the third key to obtain the first plaintext, and generates a first key for communicating with the first branch node according to the first plaintext and the second plaintext, wherein the third key is obtained by the second branch node and the central node in advance through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node;
[0294] The third message receiving module 105 is used to receive the third message sent by the second branch node; wherein the third message includes a third ciphertext, and the third ciphertext is obtained by the second branch node encrypting the second plaintext using the third key;
[0295] A second plaintext obtaining module 106 is used to decrypt the third ciphertext using a third key to obtain a second plaintext;
[0296] The fourth message sending module 107 is used to encrypt the second plaintext using the second key to obtain a fourth ciphertext, and send the fourth message including the fourth ciphertext to the first branch node, so that the first branch node decrypts the fourth ciphertext using the second key to obtain the second plaintext, and generates a first key for communicating with the second branch node based on the first plaintext and the second plaintext.
[0297] In a possible embodiment, the device further includes:
[0298] A first judgment module, used to judge whether the first message is a message used for key negotiation between the first branch node and the second branch node;
[0299] Determining, according to the corresponding relationship, a branch node corresponding to the first branch node as the second branch node includes:
[0300] If the first message is a message used for key negotiation between the first branch node and the second branch node, determining, according to the corresponding relationship, a branch node corresponding to the first branch node as the second branch node;
[0301] Sending a second message including a second ciphertext to a second branch node includes:
[0302] Setting the source address of the second message to the central network address of the central node itself, and setting the destination address of the second message to the first network address of the second branch node; the second message includes a second ciphertext;
[0303] Sending the second message to the second branch node;
[0304] The device also includes:
[0305] A second judgment module, used to judge whether the third message is a message used for key negotiation between the first branch node and the second branch node;
[0306] Encrypting the second plaintext using the second key to obtain a fourth ciphertext, and sending a fourth message including the fourth ciphertext to the first branch node, including:
[0307] If the second message is a message used for key negotiation between the first branch node and the second branch node, encrypting the second plaintext using the second key to obtain a fourth ciphertext;
[0308] Setting the source address of the fourth message to the central network address of the central node itself, and setting the destination address of the fourth message to the second network address of the first branch node; the fourth message includes a fourth ciphertext;
[0309] The fourth message is sent to the first branch node.
[0310] In a possible embodiment, the device further includes:
[0311] A fifth message receiving module, used to receive a fifth message sent by the first branch node; wherein the fifth message includes a fifth ciphertext, wherein the fifth ciphertext is obtained by encrypting the third plaintext by the first branch node using the second key;
[0312] A third plaintext obtaining module, used for decrypting the fifth ciphertext using the second key to obtain a third plaintext;
[0313] The sixth message sending module is used to encrypt the third plaintext by using the third key to obtain the sixth ciphertext, and send the sixth message including the sixth ciphertext to the second branch node.
[0314] In a possible embodiment, the first plaintext also includes: a first security parameter index of the first branch node and a second network address of the first branch node; the second plaintext also includes: a second security parameter index of the second branch node and a first network address of the second branch node;
[0315] The first ciphertext is decrypted using the second key to obtain the first plaintext, including:
[0316] Decrypting the first ciphertext using the second key to obtain a first plaintext, and storing a first security parameter index included in the first plaintext;
[0317] The third ciphertext is decrypted using the third key to obtain the second plaintext, including:
[0318] Decrypting the third ciphertext using the third key to obtain a second plaintext, and storing a second security parameter index included in the second plaintext;
[0319] After the step of sending the sixth ciphertext to the second branch node, the apparatus further includes:
[0320] A first storage module, configured to store a first network address of a second branch node corresponding to a first security parameter index;
[0321] The second storage module is used to store the second network address of the first branch node corresponding to the second security parameter index.
[0322] In a possible embodiment, the device further includes:
[0323] A first DPD message receiving module, used to receive a first DPD message sent by a first branch node, where the first DPD message is encrypted using a second key;
[0324] A first decryption module, used to decrypt the first DPD message using the second key to obtain a decrypted first DPD message;
[0325] a second DPD message sending module, configured to encrypt the decrypted first DPD message using a third key to obtain a second DPD message, and send the second DPD message to the second branch node, so that the second branch node sends a third DPD message to the central node in response to the second DPD message; the third DPD message is encrypted using the third key;
[0326] A third DPD message receiving module, used to receive a third DPD message sent by the second branch node;
[0327] A second decryption module, used to decrypt the third DPD message using a third key to obtain a decrypted third DPD message;
[0328] The fourth DPD message sending module is used to encrypt the decrypted third DPD message using the second key to obtain a fourth DPD message, and send the fourth DPD message to the first branch node, so that the first branch node responds to the fourth DPD message and determines that the second branch node is in a normal communication state.
[0329] Corresponding to the above-mentioned efficient and secure communication method between IPsec branch nodes, the embodiment of the present application also provides an efficient and secure communication device between IPsec branch nodes, which is applied to a central node, and the corresponding relationship between each IPsec branch node is pre-stored in the central node; see Fig.11 , the device comprises:
[0330] The receiving module 111 is used to receive a first communication message sent by a first branch node among the IPsec branch nodes; wherein the first communication message includes a first communication ciphertext, which is a first communication ciphertext obtained by encrypting the first communication plaintext by the first branch node using a first key; the first key is obtained by negotiation according to any of the aforementioned key negotiation methods;
[0331] A determination module 112, configured to determine, according to the corresponding relationship, an IPsec branch node corresponding to the first branch node as a second branch node;
[0332] The modification module 113 is used to modify the source address of the first communication message to the central network address of the central node itself, and modify the destination address of the first communication message to the first network address of the second branch node, so as to obtain a modified first communication message;
[0333] The sending module 114 is configured to send the modified first communication message to the second branch node.
[0334] In a possible embodiment, the corresponding relationship is a corresponding relationship between a security parameter index of a branch node and a network address; the first communication message also includes a first security parameter index of a first branch node;
[0335] Determining, according to the corresponding relationship, a branch node corresponding to the first branch node as the second branch node includes:
[0336] Extracting a first security parameter index from the first communication message;
[0337] Finding a network address corresponding to the first security parameter index as the target network address;
[0338] Modifying the destination address of the first communication message to the first network address of the second branch node includes:
[0339] The destination address of the first communication message is modified to the target network address.
[0340] The present application also provides an electronic device, such as Fig.12 As shown, including:
[0341] A memory 121, used for storing computer programs;
[0342] The processor 122 is used to execute the program stored in the memory 121 to implement the following steps:
[0343] Receive a first message sent by a first branch node; wherein the first message includes a first ciphertext, the first ciphertext is obtained by the first branch node encrypting a first plaintext using a second key, the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes a plaintext generated by the first branch node;
[0344] Decrypting the first ciphertext using the second key to obtain the first plaintext;
[0345] According to the corresponding relationship, determine a branch node corresponding to the first branch node as the second branch node;
[0346] The first plaintext is encrypted using a third key to obtain a second ciphertext, and a second message including the second ciphertext is sent to the second branch node, so that the second branch node decrypts the second ciphertext using the third key to obtain the first plaintext, and generates a first key for communicating with the first branch node according to the first plaintext and the second plaintext, wherein the third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node;
[0347] receiving a third message sent by the second branch node; wherein the third message includes a third ciphertext, and the third ciphertext is obtained by encrypting the second plaintext by the second branch node using a third key;
[0348] Decrypting the third ciphertext using the third key to obtain the second plaintext;
[0349] The second plaintext is encrypted using the second key to obtain a fourth ciphertext, and a fourth message including the fourth ciphertext is sent to the first branch node, so that the first branch node decrypts the fourth ciphertext using the second key to obtain the second plaintext, and generates a first key for communicating with the second branch node based on the first plaintext and the second plaintext.
[0350] or,
[0351] Receive a first communication message sent by a first branch node among the IPsec branch nodes; wherein the first communication message includes a first communication ciphertext, which is a first communication ciphertext obtained by encrypting the first communication plaintext by the first branch node using a first key; the first key is obtained by negotiation according to any of the aforementioned key negotiation methods;
[0352] According to the corresponding relationship, determine the IPsec branch node corresponding to the first branch node as the second branch node;
[0353] Modify the source address of the first communication message to the central network address of the central node itself, and modify the destination address of the first communication message to the first network address of the second branch node, to obtain a modified first communication message;
[0354] The modified first communication message is sent to the second branch node.
[0355] In addition, the electronic device may further include a communication bus and / or a communication interface, and the processor 122, the communication interface, and the memory 121 communicate with each other via the communication bus.
[0356] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.
[0357] The communication interface is used for communication between the above electronic device and other devices.
[0358] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.
[0359] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.
[0360] In another embodiment provided in the present application, a computer-readable storage medium is also provided, which stores a computer program. When the computer program is executed by a processor, the steps of the above-mentioned efficient and secure communication method or key negotiation method between any of the IPsec branch nodes are implemented.
[0361] In another embodiment provided by the present application, a computer program product including instructions is also provided, which, when executed on a computer, enables the computer to execute any of the efficient and secure communication methods or key negotiation methods between IPsec branch nodes in the above embodiments.
[0362] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a solid-state hard disk (SSD), etc.
[0363] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.
[0364] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the system, device, electronic device, computer-readable storage medium, and computer program product containing instructions, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.
[0365] The above description is only a preferred embodiment of the present application and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application are included in the protection scope of the present application.
Claims
1. An efficient and secure communication method between IPsec branch nodes, characterized in that: Applied to a central node, the central node pre-stores the corresponding relationship between each IPsec branch node; the method includes: Receive a first communication message sent by a first branch node among the IPsec branch nodes; wherein the first communication message includes a first communication ciphertext, and the first communication ciphertext is a first communication ciphertext obtained by encrypting the first communication plaintext by the first branch node using a first key; According to the corresponding relationship, determine the IPsec branch node corresponding to the first branch node as the second branch node; Modify the source address of the first communication message to the central network address of the central node itself, and modify the destination address of the first communication message to the first network address of the second branch node, to obtain a modified first communication message; Sending the modified first communication message to the second branch node; The first key is obtained through negotiation in the following manner: receiving a first message sent by the first branch node; wherein the first message includes a first ciphertext, the first ciphertext is obtained by the first branch node encrypting a first plaintext using a second key, the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes a plaintext generated by the first branch node; Decrypting the first ciphertext using the second key to obtain the first plaintext; According to the corresponding relationship, determining a branch node corresponding to the first branch node as a second branch node; Encrypt the first plaintext by using a third key to obtain a second ciphertext, and send a second message including the second ciphertext to the second branch node, so that the second branch node decrypts the second ciphertext by using the third key to obtain the first plaintext, and generates a first key for communicating with the first branch node according to the first plaintext and the second plaintext, wherein the third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node; receiving a third message sent by the second branch node; wherein the third message includes a third ciphertext, and the third ciphertext is obtained by the second branch node encrypting the second plaintext using the third key; Decrypting the third ciphertext using the third key to obtain the second plaintext; The second plaintext is encrypted using the second key to obtain a fourth ciphertext, and a fourth message including the fourth ciphertext is sent to the first branch node, so that the first branch node decrypts the fourth ciphertext using the second key to obtain the second plaintext, and generates a first key for communicating with the second branch node based on the first plaintext and the second plaintext.
2. The method according to claim 1, characterized in that The corresponding relationship is the corresponding relationship between the security parameter index of the branch node and the network address; the first communication message also includes the first security parameter index of the first branch node; The determining, according to the corresponding relationship, a branch node corresponding to the first branch node as a second branch node includes: Extracting the first security parameter index in the first communication message; Searching for a network address corresponding to the first security parameter index as a target network address; The modifying the destination address of the first communication message to the first network address of the second branch node includes: The destination address of the first communication message is modified to the target network address.
3. A key negotiation method, characterized in that: Applied to a central node, the central node pre-stores the corresponding relationship between the branch nodes; the method includes: Receive a first message sent by a first branch node; wherein the first message includes a first ciphertext, the first ciphertext is obtained by the first branch node encrypting a first plaintext using a second key, the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes a plaintext generated by the first branch node; Decrypting the first ciphertext using the second key to obtain the first plaintext; According to the corresponding relationship, determining a branch node corresponding to the first branch node as a second branch node; Encrypt the first plaintext by using a third key to obtain a second ciphertext, and send a second message including the second ciphertext to the second branch node, so that the second branch node decrypts the second ciphertext by using the third key to obtain the first plaintext, and generates a first key for communicating with the first branch node according to the first plaintext and the second plaintext, wherein the third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node; receiving a third message sent by the second branch node; wherein the third message includes a third ciphertext, and the third ciphertext is obtained by the second branch node encrypting the second plaintext using the third key; Decrypting the third ciphertext using the third key to obtain the second plaintext; The second plaintext is encrypted using the second key to obtain a fourth ciphertext, and a fourth message including the fourth ciphertext is sent to the first branch node, so that the first branch node decrypts the fourth ciphertext using the second key to obtain the second plaintext, and generates a first key for communicating with the second branch node based on the first plaintext and the second plaintext.
4. The method according to claim 3, characterized in that The method further comprises: determining whether the first message is a message used for key negotiation between the first branch node and the second branch node; The determining, according to the corresponding relationship, a branch node corresponding to the first branch node as a second branch node includes: If the first message is a message used for key negotiation between the first branch node and the second branch node, determining, according to the corresponding relationship, a branch node corresponding to the first branch node as the second branch node; The sending the second message including the second ciphertext to the second branch node includes: Setting the source address of the second message to the central network address of the central node itself, and setting the destination address of the second message to the first network address of the second branch node; the second message includes the second ciphertext; Sending the second message to the second branch node; The method further comprises: determining whether the third message is a message used for key negotiation between the first branch node and the second branch node; The step of encrypting the second plaintext by using the second key to obtain a fourth ciphertext, and sending a fourth message including the fourth ciphertext to the first branch node includes: If the second message is a message used for key negotiation between the first branch node and the second branch node, encrypting the second plaintext by using the second key to obtain a fourth ciphertext; Setting the source address of the fourth message to the central network address of the central node itself, and setting the destination address of the fourth message to the second network address of the first branch node; the fourth message includes the fourth ciphertext; The fourth message is sent to the first branch node.
5. The method according to claim 3, characterized in that: The method further comprises: receiving a fifth message sent by the first branch node; wherein the fifth message includes a fifth ciphertext, wherein the fifth ciphertext is obtained by encrypting the third plaintext by the first branch node using the second key; Decrypting the fifth ciphertext using the second key to obtain the third plaintext; The third plaintext is encrypted using the third key to obtain a sixth ciphertext, and a sixth message including the sixth ciphertext is sent to the second branch node.
6. The method according to claim 5, characterized in that The first plaintext also includes: a first security parameter index of the first branch node and a second network address of the first branch node; the second plaintext also includes: a second security parameter index of the second branch node and a first network address of the second branch node; The decrypting the first ciphertext by using the second key to obtain the first plaintext includes: decrypting the first ciphertext using the second key to obtain the first plaintext, and storing the first security parameter index included in the first plaintext; The decrypting the third ciphertext by using the third key to obtain the second plaintext includes: Decrypting the third ciphertext using the third key to obtain the second plaintext, and storing the second security parameter index included in the second plaintext; After the step of sending the sixth ciphertext to the second branch node, the method further includes: Corresponding to the first security parameter index, storing a first network address of the second branch node; Corresponding to the second security parameter index, a second network address of the first branch node is stored.
7. The method according to claim 3, characterized in that The method further comprises: receiving a first DPD message sent by the first branch node, where the first DPD message is encrypted using the second key; decrypting the first DPD message using the second key to obtain a decrypted first DPD message; Encrypting the decrypted first DPD message using the third key to obtain a second DPD message, and sending the second DPD message to the second branch node, so that the second branch node sends a third DPD message to the central node in response to the second DPD message; the third DPD message is encrypted using the third key; receiving a third DPD message sent by the second branch node; Decrypting the third DPD message using the third key to obtain a decrypted third DPD message; The decrypted third DPD message is encrypted using the second key to obtain a fourth DPD message, and the fourth DPD message is sent to the first branch node, so that the first branch node responds to the fourth DPD message and determines that the second branch node is in a normal communication state.
8. A communication system, characterized in that: The communication system comprises: a central node and a plurality of branch nodes, wherein the branch nodes comprise a first branch node and a second branch node; the central node pre-stores a corresponding relationship between the branch nodes; The first branch node is used to encrypt the first plaintext with the second key to obtain a first ciphertext, and send a first message including the first ciphertext to the central node; wherein the second key is obtained in advance by the first branch node and the central node through IKE key negotiation, and the first plaintext includes the plaintext generated by the first branch node; The central node is configured to receive a first message sent by the first branch node; decrypt the first ciphertext using the second key to obtain the first plaintext; determine, according to the corresponding relationship, a branch node corresponding to the first branch node as a second branch node; encrypt the first plaintext using a third key to obtain a second ciphertext, and send a second message including the second ciphertext to the second branch node; The second branch node is configured to receive the first message, decrypt the second ciphertext using the third key to obtain the first plaintext, generate a first key for communicating with the first branch node based on the first plaintext and the second plaintext, encrypt the second plaintext using the third key to obtain a third ciphertext, and send a third message including the third ciphertext to the central node; wherein the third key is obtained in advance by the second branch node and the central node through IKE key negotiation, and the second plaintext includes the plaintext generated by the second branch node; The central node is further configured to receive a third message sent by the second branch node; decrypt the third ciphertext using the third key to obtain the second plaintext; encrypt the second plaintext using the second key to obtain a fourth ciphertext, and send a fourth message including the fourth ciphertext to the first branch node; The first branch node is further configured to receive the fourth message, decrypt the fourth ciphertext using the second key to obtain the second plaintext, and generate a first key for communicating with the second branch node based on the first plaintext and the second plaintext; encrypt the first communication plaintext using the first key to obtain a first communication ciphertext, and send a first communication message including the first communication ciphertext to the central node; The central node is further used to receive a first communication message sent by the first branch node; according to the corresponding relationship, determine a branch node corresponding to the first branch node as a second branch node; modify the source address of the first communication message to the central network address of the central node itself, and modify the destination address of the first communication message to the first network address of the second branch node, to obtain a modified first communication message; and send the modified first communication message to the second branch node; The central node sends the message to the branch node in the following manner: the central node sends the message to the branch node according to the network address of the branch node.
9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, for implementing the method described in any one of claims 1-2 or 3-7 when executing a program stored in a memory.
10. A computer program product, characterized in that When it is run on a computer, the computer is enabled to execute any of the methods described in claims 1-2 or 3-7.
Citation Information
Patent Citations
Novel IPsec key distribution method and distribution system
CN115037459A
Tunnel communication method, relay node, branch node and tunnel communication system
CN115037685A