CN112787803B - Method and equipment for secure communication - Google Patents

Method and equipment for secure communication Download PDF

Info

Publication number
CN112787803B
CN112787803B CN201911253333.4A CN201911253333A CN112787803B CN 112787803 B CN112787803 B CN 112787803B CN 201911253333 A CN201911253333 A CN 201911253333A CN 112787803 B CN112787803 B CN 112787803B
Authority
CN
China
Prior art keywords
ipsec
key
indication information
aging period
template
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911253333.4A
Other languages
Chinese (zh)
Other versions
CN112787803A (en
Inventor
房永龙
楚远征
邹东棋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to PCT/CN2020/116962 priority Critical patent/WO2021082813A1/en
Priority to EP20881986.2A priority patent/EP4040752A4/en
Publication of CN112787803A publication Critical patent/CN112787803A/en
Priority to US17/732,165 priority patent/US20220255911A1/en
Application granted granted Critical
Publication of CN112787803B publication Critical patent/CN112787803B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The embodiment of the application discloses a method and equipment for secure communication. After the same key negotiation templates are established by the two-end equipment, the corresponding IPSec keys in each IPSec aging period are respectively generated based on the key negotiation templates. By the method provided by the application, when the IPSec key needs to be negotiated every time, the IPSec key can be obtained by interacting the latest public key and the indication information of the current IPSec aging period and taking the key negotiation template as the basis. Even in a large-scale networking scene such as an IoT (Internet of things), the IPSec keys corresponding to the IPSec aging periods can be quickly and efficiently obtained, so that the safe communication between the devices is realized.

Description

Method and equipment for secure communication
The present application claims priority of chinese patent application with application number CN201911060960.6 entitled "internet protocol security association IPSEC SA negotiation method and apparatus" filed by china patent office on 11/01/2019, the entire contents of which are incorporated herein by reference.
Technical Field
The present application relates to the field of communications technologies, and in particular, to a method and a device for secure communications.
Background
Internet Protocol security (IPSec) is a set of framework protocols established by the Internet Engineering Task Force (IETF), and guarantees the security of communication over the Internet by using an encrypted secure transmission channel. When data packets are securely transmitted between devices based on the IPSec technology, a currently common mode is to perform Key agreement of the IPSec based on an Internet Key Exchange (IKE) protocol, and the IKE completes interaction of IPSec Security configuration parameters by interacting a plurality of session messages, thereby completing the IPSec Security Association (SA) negotiation. And carrying out security protection on the message based on the IPSec key determined by negotiation.
In the Internet of things (IoT), for example, in the Internet of things (Internet of things), the number of devices increases continuously, and if the IPSec key is still determined through negotiation by the IKE protocol, each device and other devices need to interact with a large amount of messages, which not only takes a long time and is inefficient, but also wastes a large amount of network resources.
Disclosure of Invention
Therefore, the embodiments of the present application provide a method and a device for secure communication, where when devices need to use IPSec for secure communication, IPSec keys between the devices can be quickly and efficiently obtained, so as to implement secure communication in a network. The IPSec key described in the embodiments of the present application may include an IPSec encryption key and/or an IPSec authentication key.
In a first aspect, a method for secure communication is provided, and is applied to a scenario including a first device and a second device, where the first device is an execution subject, and the method for secure communication may include: and in a second IPSec aging period of the first device, the first device receives the first indication information sent by the second device. The first indication information is used for identifying state information corresponding to a public and private key pair generated in a first IPSec aging period of the second device. And the first equipment establishes a key negotiation template according to the first indication information and the second indication information. The second indication information is used for identifying state information of a public and private key pair generated by the first device in the second IPSec aging period. The first device generates a first IPSec key according to the key negotiation template, wherein the first IPSec key is used for protecting data transmitted by the first device and the second device in a first time period.
The device is configured with an IPSec aging period in advance, and after one IPSec aging period, the public and private keys on the device are updated once. Optionally, the state information corresponding to the public and private key pair generated in each IPSec aging period is iterated according to an agreed rule when IPSec is aged and updated each time. The agreed rule may be, for example, that state information corresponding to each public and private key pair alternately appears for each IPSec aging update. The indication information (or state information corresponding to the public and private key pair generated in each IPSec aging period) may be, for example, tick values, and the alternation of the IPSec aging periods on the indicating device occurs through alternation of different tick values. The indication information may be, for example, a character string, and the alternation of IPSec aging periods on the indication device may alternately occur through different character strings.
According to the method provided by the embodiment of the application, a key negotiation template is established on two devices in advance, and when an IPSec key needs to be negotiated each time, the local terminal device can generate the IPSec key according to a received public key generated in a current IPSec aging period and sent by the opposite terminal device, the state information corresponding to the public key, a private key generated in the current IPSec aging period and the state information corresponding to the private key, and a negotiation rule of the key negotiation template. Because the technical scheme of the application does not perform the negotiation of the IPSec key based on the IKE protocol any more, compared with the method that a plurality of messages need to be interacted when the IPSec key is negotiated through the IKE protocol between two devices, the technical scheme of the application effectively reduces the number of the messages interacted between the two devices, improves the negotiation efficiency of the IPSec key and reduces the occupation of system resources. In large-scale networking scenes such as IoT and the like, under the condition of mass equipment intercommunication, mass messages interacted based on IKE protocol negotiation are greatly reduced, and the occupation of system resources is reduced.
Optionally, the key agreement template is a parallel key agreement template when the first indication information is the same as the second indication information. And when the first indication information is different from the second indication information, the key negotiation template is a cross key negotiation template. In some possible implementation manners, "receiving the first indication information sent by the second device" may specifically include: and receiving a message sent by second equipment, wherein the message carries the first indication information. The first indication information may be carried in a first field of the packet, where the first field indicates the first device to establish the key agreement template. The packet may be, for example, a keep alive (KeepAlive) packet or a Bidirectional Forwarding Detection (BFD) packet. Taking the packet as the KeepAlive packet as an example, the first field may be, for example, a Type-Length-Value (TLV) field or a TV field added to the KeepAlive packet, where a Value part in the TLV field or the TV field carries the first indication information, and a Type field in the TLV field or the TV field is used to indicate the first device to establish the key negotiation template.
Optionally, each IPSec aging period of the first device is a first duration, each IPSec aging period of the second device is a second duration, and the first duration and the second duration may be equal or unequal. And the equipment generates an IPSec key according to the key negotiation template and the negotiation rule. The negotiation rule includes: 1) The state information corresponding to the newly generated private key of the local terminal and the state information corresponding to the latest public key of the opposite terminal equipment meet the matching condition of the key negotiation template; 2) Generating an IPSec key by using the latest private key of the local terminal device and the latest public key of the opposite terminal device; 3) The public and private keys involved in generating the IPSec key cannot participate again in generating the next IPSec key. Optionally, the rule may further include: the synthesized IPSec key in the current IPSec aging period of the device is used for protecting data transmitted in the next IPSec aging period adjacent to the current IPSec aging period.
Optionally, the matching condition of the key agreement template includes: and when the key negotiation template is a parallel key negotiation template, the corresponding state information of the public key and the private key which participate in generating the IPSec key is the same. When the key negotiation template is a cross negotiation template, the state information corresponding to the public key and the private key participating in generating the IPSec key are different.
As an example, the embodiment of the present application may further include: and in a fourth IPSec aging period of the first device, receiving a first message sent by the second device in the third IPSec aging period, where the first message carries third indication information and a first public key generated by the second device in the third IPSec aging period, and the third indication information is used to indicate state information corresponding to the first public key. Optionally, the third IPSec aging period is the first IPSec aging period, and the third indication information is the same as the first indication information. Optionally, N aging periods are separated between the third IPSec aging period and the first IPSec aging period, N is a positive odd number, and the third indication information is the same as the first indication information.
The "generating the first IPSec key according to the key agreement template" may specifically include: and generating a first IPSec key according to the key negotiation template, the third indication information, the first public key, and a first private key and fourth indication information generated by the first device in a fourth IPSec aging period, wherein the fourth indication information is used for indicating state information corresponding to the first private key. Optionally, the fourth IPSec aging period is the second IPSec aging period, or M aging periods are spaced between the fourth IPSec aging period and the second IPSec aging period, where M is a positive odd number. The fourth indication information is the same as the second indication information. It can be understood that the "generating a first IPSec key according to the key negotiation template, the third indication information, the first public key, the first private key generated by the first device in the fourth IPSec aging period, and the fourth indication information" specifically may be: and judging whether the third indication information and the fourth indication information are matched with the key negotiation template, and if so, synthesizing the first IPSec key according to the first public key and the first private key. When the key agreement template is a parallel key agreement template, the matching between the third indication information and the fourth indication information with the key agreement template may be: the third indication information is the same as the fourth indication information; when the key agreement template is a cross key agreement template, the matching of the third indication information and the fourth indication information with the key agreement template may be: the third indication information and the fourth indication information are different.
As another example, the embodiment of the present application may further include: and in a sixth IPSec aging period of the first device, receiving a second message sent by the second device, where the second message carries a second public key generated by the second device in a fifth IPSec aging period and fifth indication information, where the fifth indication information indicates status information corresponding to the second public key. Optionally, an even number of IPSec aging periods are spaced between the fifth IPSec aging period and the first IPSec aging period. And generating a second IPSec key according to the key negotiation template, the second public key, the fifth indication information, and a second private key and sixth indication information generated by the first device in a current sixth IPSec aging period, wherein the sixth indication information is used for indicating state information corresponding to the second private key, and the second IPSec key is used for protecting data transmitted by the first device and the second device in a second time period. Optionally, the sixth IPSec aging period is separated from the second IPSec aging period by an even number of IPSec aging periods. Optionally, to ensure the effectiveness of secure communication, the packet transmitted between the first device and the second device may be secured by the IPSec key synthesized by the previous IPSec aging period. For example: and generating a first IPSec key in a second IPSec aging period of the first device, where the first IPSec key may be used to protect data transmitted in a next IPSec aging period of the second IPSec aging period. Optionally, the first time period and/or the second time period may correspond to a time period within one IPSec aging period, or may correspond to a time period of the entire IPSec aging period.
In the present application, under the condition that the durations of the IPSec aging periods of the first device are consistent with the durations of the IPSec aging periods of the second device, no matter whether the interval between the IPSec aging periods of the key negotiation template and the IPSec aging periods is an odd number of IPSec aging periods or an even number of IPSec aging periods, by using the embodiments of the present application, the IPSec keys of the IPSec aging periods can be quickly and efficiently negotiated, so that a reliable data base is provided for secure communication between the first device and the second device.
Optionally, the first message and the second message may be Border Gateway Protocol (BGP) messages or User Datagram Protocol (UDP) messages, or may be other proprietary messages, which is not limited in this application. In a specific implementation, the BGP message or the UDP message may be extended to carry a public key required for generating each IPSEC key and indication information for indicating status information corresponding to the public key.
Optionally, the first packet and the second packet, in addition to carrying the indication information and the public key, may further include one or more of the following security parameters: DH set, package mode, encryption algorithm, or authentication algorithm. Then, based on the scheme described in the present application, not only the IPSec key may be negotiated, but also the IPSec SA may be further negotiated, and the specific process is not described in detail in the present application.
Wherein, no matter the indication information, the public key, or the DH set, the encapsulation mode, the encryption algorithm and/or the authentication algorithm can be carried in the BGP message or the UDP message. Taking the BGP message carrying all the parameters as an example, optionally, a tunnel attribute may be newly added in the BGP message, and 6 TLV fields are extended in the tunnel attribute, where each TLV field carries one of the parameters of the indication information, the public key, the DH group, the encapsulation mode, the encryption algorithm, and the authentication algorithm. Optionally, 6 tunnel attributes may be added in the BGP message, and the 6 tunnel attributes respectively carry one of the parameters of the indication information, the public key, the DH set, the encapsulation mode, the encryption algorithm, and the authentication algorithm. The one or more security parameters may also be interacted between the devices in other manners through other messages, which is not described herein again.
In a specific implementation, the first IPSec key may be an encryption key or an authentication key, and the second IPSec key may be an encryption key or an authentication key. In this application, the encryption key may also be referred to as an IPSec encryption key, an IPSec session key, an IPSec SA encryption key, or an IPSec SA session key, and is used to encrypt and decrypt a packet. The authentication key, which may also be referred to as an IPSec authentication key or an IPSec SA authentication key, is used to authenticate a packet, for example, for an encrypted IP packet, a digital signature is generated based on the authentication key and an authentication algorithm, and integrity and authenticity of the encrypted packet are authenticated based on the digital signature, thereby ensuring secure communication.
In a second aspect, a method for secure communication is also provided, and is applied in a scenario including a first device and a second device, where the second device is an execution subject, and the method for secure communication may include: in a first IPSec aging period of second equipment, the second equipment generates first indication information, wherein the first indication information is used for indicating state information corresponding to a public and private key pair generated by the second equipment in the first IPSec aging period; the second device sends the first indication information to the first device. In this way, a data base is provided for establishing the key negotiation template between the first device and the second device, so that the IPSec key can be quickly determined through the key negotiation template, and the secure communication between the first device and the second device can be ensured.
In some possible implementation manners, the "first indication information sent by the second device to the first device" may specifically include: the second equipment sends keep-alive KeepAlive messages or Bidirectional Forwarding Detection (BFD) messages to the first equipment, and the first indication information is carried in the KeepAlive messages or the BFD messages.
In other possible implementations, the embodiments of the present application may further include: in the first IPSec aging period, the second device receives second indication information sent by the first device, wherein the second indication information is used for indicating state information corresponding to a public and private key pair generated by the first device in the second IPSec aging period; the second equipment establishes a key negotiation template according to the second indication information and the first indication information; and the second device generates a first IPSec key according to the key negotiation template, wherein the first IPSec key is used for protecting the data transmitted by the first device and the second device in the first time period.
In some possible implementation manners, the "receiving, by the second device, the second indication information sent by the first device" may specifically include: and the second equipment receives a message sent by the first equipment, wherein the message carries the second indication information. The second indication information may be carried in a second field of the packet, where the second field indicates the second device to establish the key agreement template. The packet may be, for example, a keep-alive (KeepAlive) packet or a Bidirectional Forwarding Detection (BFD) packet. Taking the packet as the KeepAlive packet as an example, the second field may be, for example, a Type-Length-Value (TLV) field or a TV field added to the KeepAlive packet, where a Value part in the TLV field or the TV field carries the second indication information, and a Type field in the TLV field or the TV field is used to indicate the second device to establish the key negotiation template.
Optionally, the first indication information is the same as the second indication information, and the key agreement template is a parallel key agreement template. Optionally, the first indication information is different from the second indication information, and the key agreement template is a cross key agreement template. According to the method provided by the embodiment of the application, a key negotiation template is established on two devices in advance, and when an IPSec key needs to be negotiated each time, the local terminal device can generate the IPSec key according to a received public key generated in a current IPSec aging period and sent by the opposite terminal device, the state information corresponding to the public key, a private key generated in the current IPSec aging period and the state information corresponding to the private key, and a negotiation rule of the key negotiation template. Because the technical scheme of the application does not perform IPSec key negotiation based on the IKE protocol any more, compared with the situation that a plurality of messages need to be interacted when the IPSec key is negotiated between two devices through the IKE protocol, the technical scheme of the application reduces the number of the interacted messages between the two devices, improves the negotiation efficiency of the IPSec key and reduces the occupation of system resources. In large-scale networking scenes such as IoT and the like, under the condition of mass equipment intercommunication, mass messages interacted based on IKE protocol negotiation are greatly reduced, and the occupation of system resources is reduced.
Optionally, the method may further include: in a third IPSec aging period of the second device, the second device sends a first packet to the first device, where the first packet carries third indication information and a first public key generated by the second device in the third IPSec aging period, where the third indication information is used to indicate state information corresponding to the first public key, and the third indication information is the same as the first indication information. Optionally, the third IPSec aging period is the first IPSec aging period; or, N aging periods are separated between the third IPSec aging period and the first IPSec aging period, where N is a positive odd number. Optionally, the method further comprises: receiving a second message sent by the first device in a third IPSec aging period of the second device, where the second message carries a second public key and fourth indication information generated by the first device in a fourth IPSec aging period, and the fourth indication information indicates status information corresponding to the second public key, and the fourth indication information is the same as the second indication information. The generating a first IPSec key according to the key agreement template includes: and generating the first IPSec key according to the key negotiation template, the fourth indication information, the second public key, third indication information generated by the second device in the third IPSec aging period and the first private key, wherein the third indication information indicates state information corresponding to the first private key.
Optionally, the fourth IPSec aging period is the second IPSec aging period; or, M aging periods are separated between the fourth IPSec aging period and the second IPSec aging period, where M is a positive odd number. The "generating the first IPSec key according to the key agreement template, the fourth indication information, the second public key, the third indication information generated by the second device in the third IPSec aging period, and the first private key" may specifically be: and judging whether the third indication information and the fourth indication information are matched with the key negotiation template, and if so, synthesizing the first IPSec key according to the first public key and the first private key. When the key agreement template is a parallel key agreement template, the matching between the third indication information and the fourth indication information with the key agreement template may be: the third indication information and the fourth indication information are the same; when the key agreement template is a cross key agreement template, the matching of the third indication information and the fourth indication information with the key agreement template may refer to: the third indication information and the fourth indication information are different.
Optionally, the method may further include: in a fifth IPSec aging period of the second device, the second device sends a third packet to the first device, where the third packet carries a third public key and fifth indication information generated by the second device in the fifth IPSec aging period, the fifth indication information indicates status information corresponding to the third public key, and an even number of IPSec aging periods are separated between the fifth IPSec aging period and the first IPSec aging period.
Optionally, the method may further include: in a fifth IPSec aging period of the second device, the second device receives a fourth packet sent by the first device, where the fourth packet carries a fourth public key and sixth indication information generated by the first device in the sixth IPSec aging period, the sixth indication information indicates status information corresponding to the fourth public key, an even number of IPSec aging periods are spaced between the sixth IPSec aging period and the second IPSec aging period, and an even number of IPSec aging periods are spaced between the fifth IPSec aging period and the first IPSec aging period; and the second device generates a second IPSec key according to the key negotiation template, the fourth public key and the sixth indication information, as well as a second private key and fifth indication information generated by the second device in a fifth IPSec aging period, wherein the fifth indication information indicates state information corresponding to the second private key.
In the application, no matter whether the IPSec aging periods of the first device and the second device are consistent or not, the IPSec key of the IPSec aging period can be negotiated quickly and efficiently in each IPSec aging period based on the established key negotiation template, the current indication information of the devices at both ends and the public and private keys, so that a reliable data basis is provided for the secure communication between the first device and the second device.
Optionally, the first message, the second message, the third message, and the like in each implementation manner may be a BGP message or a UDP message, or may be other proprietary messages, and the application is not particularly limited. In a specific implementation, the BGP message or the UDP message may be extended to carry a public key required to generate each IPSEC key and indication information used to indicate status information corresponding to the public key.
Optionally, the first packet, the second packet, the third packet, and the like, except for carrying the indication information and the public key for generating the IPSec key, may further include one or more of the following security parameters: DH set, package mode, encryption algorithm, or authentication algorithm.
Optionally, to ensure the effectiveness of secure communication, the packet transmitted between the first device and the second device may be secured by the IPSec key synthesized by the previous IPSec aging period. For example: and generating a first IPSec key in a second IPSec aging period of the first device, where the first IPSec key may be used to protect data transmitted in a next IPSec aging period of the second IPSec aging period. Optionally, the first time period and/or the second time period may correspond to a time period within one IPSec aging period, or may also correspond to a time period of the entire IPSec aging period.
For various possible implementation manners and achieved technical effects of the method provided by the second aspect, reference may be made to the description of the method provided by the first aspect, and details are not described herein again.
In a third aspect, the present application further provides a first device, including a transceiver unit and a processing unit. Wherein, the transceiver unit is configured to perform transceiving operation in the method provided by the first aspect; the processing unit is configured to perform other operations than the transceiving operation in the first aspect. For example: when the first device executes the method of the first aspect, the transceiver unit is configured to receive, in a second IPSec aging period of the first device, first indication information sent by a second device; the processing unit is used for establishing a key negotiation template according to the first indication information and the second indication information; and generating a first IPSec key according to the key negotiation template.
In a fourth aspect, an embodiment of the present application further provides a second device, where the second device includes a transceiver unit and a processing unit. Wherein, the transceiver unit is used for executing the transceiving operation in the method provided by the second aspect; the processing unit is configured to perform other operations than the transceiving operation in the second aspect described above. For example: when the second device executes the method of the second aspect, the transceiver is configured to send the first indication information to the first device; the processing unit is used for generating first indication information.
In a fifth aspect, an embodiment of the present application further provides a first device, which includes a communication interface and a processor. Wherein, the communication interface is used for executing the transceiving operation in the method provided by the first aspect; a processor configured to perform the operations of the method provided by the first aspect, except the transceiving operation.
In a sixth aspect, an embodiment of the present application further provides a second device, which includes a communication interface and a processor. Wherein, the communication interface is used for executing the transceiving operation in the method provided by the second aspect; a processor, configured to perform other operations besides the transceiving operation in the method provided by the foregoing second aspect.
In a seventh aspect, an embodiment of the present application further provides a first device, where the first device includes a memory and a processor. Wherein the memory is used for storing program codes; the processor is configured to execute the instructions in the program code to cause the first device to perform the method provided in the first aspect above.
In an eighth aspect, an embodiment of the present application further provides a second device, where the second device includes a memory and a processor. Wherein the memory is used for storing program codes; the processor is configured to execute the instructions in the program code, so that the first device performs the method provided by the second aspect above.
In a ninth aspect, the present embodiments also provide a computer-readable storage medium, which stores instructions that, when executed on a computer, cause the computer to perform the method for secure communication provided in the above first aspect or second aspect.
In a tenth aspect, embodiments of the present application further provide a computer program product, which when run on a computer, causes the computer to perform the method for secure communication provided in the foregoing first aspect or second aspect.
In an eleventh aspect, the present application further provides a communication system, where the communication system includes the first device provided in the third aspect, the fifth aspect, or the seventh aspect, and the second device provided in the fourth aspect, the sixth aspect, or the eighth aspect.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings.
Fig. 1 is a signaling flow diagram of a method for negotiating and determining an encryption key according to an embodiment of the present application;
fig. 2 is a signaling flow diagram of a method 100 for secure communication in an embodiment of the present application;
fig. 3 is a schematic structural diagram of a KeepAlive message in the embodiment of the present application;
fig. 4a is a schematic diagram of a parallel key agreement template when IPSec aging periods are consistent in an embodiment of the present application;
fig. 4b is a schematic diagram of a cross key agreement template when IPSec aging periods are consistent in an embodiment of the present application;
fig. 5a is a schematic structural diagram of an attribute of a BGP message newly added tunnel in an embodiment of the present application;
fig. 5b is a schematic structural diagram of a Value field of the tunnel attribute Value in fig. 5a in this embodiment of the present application;
FIG. 6 is a signaling flow diagram of a method 200 for secure communication in an embodiment of the present application;
FIG. 7 is a signaling flow diagram illustrating a method 300 for secure communication in an embodiment of the present application;
FIG. 8 is a signaling flow diagram of a method 400 for secure communications in an embodiment of the present application;
fig. 9 is a signaling flow diagram of a method 500 for secure communication in an embodiment of the present application;
FIG. 10 is a signaling flow diagram of a method 600 for secure communication in an embodiment of the present application;
FIG. 11 is a signaling flow diagram of a method 1100 for secure communications in an embodiment of the present application;
FIG. 12 is a graph showing the tick values of the device 1 and the device 3 in the example of the present application;
fig. 13 is a signaling flow diagram of a method 1300 of secure communication in an embodiment of the present application;
FIG. 14 is a flowchart illustrating a method 1400 for secure communication according to an embodiment of the present application;
FIG. 15 is a flow chart illustrating another method 1500 of secure communication in an embodiment of the present application;
FIG. 16 is a schematic structural diagram of a first apparatus according to an embodiment of the present application;
FIG. 17 is a schematic diagram of a second apparatus according to an embodiment of the present application;
FIG. 18 is a schematic structural diagram of another first apparatus in an embodiment of the present application;
FIG. 19 is a schematic structural diagram of another second apparatus in an embodiment of the present application;
FIG. 20 is a schematic structural diagram of a first apparatus according to yet another embodiment of the present application;
FIG. 21 is a schematic structural diagram of a second apparatus according to an embodiment of the present application;
fig. 22 is a schematic structural diagram of a communication system in an embodiment of the present application.
Detailed Description
With the popularization of the Internet, more and more data messages are transmitted through the Internet, and in order to overcome the problem that data transmission in the Internet in a plaintext form is not safe enough, an Internet Protocol Security (Internet Protocol Security, abbreviated as IPSec) technology is provided. The IPSec technology is a set of open network security protocols based on cryptography, works in an Internet Protocol (IP) layer, and provides protection for the IP layer and upper layer protocols, for example, security services such as IP message encryption, data integrity verification, data source verification, and anti-replay can be provided.
IPSec consists of a set of network security protocols and may include, for example: a message Authentication Header (AH) protocol, an Encapsulating Security Payload (ESP) protocol, an encryption algorithm, an Authentication algorithm, and an Internet Key Exchange (IKE) protocol. The AH protocol can provide data source verification and data integrity verification functions; the ESP can provide functions of data source verification and data integrity verification and also can provide an IP message encryption function; the encryption algorithm may include: a Data Encryption Standard (DES) algorithm, a triple Data Encryption Standard (3 DES) algorithm, an Advanced Data Encryption Standard (AES) algorithm, etc.; authentication algorithms may include Message-Digest (MD) algorithms and Secure Hash (SHA) algorithms, such as: MD5, SHA1, SHA2, etc.; the IKE Protocol may include, for example, a Key DH exchange algorithm and an Internet Security Association Key Management Protocol (ISAKMP), and may determine the IPSec SA through negotiation in a manner of exchanging messages between devices.
The IPSec SA is a data basis for performing IPSec communication between devices, and the devices negotiate to determine the IPSec SA and perform IPSec communication based on the IPSec SA. The IPSec SA may specifically include: the key DH exchanges the group, encapsulates the mode, authorizes the algorithm, encrypts key and authorizes the key, etc., IPSec SA is used for guiding the safe transmission data message between the apparatus.
The IPSec key is a key synthesized by the public key generated by the local device and the public key sent by the peer device after the public keys are exchanged between the two devices. The IPSec key generated by the symmetric key algorithm is a consistent shared key between two communicating devices, and is used for security protection of data packets exchanged between the devices.
As an example, taking IPSec key as an encryption key as an example, fig. 1 shows a process of determining an encryption key according to negotiation of a key DH exchange algorithm. The scene includes a device 101, a device 102, and a Route Reflector (RR) 103, where the device 101 and the device 102 are two devices (communication peers for short) participating in communication. Referring to fig. 1, negotiating a determination of an encryption key may include, for example: s11, the device 101, the device 102 and the RR 103 respectively generate corresponding private keys a, b and c; s12, the device 101, the device 102 and the RR 103 respectively calculate corresponding public keys based on the generated private keys to obtain public keys A, B and C; s13, the device 101 and the device 102 respectively send the public keys a and B to the RR 103, and the RR 103 floods the public keys a and B in the network, and at the same time, the RR 103 floods the public key C of the RR 103 in the network; s14, the device 101 generates an encryption key based on the public key B and the private key a 12 Device 101 generates an encryption key based on public key C and private key a 13 Similarly, device 102 generates an encryption key based on public key A and private key b 21 Device 102 generates an encryption key based on public key C and private key b 23 RR 103 generates an encryption key based on public key A and private key c 31 RR 103 generates an encryption key based on public key B and private key c 32 Wherein the encryption key 12 And an encryption key 21 Are identical and are denoted as encryption keys (also referred to as shared keys) between the devices 101 and 102, and similarly, encryption keys 13 And an encryption key 31 Consistent, encrypted key 23 And an encryption key 32 And (5) the consistency is achieved.
Because the IPSec security parameters (such as a public key and a private key) of the device can be updated continuously, each time the IPSec security parameters are updated, the IPSec security parameters are regarded as entering another IPSec aging period, the negotiation of the IPSec key needs to be carried out again, and the IPSec key corresponding to the newly entered IPSec aging period is determined through the negotiation.
Currently, the negotiation of the IPSec key between devices is usually implemented in a process of dynamically negotiating the IPSec SA using an IKE Protocol, which is an application layer Protocol based on a User data packet Protocol (UDP). However, the IKE protocol is used to determine an IPSec key for a pair of device negotiation once, at least 6 messages need to be exchanged between a pair of devices, and for many large-scale networking scenarios (for example, ioT scenarios), because the number of devices increases and IPSec security parameters are continuously updated, each device needs to exchange massive messages with other devices to be able to negotiate out the IPSec key in each IPSec aging period, which not only occupies many resources in the devices and in the network, but also has problems of long time consumption and low efficiency in the way of negotiating the IPSec key by using the IKE protocol, and cannot meet the requirement for determining the IPSec key in the scenario where devices in the network increase continuously, thereby achieving fast and efficient security communication.
Based on this, in the embodiment of the present application, a method capable of fast, efficient, and convenient secure communication is provided, where a key negotiation template is established on two devices that communicate with each other, and when an IPSec key needs to be negotiated each time, a home terminal device may generate the IPSec key according to a received public key generated in a current IPSec aging period of the home terminal device and state information corresponding to the public key, which are sent by an opposite terminal device, and a received private key generated in the current IPSec aging period of the home terminal device and state information corresponding to the private key, and according to a negotiation rule of the key negotiation template. According to the technical scheme, the negotiation of the IPSec key is not carried out based on the IKE protocol any more, and compared with the situation that a plurality of messages need to be interacted when the IPSec key is negotiated between two devices through the IKE protocol, the technical scheme reduces the number of the messages interacted between the two devices, improves the negotiation efficiency of the IPSec key and reduces the occupation of system resources. In large-scale networking scenes such as IoT and the like, under the condition of mass equipment intercommunication, mass messages interacted based on IKE protocol negotiation are greatly reduced, and the occupation of system resources is reduced. In the application, the state information corresponding to the public and private key pair in one IPSec aging period, the state information corresponding to the public key in the same IPSec aging period, and the state information corresponding to the private key in the same IPSec aging period refer to the same state information.
Before describing particular embodiments of the present application, a brief description of some basic concepts involved in the present application will be provided.
The IPSec aging period refers to the time that the IPSec security parameters are valid on the device, and is used to characterize the frequency of updating the IPSec security parameters. The device can define the IPSec aging period (for example, 1 day) in advance, generate a public and private key pair in the IPSec aging period in each IPSec aging period, and obtain the IPSec key corresponding to the IPSec aging period by exchanging the public key in the newly generated public and private key pair, thereby implementing secure communication in the IPSec aging period. For example: assuming that the device 101 defines an IPSec aging period as 10 hours, the device 101 generates a private key 1 and a public key 1 at the beginning of the 1 st IPSec aging period, and after 10 hours, the device 101 enters the 2 nd IPSec aging period to generate a private key 2 and a public key 2 corresponding to the 2 nd IPSec aging period. The time length of the IPSec aging period defined by each device in the network may be the same or different, and is not limited specifically herein. A public-private key pair described herein includes a public key and a private key.
It can be appreciated that in each IPSec aging period, the device generates a new public-private key pair that is different from the public-private key pair of the previous IPSec aging period.
The key negotiation template is a template for guiding the determination of the corresponding IPSec keys in each IPSec aging period, which is established based on the state information of the public and private key pair generated in the IPSec aging period, which is interacted between the devices communicating with each other. For example, when establishing a first communication connection, two devices (which may also be referred to as communication peers) establish a key agreement template. The key negotiation template can be divided into a parallel key negotiation template and a cross key negotiation template according to whether the interactive indication information of the communication peer is the same when the key negotiation template is established. If the interactive indication information is the same, the established key agreement template is a parallel key agreement template, otherwise, if the interactive indication information is different, the established key agreement template is a cross key agreement template.
Once a key agreement template between two devices is established, it cannot be changed until the two devices are disconnected from communication. Details and implementation of specific establishment of the key agreement template can be seen in the embodiments shown in fig. 2, fig. 11, and fig. 13 to fig. 15.
It should be noted that, in the IPSec SA, the IPSec key may change with the change of the IPSec aging period, but other IPSec security parameters (such as an encryption algorithm, an authentication algorithm, and an encapsulation mode) may change or may not change in different aging periods, and the embodiment of the present application focuses on a process of negotiating and determining the IPSec key.
Fig. 2 is a flowchart illustrating a method 100 for secure communication in an embodiment of the present application. Referring to fig. 2, the method 100 is applied in a network comprising a device 1 and a device 2. The method 100 may include, for example:
s101, in an IPSec aging period 1 of a device 2, the device 2 generates indication information 1, wherein the indication information 1 is used for identifying state information corresponding to a public and private key pair generated in the IPSec aging period 1 of the device 2.
The indication information mentioned in the application or the indication information numbered by Arabic numerals, such as indication information 1, indication information 2 \8230; or indication information numbered by numbers, such as first indication information, second indication information \8230, which are all used for indicating state information corresponding to a public key and/or a private key generated by a device sending the indication information in the current IPSec aging period. The public key and/or the private key generated in each IPSec aging period iterates the corresponding state information according to the agreed rule each time IPSec is aged and updated, that is, the indication information iterates according to the agreed rule each time IPSec is aged and updated.
In one embodiment, the indication may be a numerical value, and alternate ones of the IPSec aging periods are indicated by alternate numerical values, which are used as the indication and may be written as tick values. And the tick value is used for representing the state of a public and private key pair generated by the equipment in the IPSec aging period, and can represent the state change of the equipment from one IPSec aging period to the next IPSec aging period through the alternate appearance of the two values, and can also be understood as the state change of the equipment from one public and private key pair to another public and private key pair. Taking the tick values 0 and 1 as an example, the tick value =0 may characterize the ith IPSec aging period (where i =1, 3, 5, \8230;, and the tick value =1 may characterize the jth IPSec aging period (where j =2, 4, 6, \8230;), and the ith IPSec aging period alternates with the jth aging period. The alternation of the click values 0 and 1 represents the update of the public and private key pair of the device and the alternation of the IPSec aging period.
In another specific embodiment, the indication information may also be a character string, and the updating of the public and private key pair of the device and the alternation of the IPSec aging period are characterized by the character string which alternately appears. For example: when the indication information of the device changes from string a to string b, or from string b to string a, the device is characterized to be updated from the current IPSec aging period to the next IPSec aging period.
It should be noted that the indication information includes, but is not limited to, the above-mentioned forms of character strings and tick values, and all of them fall within the scope of the indication information in the embodiment of the present application as long as the alternation of the IPSec aging period can be characterized by a predetermined rule.
The device 1 and the device 2 may respectively define their IPSec aging periods, and define state information representing that the IPSec aging periods change and then generate a public-private key pair as indication information. For example: the device 1 may define the duration of each IPSec aging period of itself as 10 hours, and define the indication information as a tick value, and the device 2 may define the duration of each IPSec aging period of itself as 2 hours, and define the indication information as a tick value. Wherein, the indication information 1 in S101 may be, for example, 0, and is used to characterize IPSec aging period 1 of device 2.
S102, the device 2 transmits the instruction information 1 to the device 1.
In specific implementation, S102 may be implemented by sending, by the device 2, a message to the device 1, where the message may be, for example, a connection detection message, and the message may also be a newly defined message, which is used to negotiate a key negotiation template. For example, the device 2 sends a connection detection message 1 to the device 1, where the connection detection message 1 includes a field 1 for carrying the indication information 1 of the device 2. Field 1 is used to instruct device 1 to establish the key agreement template. The connection detection message is a detection message used for detecting whether connection exists between the devices, and since the connection detection message is a message which is frequently interacted between the devices and has regularity, the current indication information of the local terminal device can be reliably and quickly notified to the opposite terminal device by selecting the interaction indication information of the connection detection message, so that a key negotiation template is reliably and quickly triggered and established, and the secure communication is started.
The connection Detection messages include but are not limited to keep-alive (KeepAlive) messages and Bidirectional Forwarding Detection (BFD) messages. In the application, a new field is extended to the connection detection packet, for example, a Type-Length-Value (TLV) field or a Type-Value (TV) field is added to carry indication information. Taking the KeepAlive message as an example, referring to fig. 3, the KeepAlive message includes: an IP header, a Generic Routing Encapsulation (GRE) header, and a payload (payload), then a TLV field or a TV field may be newly added in the payload, and a Value portion of the newly added TLV field or TV field carries indication information 1. The added TLV field or TV field is used to instruct the device 1 to establish a key negotiation template based on the indication information 1. The indication information is carried in the connection detection messages which need to be transmitted between the devices, new messages do not need to be redefined to transmit the indication information, network resources are saved, and due to the characteristics of frequent interaction and strong regularity of the connection detection messages, the indication information is interacted through the connection detection messages to trigger the establishment of the key negotiation template, so that the network resource is more reliable and faster, and the efficiency of obtaining the IPSec key is improved.
S103, in IPSec aging period 2 of device 1, device 1 receives indication information 1 sent by device 2.
S104, in IPSec aging period 2 of device 1, device 1 generates indication information 2, where indication information 2 is used to identify state information of a public and private key pair generated by device 1 in IPSec aging period 2.
It is understood that the indication information 2 includes, but is not limited to, a character string and a tick value, and the specific description may refer to the description about the indication information in S101 above.
For example, the indication information 2 of the device 1 in the IPSec aging period 2 is 0; as another example, the indication information 2 of the device 1 in the IPSec aging period 2 is 1.
And S105, the device 1 establishes a key negotiation template according to the indication information 1 and the indication information 2.
And the key negotiation template is used for guiding the device 1 to generate corresponding IPSec keys in each IPSec aging period. According to whether the indication information 1 is the same as the indication information 2, the established key agreement template can be divided into a parallel key agreement template and a cross key agreement template. When the indication information 1 is the same as the indication information 2, the key negotiation template is a parallel key negotiation template; when the indication information 1 and the indication information 2 are different, the key negotiation template is a cross key negotiation template.
Taking the indication information as a click value as an example, in a specific embodiment, the indication information 1 and the indication information 2 are the same. For example: assuming that the indication information 1 and the indication information 2 are both 0, the key agreement template established by the device 1 in S105 is a parallel key agreement template; another example is: assuming that the indication information 1 and the indication information 2 are both 1, the key agreement template established by the device 1 in S105 is also a parallel key agreement template. It should be noted that, in the subsequent IPSec aging period, as long as the tick values of the device 1 and the device 2 are the same, that is, the tick values of the device 1 and the device 2 are both 0, or the tick values of the device 1 and the device 2 are both 1, both can be regarded as conforming to the parallel key agreement template. For example: referring to fig. 4a, taking the case that the IPSec aging periods of the device 1 and the device 2 are consistent in duration as an example, the corresponding tick values are 1,0, \ 8230;, respectively, on the device 1 from the 1 st IPSec aging period; on device 2, starting with the first IPSec aging period, the corresponding tick values are 1,0, \8230;, respectively. After the parallel key agreement template is established, when the IPSec key is subsequently generated based on the parallel key agreement template, the matching condition of the parallel key agreement template needs to be met, that is: and the click value corresponding to the opposite-end public key for generating the IPSec key is the same as the click value corresponding to the local-end private key.
In another specific manner, the indication information 1 and the indication information 2 are different, for example: the indication information 1 is 0, the indication information 2 is 1, and the key agreement template established by the device 1 in S105 is a cross key agreement template. Another example is: the indication information 1 is 1, the indication information 2 is 0, and the key agreement template established by the device 1 in S105 is also a cross key agreement template. It should be noted that, in the subsequent IPSec aging period, as long as the tick values of the device 1 and the device 2 are different, that is, the tick value of the device 1 is 1 and the tick value of the device 2 is 0, or the tick value of the device 1 is 0 and the tick value of the device 2 is 1, the cross key agreement template may be regarded as being met. For example: referring to fig. 4b, taking the case that the IPSec aging periods of the device 1 and the device 2 are consistent in duration as an example, the corresponding tick values are 1,0, \ 8230;, respectively, on the device 1 from the 1 st IPSec aging period; on device 2, starting with the 1 st IPSec aging period, the corresponding tick values are 0,1, \ 8230;, respectively. After the cross key agreement template is established, when the IPSec key is subsequently generated based on the cross key agreement template, the matching condition of the cross key agreement template needs to be met, that is: the tick value corresponding to the peer public key used for generating the IPSec key is different from the tick value corresponding to the home-end private key. It can be understood that, since the duration of the IPSec aging period is usually relatively long, and the time for the device 1 and the device 2 to establish the key agreement template is very close, in the embodiment of the present application, the key agreement templates established on the device 1 and the device 2 are the same key agreement template.
S106, device 1 generates IPSec key 1 according to the key agreement template, where IPSec key 1 is used to protect data transmitted by device 1 and device 2 in time segment 1.
It is understood that, after establishing the key agreement template, device 1 may determine the IPSec key corresponding to the current IPSec aging period based on the established key agreement template, or device 1 may also determine the IPSec key corresponding to the subsequent IPSec aging period based on the established key agreement template.
The device generally judges whether the current indication information of the local terminal and the current indication information of the opposite terminal meet the matching condition of the key negotiation template, and when the conditions are met, the IPSec key can be generated based on the current private key of the local terminal and the current public key of the opposite terminal.
In a specific implementation, S106 may include: s1061, in the IPSec aging period 3 of the device 2, the device 2 sends a message 1 to the device 1, where the message 1 carries the indication information 3 and the public key 1, and the public key 1 is generated by the device 2 in the IPSec aging period 3; s1062, in the IPSec aging period 4 of the device 1, the device 1 receives the message 1 sent by the device 2; s1063, the device 1 generates the IPSec key 1 according to the key negotiation template, the indication information 3, the public key 1, the indication information 4 of the device 1 in the IPSec aging period 4, and the private key 1.
In a specific embodiment, the message 1 may be a Border Gateway Protocol (BGP) message or a User Datagram Protocol (UDP) message. Message 1 may also be a newly defined proprietary message.
When the message 1 is a BGP message, the BGP message may be extended to carry the current public key 1 and the indication information 3. For example: tunnel attributes may be newly added in the BGP message to carry the public key 1 and the indication information 3.
As an example, a tunnel attribute may be extended in a BGP message, which may be, for example, a TLV field or a TV field. Taking TLV fields as an example, as shown in fig. 5a, a Tunnel attribute Type Tunnel Type field in the extended Tunnel attribute TLV field is used to identify security parameters that are IPSec carried in the Tunnel attribute, and a Tunnel attribute Value Tunnel Value field may be extended as shown in fig. 5b to carry IPSec security parameters.
As another example, multiple tunnel attributes may also be extended in a BGP message, each extended tunnel attribute may be a TLV field or a TV field. Taking TLV fields as an example, a Tunnel Type field in each extended Tunnel attribute TLV field is used to identify which IPSec security parameter or parameters carried in the Tunnel attribute, and a Value field may be extended by 1 or more TLV fields and is used to carry specific values of the IPSec security parameters indicated by the Tunnel Type field.
It is to be understood that, in one case, if the IPSec key is an encryption key, the BGP message may include 2 extended TLV fields, and the Value fields of the 2 extended TLV fields are used to carry the encryption public key 1 and the indication information 3, respectively. In another case, if the IPSec key is an authentication key, the BGP message may include 2 extended TLV fields, and the Value fields of the 2 extended TLV fields are used to carry the authentication public key 1 and the indication information 3, respectively. In another case, if the IPSec key includes an authentication key and an encryption key, the BGP message may include 3 extended TLV fields, and Value fields of the 3 extended TLV fields are respectively used to carry an encryption public key 1, an authentication public key 1, and indication information 3. It should be noted that the BGP message may also carry security parameters such as DH group, encapsulation mode, encryption algorithm, authentication algorithm, etc. by extending more TLV fields in the newly added tunnel attribute, or by adding more tunnel attributes, and is used to negotiate the content that the secure communication in the IPSec SA needs to comply with, except the IPSec key.
In a specific embodiment, the message 1 is a UDP message, and the UDP message may be extended to carry the indication information 1 and the public key 1. The UDP message can be expanded and carries security parameters such as a DH group, an encapsulation mode, an encryption algorithm, an authentication algorithm and the like. For example, a TLV field or a TV field may be extended in a payload (english: payload) of the UDP packet, and the extended TLV field or the TV field is used to carry the current public key 1 and the indication information 3.
In some possible implementation manners, in addition to carrying the public key 1 and the indication information 3 of the device 2 in the current IPSec aging period, the packet 1 also carries at least one of the following IPSec security parameters: encapsulation mode 1, DH set 1, encryption algorithm 1, and authentication algorithm of device 2. Then, the method 100 may further include: the device 1 determines whether the security parameter of the device 2 matches the current security parameter of the device 1, and if the security parameter of the device 2 matches the current security parameter of the device 1, determines that the matching security parameter and the IPSec key 1 are IPSec SA, where the IPSec SA is used to implement secure communication between the device 1 and the device 2 in the time period 1, and at least one of an encapsulation mode 2, an encryption algorithm 2, and an authentication algorithm 2 of the current security parameter of the device 1.
In some specific implementation manners, the DH group, the encapsulation mode, the encryption algorithm, and the authentication algorithm may also be carried in an extended TLV field of a BGP message or a UDP packet, taking BGP message as an example, in one case, a tunnel attribute may be newly added in BGP message, and at least 6 TLV fields are extended in the tunnel attribute, where each TLV field carries one of the parameters, i.e., the public key, the indication information, the DH group, the encapsulation mode, the encryption algorithm, and the authentication algorithm. In another case, at least 6 tunnel attributes may be added to the BGP message, and each of the tunnel attributes carries one of the parameters, which is the indication information, the public key, the DH set, the encapsulation mode, the encryption algorithm, and the authentication algorithm.
Therefore, the method provided by the embodiment of the application can not only realize the function of quickly and accurately determining the IPSec key, but also negotiate and determine more contents in the IPSec SA by carrying other security parameters, thereby providing more data bases for realizing secure communication based on IPSec.
After S104 "the device 1 generates the indication information 2 within the IPSec aging period 2 of the device 1", the method 100 may further include: s107, the device 1 sends indication information 2 to the device 2; s108, in IPSec aging period 1 of the device 2, the device 2 receives the indication information 2 sent by the device 1; s109, the device 2 establishes a key negotiation template according to the indication information 1 and the indication information 2; s110, the device 2 generates the IPSec key 1 based on the key agreement template. S107 to S108 may refer to the relevant descriptions of S102 to S103, S109 may refer to the relevant descriptions of S105, and S110 may refer to the relevant descriptions of S106, and detailed descriptions thereof are omitted. Wherein, S110 may specifically include: device 2 may determine the IPSec key corresponding to the current IPSec aging period based on the established key agreement template negotiation, or device 2 may determine the IPSec key corresponding to the subsequent IPSec aging period based on the established key agreement template negotiation.
During time period 1, method 100 may further include: after S106, device 1 transmits data secured by IPSec key 1 to device 2; after S110, device 2 transmits data secured by IPSec key 1 to device 1.
As an example, if data to and from a user needs to be encrypted, the IPSec key may be configured as an encryption key, and the IPSec key 1 generated in S106 and S110 is also the encryption key 1, then the device 1 performs security protection on the data 1 through the IPSec key 1, that is, the device 1 encrypts the data 1 using the encryption key 1 and transmits the encrypted data to the device 2, and the device 2 decrypts the received data based on the encryption key 1 to obtain the data 1.
As another example, if the data to and from the device needs to be authenticated, the IPSec key may be configured as an authentication key, and the IPSec key 1 generated in S106 and S110 is also the authentication key 1, then the device 1 performs security protection on the data 1 through the IPSec key 1, which means that the device 1 authenticates the data 1 using the authentication key 1, for example, for an IP packet, a digital signature is generated based on the authentication key and an authentication algorithm, and the device 2 authenticates the integrity and the authenticity of the IP packet based on the digital signature, thereby ensuring secure communication.
As another example, if the data packet needs to be encrypted and authenticated, the IPSec key may be configured to include an encryption key and an authentication key, and the IPSec key 1 generated in S106 and S110 includes an encryption key 1 and an authentication key 1, so that the device 1 performs security protection on the data 1 through the IPSec key 1, that is, the device 1 encrypts the data 1 using the encryption key 1, then digitally signs the encrypted data with the authentication key 1, and sends the data to the device 2, the device 2 performs integrity and authenticity authentication on the digital signature based on the authentication key 1, and after the authentication is passed, the device 1 decrypts the data to obtain the data 1.
It should be noted that, applicable scenarios in the embodiment of the present application include: in a scenario one, the device 1 and the device 2 may be directly connected, and then, operations such as sending, receiving, and the like in the embodiment shown in fig. 2 are all performed by directly exchanging information between the device 1 and the device 2; in a second scenario, the device 1 and the device 2 may also be indirectly connected, for example, the device 1 is connected to the device 2 through another device such as a controller, and then operations such as sending, receiving, and the like in the embodiment shown in fig. 2 are all completed through device relay interaction information between the device 1 and the device 2 through the controller and the like. The description in the embodiments of the present application takes the scenario one as an example.
Thus, in this embodiment of the present application, when a secure connection needs to be established, two devices participating in communication pre-establish a key agreement template, and when a subsequent IPSec key agreement is performed, based on the pre-established key agreement template, each device can quickly generate a corresponding IPSec key within a current IPSec aging period of each device. Therefore, because the technical scheme of the application does not perform IPSec key negotiation based on the IKE protocol any more, compared with the situation that a plurality of messages need to be interacted when the IPSec key is negotiated between two devices through the IKE protocol, the technical scheme of the application effectively reduces the number of the interacted messages between the two devices, improves the negotiation efficiency of the IPSec key, and simultaneously reduces the occupation of system resources. Especially in a large-scale networking scene such as IoT and the like, under the condition of mass equipment intercommunication, the mass messages interacted based on IKE protocol negotiation are greatly reduced, and the occupation of system resources is reduced.
In some specific embodiments, in order to avoid that the time for synthesizing the new IPSec key by each device is inconsistent, which results in that the data transmission is not secure enough or cannot be effectively transmitted, in this embodiment of the application, the method may further include: and saving the previously used IPSec key on the equipment, and enabling the IPSec key synthesized in the previous IPSec aging period when synthesizing a new IPSec key, so as to perform security protection on the data to be transmitted. Therefore, the data can be ensured to be safely protected by adopting the same IPSec key in the same time period between the communication peers, the effectiveness of the IPSec key in the safety protection of the data to be transmitted is improved, and the probability of safe and effective transmission of the data is improved.
In general, the same device may define the duration of each IPSec aging period thereon to be the same; the time lengths of the IPSec aging periods of different devices may be the same or different. And the device 1 or the device 2 generates the IPSec key according to the key negotiation template and the negotiation rule. The negotiation rule comprises: 1) The state information corresponding to the newly generated private key of the local terminal and the state information corresponding to the newly generated public key of the opposite terminal equipment meet the matching condition of the key agreement template; 2) Generating an IPSec key by using the latest private key of the local terminal device and the latest public key of the opposite terminal device; 3) The public and private keys involved in generating the IPSec key cannot participate again in generating the next IPSec key. Optionally, the rule may further include: the synthesized IPSec key in the current IPSec aging period of the device is used for protecting data transmitted in the next IPSec aging period adjacent to the current IPSec aging period.
In some possible implementation manners, assuming that each IPSec aging period of the device 1 is duration 1, each IPSec aging period of the device is duration 2, and the durations 1 and 2 are equal, then the IPSec key corresponding to the IPSec aging period may be obtained according to a pre-established key negotiation template and a public key exchanged between the IPSec aging periods.
As an example, an embodiment of the present application provides a method 200 for secure communication, where, referring to fig. 6, the method 200 includes:
s201, in an IPSec aging period 1 of the device 2, the device 2 sends a message 1 to the device 1, where the message 1 carries indication information 1 and a public key 1, and the indication information 1 is used to indicate that the device 2 generates state information of a public and private key pair in the IPSec aging period 1.
S202, in IPSec aging period 2 of device 1, device 1 receives packet 1 sent by device 2 in IPSec aging period 1.
S203, the device 1 generates an IPSec key 1 according to the key agreement template, the indication information 1, the public key 1, and the private key 1 and the indication information 2 generated by the device 1 in the IPSec aging period 2. The indication information 2 is used for indicating the device 1 to generate state information of a public and private key pair in the IPSec aging period 2
It should be noted that the method 200 may further include:
s204, in the IPSec aging period 2 of the device 1, the device 1 sends a message 2 to the device 2, where the message 2 carries the indication information 2 and the public key 2.
S205, in the IPSec aging period 1 of the device 2, the device 2 receives the packet 2 sent by the device 1 in the IPSec aging period 2.
S206, the device 2 generates an IPSec key 2 according to the key negotiation template, the indication information 2, the public key 2, and the private key 2 and the indication information 1 that are generated by the device 2 in the IPSec aging period 1. Here, IPSec key 2 is the same as IPSec key 1 generated in S203.
In method 200, public key 2 and private key 1 are a public-private key pair generated by device 1 during IPSec aging period 2, and public key 1 and private key 2 are a public-private key pair generated by device 2 during IPSec aging period 1.
In a specific implementation, both the message 1 and the message 2 may be BGP messages or UDP messages, which may be specifically referred to the relevant description about the public key and the indication information carried by the BGP messages or UDP messages in the embodiment of the method 100.
Here, S201 to S202 may be executed at any position after S101, and S204 to S205 may be executed at any position after S104. S203 is a specific implementation of S106; s206 is a specific implementation of S110.
As another example, in IPSec aging period 4 for device 1 and IPSec aging period 3 for device 2, IPSec aging period 4 and IPSec aging period 2 are separated by an odd number of IPSec aging periods, and IPSec aging period 3 and IPSec aging period 1 are also separated by an odd number of IPSec aging periods. An embodiment of the present application further provides a method 300 for secure communication, and as shown in fig. 7, the method 300 may include, for example:
s301, in an IPSec aging period 3 of the device 2, the device 2 sends a message 3 to the device 1, where the message 3 carries indication information 3 and a public key 3, and the indication information 3 is used to indicate that the device 2 generates state information of a public and private key pair in the IPSec aging period 3.
S302, in IPSec aging period 4 of device 1, device 1 receives packet 3 sent by device 2 in IPSec aging period 3.
S303, the device 1 generates an IPSec key 3 according to the key negotiation template, the indication information 3, the public key 3, and the private key 3 and the indication information 4 that are generated by the device 1 in the IPSec aging period 4.
The method 300 may further include:
s304, in an IPSec aging period 4 of the device 1, the device 1 sends a packet 4 to the device 2, where the packet 2 carries indication information 4 and a public key 4, and the indication information 4 is used to indicate that the device 1 generates state information of a public and private key pair in the IPSec aging period 4.
S305, in IPSec aging period 3 of device 2, device 2 receives packet 4 sent by device 1 in IPSec aging period 4.
S306, the device 2 generates an IPSec key 4 according to the key negotiation template, the indication information 4, the public key 4, and the private key 4 and the indication information 3 generated by the device 2 in the IPSec aging period 3. Here, IPSec key 4 generated in S306 is the same as IPSec key 3 generated in S303.
Since the indicating information is updated alternately to indicate IPSec, the indicating information on the device is the same after an odd number of IPSec aging periods apart. Since IPSec aging period 3 is separated from IPSec aging period 1 by an odd number of IPSec aging periods, and IPSec aging period 4 is separated from IPSec aging period 2 by an odd number of IPSec aging periods, then indication information 3 is the same as indication information 1, and indication information 4 is the same as indication information 2. Also, since duration 1 and duration 2 are equal, then the number of interphased IPSec aging periods is the same.
In a specific embodiment, S303 may include: the device 1 judges whether the indication information 3 and the indication information 4 meet the matching condition of the key negotiation template, if so, the device 1 synthesizes the IPSec key 3 according to the public key 3 and the private key 3; otherwise, device 1 does not synthesize IPSec key 3. S306 may include: the device 2 judges whether the indication information 3 and the indication information 4 meet the matching condition of the key negotiation template, if so, the device 2 synthesizes an IPSec key 4 according to the public key 4 and the private key 4; otherwise, device 2 does not compose IPSec key 4. For the scenario that the aging periods of the IPSec devices are consistent, after the key agreement template is established for the first time, the subsequent aging periods of the IPSec devices are consistent, and the above-mentioned judgment operation is not a necessary operation.
In a specific implementation, both the message 3 and the message 4 may be BGP messages or UDP messages, which may be specifically referred to the relevant description about the public key and the indication information carried in the BGP messages or UDP messages in the embodiment of the method 100.
S301 to S303 may be executed at any time after device 1 enters IPSec aging period 4, and similarly, S304 to S306 may be executed at any time after device 2 enters IPSec aging period 3. The execution of S301-S303 and S304-S306 are not in sequence. S303 is a specific implementation of S106; s306 is a specific implementation of S110.
As yet another example, in IPSec aging period 6 for device 1 and IPSec aging period 5 for device 2, IPSec aging period 6 and IPSec aging period 2 are separated by an even number of IPSec aging periods, and IPSec aging period 5 and IPSec aging period 1 are also separated by an even number of IPSec aging periods. An embodiment of the present application further provides a method 400 for secure communication, and as shown in fig. 8, the method 400 may include, for example:
s401, in an IPSec aging period 5 of the device 2, the device 2 sends a message 5 to the device 1, where the message 5 carries indication information 5 and a public key 5, and the indication information 5 is used to indicate that the device 2 generates state information of a public and private key pair in the IPSec aging period 5.
S402, in IPSec aging period 6 of device 1, device 1 receives packet 5 sent by device 2 in IPSec aging period 5.
S403, the device 1 generates an IPSec key 5 according to the key negotiation template, the indication information 5, the public key 5, and the private key 5 and the indication information 6 that are generated by the device 1 in the IPSec aging period 6.
The method 400 may further include:
s404, in IPSec aging period 6 of device 1, device 1 sends message 6 to device 2, where message 2 carries indication information 6 and public key 6, and indication information 6 is used to indicate that device 1 generates state information of a public/private key pair in IPSec aging period 6.
S405, in IPSec aging period 5 of device 2, device 2 receives packet 6 sent by device 1 in IPSec aging period 6.
S406, the device 2 generates the IPSec key 6 according to the key agreement template, the indication information 6, the public key 6, the private key 6 generated by the device 2 in the IPSec aging period 5, and the indication information 5. The IPSec key 6 generated in S406 is the same as the IPSec key 5 generated in S402.
Since the indicating information is updated alternately to indicate IPSec, the indicating information on the device is not the same after an even number of IPSec aging periods. Since IPSec aging period 5 is separated from IPSec aging period 1 by an even number of IPSec aging periods, and IPSec aging period 6 is separated from IPSec aging period 2 by an even number of IPSec aging periods, indication information 5 is different from indication information 1, and indication information 6 is different from indication information 2. Also, since duration 1 and duration 2 are equal, then the number of interphased IPSec aging periods is the same.
Wherein, S403 may specifically include: the device 1 judges whether the indication information 5 and the indication information 6 meet the matching condition of the key negotiation template, if so, the device 1 synthesizes the IPSec key 5 according to the public key 5 and the private key 5; otherwise, device 1 does not synthesize IPSec key 5. S306 may specifically include: the device 2 judges whether the indication information 5 and the indication information 6 meet the matching condition of the key negotiation template, if yes, the device 2 synthesizes an IPSec key 6 according to the public key 6 and the private key 6; otherwise, device 2 does not synthesize IPSec key 6. For the scenario that the aging periods of the IPSec devices are consistent, after the key agreement template is established for the first time, the subsequent aging periods of the IPSec devices are consistent, and the above-mentioned judgment operation is not a necessary operation.
In a specific implementation, the messages 5 and 6 may be BGP messages or UDP messages, which may specifically refer to the relevant description about the public key and the indication information carried in the BGP messages or UDP messages in the embodiment of the method 100.
S401 to S403 may be executed at any time after device 1 enters IPSec aging period 6, and similarly, S404 to S406 may be executed at any time after device 2 enters IPSec aging period 5. The execution of S401-S403 and S404-S406 has no precedence order. S403 is a specific implementation of S106; s406 is a specific implementation of S110.
In a specific embodiment, the method 200 may be executed during an IPSec aging period (which may also be referred to as a first IPSec aging period) for establishing the key agreement template; enter a second IPSec aging period and perform method 400; entering a third IPSec aging period and performing method 300; enter a fourth IPSec aging period and then perform method 400; enter a fifth IPSec aging period and then perform method 300; by analogy, the method 300 and the method 400 are repeatedly executed, so that the IPSec keys in the IPSec aging periods are obtained.
For two devices with the same IPSec aging period duration, by executing the method 200, the method 300, and the method 400, IPSec keys corresponding to the IPSec aging periods can be generated quickly and efficiently, and a data basis is provided for secure communication between the devices.
In the following embodiment shown in fig. 11, how the method 200, the method 300, and the method 400 are implemented in the embodiment of the present application will be specifically described by taking the tick value indicating that the information is 0 and 1 alternated as an example.
In other possible implementation manners, each IPSec aging period of the device 1 is duration 1, each IPSec aging period of the device is duration 2, but the durations 1 and 2 are not equal.
As an example, in IPSec aging period 4 of device 1 and IPSec aging period 3 of device 2, IPSec aging period 4 and IPSec aging period 2 are separated by an odd number of IPSec aging periods, indication information 4 corresponding to IPSec aging period 4 is the same as indication information 2, IPSec aging period 3 and IPSec aging period 1 are also separated by an odd number of IPSec aging periods, and indication information 3 corresponding to IPSec aging period 3 is the same as indication information 1. An embodiment of the present application further provides a method 500 for secure communication, as shown in fig. 9, where the method 500 may include, for example:
s501, in an IPSec aging period 3 of the device 2, the device 2 sends a message 3 to the device 1, where the message 3 carries indication information 3 and a public key 3, and the indication information 3 is used to indicate that the device 2 generates state information of a public and private key pair in the IPSec aging period 3.
S502, the device 1 receives the packet 3 sent by the device 2 in the IPSec aging period 3.
In S503, the device 1 determines whether a condition (which may also be referred to as a predetermined negotiation rule) is satisfied, and if so, executes S504.
Wherein the conditions include: neither public key 3 nor private key 3 generated by device 1 during IPSec aging period 4 participate in the synthesis of the IPSec key.
S504, the device 1 determines whether the indication information 3 and the indication information 4 generated by the device 1 in the IPSec aging period 4 satisfy the matching condition of the key agreement template, and if so, executes S505.
S505, device 1 generates IPSec key 3 based on public key 3 and private key 3 generated by device 1 within IPSec aging period 4.
The method 500 may further include:
s506, in IPSec aging period 4 of device 1, device 1 sends message 4 to device 2, where message 2 carries indication information 4 and public key 4, and indication information 4 is used to indicate that device 1 generates state information of a public and private key pair in IPSec aging period 4.
S507, the device 2 receives the message 4 sent by the device 1 in the IPSec aging period 4.
S508, the device 2 determines whether the condition is satisfied, and if so, executes S509.
Wherein the conditions include: neither public key 4 nor private key 4 generated by device 2 during IPSec aging period 3 participates in the synthesis of IPSec keys.
S509, the device 2 determines whether the indication information 4 and the indication information 3 generated by the device 2 in the IPSec aging period 3 satisfy the matching condition of the key agreement template, and if so, executes S510.
S510, device 2 generates IPSec key 4 according to public key 4 and private key 4 generated by device 2 in IPSec aging period 3. IPSec key 4 generated in S510 is the same as IPSec key 3 generated in S505.
As another example, in IPSec aging period 6 of device 1 and IPSec aging period 5 of device 2, IPSec aging period 6 and IPSec aging period 2 are separated by an even number of IPSec aging periods, indication information 6 corresponding to IPSec aging period 6 is different from indication information 2, IPSec aging period 5 and IPSec aging period 1 are also separated by an even number of IPSec aging periods, and indication information 5 corresponding to IPSec aging period 5 is different from indication information 1. An embodiment of the present application further provides a method 600 for secure communication, and as shown in fig. 10, the method 600 may include, for example:
s601, in an IPSec aging period 5 of the device 2, the device 2 sends a message 5 to the device 1, where the message 5 carries indication information 5 and a public key 5, and the indication information 5 is used to indicate that the device 2 generates state information of a public and private key pair in the IPSec aging period 5.
S602, the device 1 receives the packet 5 sent by the device 2 in the IPSec aging period 5.
S603, the device 1 determines whether the condition is satisfied, and if so, executes S604.
Wherein the conditions include: neither the public key 5 nor the private key 5 generated by the device 1 during the IPSec aging period 6 participate in the synthesis of the IPSec key.
S604, the device 1 determines whether the indication information 5 and the indication information 6 generated by the device 1 in the IPSec aging period 6 satisfy the matching condition of the key agreement template, and if so, executes S605.
S605, device 1 generates IPSec key 5 based on public key 5 and private key 5 generated by device 1 in IPSec aging period 6.
The method 600 may further include:
s606, in the IPSec aging period 6 of the device 1, the device 1 sends a message 6 to the device 2, where the message 2 carries indication information 6 and the public key 6, and the indication information 6 is used to indicate that the device 1 generates state information of a public and private key pair in the IPSec aging period 6.
S607, in IPSec aging period 5 of device 2, device 2 receives packet 6 sent by device 1 in IPSec aging period 6.
S608, the device 2 determines whether the condition is satisfied, and if so, executes S609.
Wherein the condition includes that neither the public key 6 nor the private key 6 generated by the device 2 during the IPSec aging period 5 has participated in the synthesis of the IPSec key.
S609, the device 2 determines whether the indication information 6 and the indication information 5 generated by the device 2 in the IPSec aging period 5 conform to the key agreement template, and if so, executes S610.
S610, device 2 generates IPSec key 6 based on public key 6 and private key 6 generated by device 2 in IPSec aging period 5. IPSec key 6 generated in S610 is the same as IPSec key 5 generated in S605.
In a specific embodiment, the method 200 may be executed during an IPSec aging period (which may also be referred to as a first IPSec aging period) during which the key agreement template is established; the device with the longer IPSec aging period enters the second IPSec aging period and performs the method 600; the device with the longer IPSec aging period enters the third IPSec aging period, and the method 500 is executed; the device with the longer IPSec aging period enters the fourth IPSec aging period and then performs the method 600; the device with the longer IPSec aging period enters the fifth IPSec aging period and then performs the method 500; by analogy, the method 500 and the method 600 are repeatedly executed to achieve obtaining of IPSec keys in each IPSec aging period.
For two devices with different IPSec aging periods, by executing the method 200, the method 500, and the method 600, the IPSec keys corresponding to the IPSec aging periods can be generated quickly and orderly, and a data basis is provided for secure communication between the devices.
In the following embodiment shown in fig. 13, how to implement the method 200, the method 500, and the method 600 described above will be described by taking, as an example, a tick value indicating that information is 0 and 1 alternated.
For more clearly and specifically describing the embodiment of the present application, referring to fig. 11 and fig. 13, taking the indication information as a tick value and the IPSec key as an encryption key as an example, a negotiation process of the IPSec key in the embodiment of the present application is specifically described by two examples.
In this scenario, device 1 and device 2 are communication peers, and device 1 and device 3 are also communication peers. Assuming that the IPSec aging period for device 1 and device 2 is 24 hours and the aging period for device 3 is 10 hours; from the establishment of the connection, the tick values 0,1 of device 1 and device 2 alternate, and the tick values 1,0 of device 3 alternate. The following example first introduces negotiation of IPSec keys within the first 2 IPSec aging periods for apparatus 1 and apparatus 2, and the following example second introduces negotiation of IPSec keys within the first 2 IPSec aging periods for apparatus 1 for apparatus 3.
Example one: referring to fig. 11, a method 1100 of negotiating IPSec keys may include a process of obtaining IPSec keys in a first IPSec aging period and a process of obtaining IPSec keys in a second IPSec aging period.
In the first IPSec aging period, obtaining the IPSec key includes:
s1101, the device 1 sends KeepAlive message 1 to the device 2, where the KeepAlive message 1 carries a tick value 0.
S1102, the device 2 sends a KeepAlive message 2 to the device 1, where the KeepAlive message 2 carries a tick value 0.
S1103, the device 1 generates a key agreement template according to the tick value 0 and its current tick value 0; the device 2 generates a key agreement template according to the tick value 0 and the current tick value 0 of itself.
S1104, device 1 sends BGP message 0 to device 2, where BGP message 0 carries tick value 0 and public key H1 in the first IPSec aging period; the device 2 sends the BGP message 0 'to the device 1, where the BGP message 0' carries the tick value 0 and the public key H2 in the first IPSec aging period.
S1105, the device 1 synthesizes the encryption key K1 according to the private key D1 generated by itself and the received public key H2.
S1106, device 2 synthesizes encryption key K2 according to private key D2 generated by itself and received public key H1.
K1 and K2 are identical.
S1107, the data packet 1 encrypted by the encryption key is transmitted between the device 1 and the device 2.
After the first IPSec aging period lasts 24 hours, a second IPSec aging period is entered, a new IPSec key needs to be negotiated, and the process of negotiating the IPSec key in the second IPSec aging period may include:
s1108, the device 1 sends a BGP message 1 to the device 2, where the BGP message 1 carries the tick value 1 and the public key H3; the device 2 sends a BGP message 2 to the device 1, where the BGP message 2 carries the tick value 1 and the public key H4.
S1109, the device 1 synthesizes the encryption key K3 according to the private key D3 generated by itself and the received public key H4.
S1110, the device 2 synthesizes an encryption key K4 according to the private key D4 generated by itself and the received public key H3.
K3 and K4 are identical.
And S1111, transmitting the data message 2 encrypted by the encryption key between the equipment 1 and the equipment 2.
In a specific embodiment, after S1108 and before S1109, the method may further include the device 1 determining that the matching condition of the key agreement template is satisfied according to the received tick value 1 and its current tick value 1, and then executing S1109.
In a specific embodiment, in S1111, the data packet 2 secured by K3 or K4 may also be transmitted between the device 1 and the device 2.
Therefore, under the condition that the time length of the aging period of the IPSec of the two devices is the same and the updating period is consistent, the key negotiation template can be established before the IPSec key is negotiated, and then the IPSec key is rapidly and efficiently negotiated based on the key negotiation template when the IPSec key needs to be negotiated, so that the safe and rapid message transmission based on the IPSec in the network becomes possible.
Example two: referring to fig. 12, a diagram of the IPSec aging period between apparatus 1 and apparatus 3 is shown. Referring to fig. 13, a method 1300 for negotiating an IPSec key includes a process of obtaining the IPSec key in a first IPSec aging period and a process of obtaining the IPSec key in a second IPSec aging period of the device 1. The method 1300 includes:
s1301, the device 1 sends a KeepAlive message 3 to the device 3, where the KeepAlive message 3 carries a tick value 0.
S1302, the device 3 sends a KeepAlive message 4 to the device 1, where the KeepAlive message 4 carries the tick value 1.
And S1303, the device 1 generates a key agreement template according to the click value 1 and the current click value 0 thereof, and the device 3 generates a key agreement template according to the click value 0 and the current click value 1 thereof.
S1304, the device 1 sends a BGP message 0 to the device 3, where the BGP message 0 carries the tick value 0 and the public key H1 in the first IPSec aging period; the device 3 sends the BGP message 0 'to the device 1, where the BGP message 0' carries the tick value 1 and the public key H2 in the first IPSec aging period.
S1305, the device 1 synthesizes the encryption key K1 according to the private key D1 generated by itself and the received public key H2.
S1306, the device 3 synthesizes the encryption key K2 from the private key D2 generated by itself and the received public key H1.
K1 and K2 are identical.
In a specific embodiment, it should be noted that, after S1306, the BGP message and the data packet that interact between the device 1 and the device 3 may both be encrypted by using the encryption key K1 or K2 to implement security protection.
After the first IPSec aging period of the device 3 lasts for 10 hours, entering a second IPSec aging period of the device 3, where the embodiment of the present application includes:
s1307, the device 3 sends a BGP message 3 to the device 1, where the BGP message 3 carries the tick value 0 and the public key H3.
Since the cross-key agreement template is not currently complied with, and the private key D1 of the device 1 has already participated in the synthesis of the IPSec key, the device 1 does not perform the synthesis of a new IPSec key, and continues to use K1 or K2 as the shared encryption key.
After the second IPSec aging period of the device 3 lasts for 10 hours, a third IPSec aging period of the device 3 is entered, and in this case, the embodiment of the present application includes:
s1308, the device 3 sends a BGP message 4 to the device 1, where the BGP message 4 carries the tick value 1 and the public key H4.
Although conforming to the cross-key agreement template, the private key D1 of device 1 has already participated in the synthesis of the IPSec key, and device 1 still does not perform the synthesis of a new IPSec key, and continues to use K1 or K2 as the shared IPSec key.
When the first IPSec aging period of the apparatus 1 lasts 24 hours, at this time, the third IPSec aging period of the apparatus 3 has been performed for 4 hours, and at this time, the second IPSec aging period of the apparatus 1 is entered, and the process of obtaining the IPSec key may include, for example:
s1309, the device 1 sends a BGP message 5 to the device 3, where the BGP message 5 carries the tick value 1 and the public key H5.
Although the private key D4 of the device 3 does not participate in the synthesis of the IPSec key, it does not conform to the cross-key agreement template, and therefore the device 3 does not perform the synthesis of a new IPSec key and continues to use K1 or K2 as a shared encryption key.
After the third IPSec aging period of the device 3 lasts for 10 hours, a fourth IPSec aging period of the device 3 is entered, and at this time, the embodiment of the present application includes:
s1310, the device 3 sends a BGP message 6 to the device 1, where the BGP message 6 carries the tick value 0 and the public key H6.
S1311, the device 1 determines that the key negotiation template is satisfied and the key synthesis condition is satisfied according to the tick value 0 and the current tick value 1 of the device, and synthesizes an encryption key K3 according to the private key D5 generated by the device and the received public key H6.
The key synthesis condition (that is, the "condition" in the above embodiment, may also be referred to as a predetermined negotiation rule) may specifically include: private key D5 is the latest generated private key of device 1, public key H6 is the latest public key received from device 3, and neither private key D5 nor public key H6 has participated in the composition of the encryption keys.
After the fourth IPSec aging period of the device 3 lasts for 10 hours, entering a fifth IPSec aging period of the device 3, where the embodiment of the present application includes:
s1312, the device 3 sends a BGP message 7 to the device 1, where the BGP message 7 carries the tick value 1 and the public key H7.
Since the cross-key agreement template is not complied with and the private key D5 of the device 1 has already participated in the synthesis of the IPSec key, the device 1 does not perform the synthesis of a new IPSec key and continues to use either K1 or K2 as the shared encryption key or K3 as the shared encryption key.
When the second IPSec aging period of device 1 lasts 24 hours, at this time, the fifth IPSec aging period of device 3 has been performed for 8 hours, and at this time, the third IPSec aging period of device 1 is entered, and the process of negotiating the IPSec key may include, for example:
s1313, the device 1 sends a BGP message 8 to the device 3, where the BGP message 8 carries the tick value 0 and the public key H8.
S1314, the device 3 determines that the template is in accordance with the key agreement according to the tick value 0 and the current tick value 1, and that the condition for key synthesis is satisfied, and synthesizes the encryption key K4 according to the private key D7 generated by the device and the received public key H8.
The key synthesis condition may specifically include: the private key D7 is a newly generated private key of the device 3, the public key H8 is a newly received public key from the device 1, and neither the private key D7 nor the public key H8 participates in the synthesis of the encryption key.
It will be appreciated that during the remaining 2 hours of the fifth IPSec aging period for this device 3, data messages 3 secured by any one of the encryption keys K1, K2, K3 or K4 are transmitted between the device 1 and the device 3.
Therefore, under the condition that the time lengths of the aging periods of the IPSec of the two devices are different, the key negotiation template can be established before the IPSec key is negotiated, and then the IPSec key is negotiated based on the key negotiation template quickly and efficiently when the IPSec key needs to be negotiated, so that the safe and quick data transmission based on the IPSec in the network is possible.
Fig. 14 shows a flowchart of a method 1400 for secure communication in an embodiment of the present application, where the method 1400 is applied in a scenario including a first device and a second device, and the method 1400 for secure communication may include, for example:
step 1401, in a second internet protocol security IPSec aging period of a first device, receiving first indication information sent by a second device, where the first indication information is used to identify state information corresponding to a public and private key pair generated in the first IPSec aging period of the second device;
step 1402, establishing a key agreement template according to the first indication information and second indication information, where the second indication information is used to identify state information of a public and private key pair generated by the first device in the second IPSec aging period;
in step 1403, according to the key agreement template, a first IPSec key is generated, where the first IPSec key is used to protect data transmitted by the first device and the second device in the first time period.
As an example, the first device may be device 1 in method 100, the second device may be device 2 in method 100, and then the first indication information may be indication information 1 in method 100, the second indication information is indication information 2 in method 100, the second IPSec aging period is IPSec aging period 2, the first IPSec aging period is IPSec aging period 1, and the first IPSec key is IPSec key 1.
As another example, the first device may be device 2 in method 100, the second device may be device 1 in method 100, and then the first indication information may be indication information 2 in method 100, the second indication information is indication information 1 in method 100, the second IPSec aging period is IPSec aging period 1, the first IPSec aging period is IPSec aging period 2, and the first IPSec key is IPSec key 1.
The first indication information is the same as the second indication information, and the key negotiation template is a parallel key negotiation template; or the first indication information is different from the second indication information, and the key agreement template is a cross key agreement template.
In some possible implementation manners, in S1401 "receiving the first indication information sent by the second device" in this embodiment of the application may include: and receiving keep-alive KeepAlive messages or Bidirectional Forwarding Detection (BFD) messages sent by the second equipment, wherein the first indication information is carried in the KeepAlive messages or the BFD messages.
In other possible implementations, the method 1400 further includes: in a fourth IPSec aging period of the first device, receiving a first packet sent by the second device in a third IPSec aging period, where the first packet carries third indication information and a first public key generated by the second device in the third IPSec aging period, where the third indication information is used to indicate state information corresponding to the first public key, the third IPSec aging period is the first IPSec aging period or N aging periods are spaced between the third IPSec aging period and the first IPSec aging period, N is a positive odd number, and the third indication information is the same as the first indication information. Then, S1403 "generating the first IPSec key according to the key agreement template" in the method 1400 may include: and generating a first IPSec key according to the key negotiation template, the third indication information, the first public key, and a first private key and fourth indication information generated by the first device in a fourth IPSec aging period, wherein the fourth indication information is used for indicating the fourth IPSec aging period, the fourth IPSec aging period is the second IPSec aging period or M aging periods are arranged between the fourth IPSec aging period and the second IPSec aging period, M is a positive odd number, and the fourth indication information is the same as the second indication information.
It should be noted that, when the method 1400 is used to implement the method 200 corresponding to fig. 6, the method 300 corresponding to fig. 7, or the method 500 corresponding to fig. 9, for example, the first device may be the device 1 in the foregoing method embodiment, and the second device is the device 2 in the foregoing method embodiment, then, the third indication information is the indication information 3, the fourth indication information is the indication information 4, the third IPSec aging period is the IPSec aging period 3, the fourth IPSec aging period is the IPSec aging period 4, and the first packet is the packet 1 or the packet 3 in the foregoing method embodiment. Or, for example, the first device may also be the device 2 in the foregoing method 200, 300, or 500, and the second device is the corresponding device 1, then the third indication information is indication information 4, the fourth indication information is indication information 3, the third IPSec aging period is the IPSec aging period 4, the fourth IPSec aging period is the IPSec aging period 3, and the first packet is packet 2 or packet 4 in the foregoing method embodiment.
It is understood that the related descriptions of the implementation and the achieved effects can be found in the related descriptions of the method 200, the method 300 or the method 500. Specifically, when each IPSec aging period of the first device is a first duration, each IPSec aging period of the second device is a second duration, and the first duration and the second duration are equal, the implementation manner may be referred to as method 200 or method 300; when the first duration and the second duration are not equal, see method 500, where generating the first IPSec key in S1403 specifically includes: generating the first IPSec key when the following conditions are satisfied, the conditions including: neither the first public key nor the first private key involved in generating the first IPSec key is involved in generating IPSec keys other than the first IPSec key.
In still other possible implementations, the method 1400 may further include: receiving a second message sent by the second device in a sixth IPSec aging period of the first device, wherein the second message carries a second public key and fifth indication information generated by the second device in a fifth IPSec aging period, the fifth indication information indicates state information corresponding to the second public key, and an even number of IPSec aging periods are arranged between the fifth IPSec aging period and the first IPSec aging period; and generating a second IPSec key according to the key negotiation template, the second public key, the fifth indication information, and a second private key and sixth indication information generated by the first device in a sixth IPSec aging period, wherein the sixth indication information is used for indicating state information corresponding to the second private key, the second IPSec key is used for protecting data transmitted by the first device and the second device in a second time period, and the sixth IPSec aging period is separated from the second IPSec aging period by an even number of IPSec aging periods.
It should be noted that, when the method 1400 is used to implement the method 400 corresponding to fig. 8 or the method 600 corresponding to fig. 10, for example, the first device may be the device 1 in the foregoing method embodiment, and the second device is the device 2 in the foregoing method embodiment, then the fifth indication information is the indication information 5, the sixth indication information is the indication information 6, the fifth IPSec aging period is the IPSec aging period 5, the sixth IPSec aging period is the IPSec aging period 6, and the second packet is the packet 5 in the foregoing method embodiment. Or, for example, the first device may also be the device 2 in the foregoing method embodiment, and the second device is the device 1 in the foregoing method embodiment, then the fifth indication information is the indication information 6, the sixth indication information is the indication information 5, the fifth IPSec aging period is the IPSec aging period 6, the sixth IPSec aging period is the IPSec aging period 5, and the second packet is the packet 6 in the foregoing method embodiment.
It is understood that the related description of the implementation and the achieved effect can be referred to the related description in the method 400 or the method 600. Specifically, when each IPSec aging period of the first device is a first duration, each IPSec aging period of the second device is a second duration, and the first duration and the second duration are equal, the implementation manner may be referred to as method 400; when the first duration and the second duration are not equal, see method 600, where "generating the second IPSec key" specifically is: generating the second IPSec key when the following conditions are satisfied, the conditions including: neither the second public key nor the second private key involved in generating the second IPSec key has participated in generating IPSec keys other than the second IPSec key.
It is understood that the first message and the second message may further include at least one of the following security parameters: DH group, packaging mode, encryption algorithm and authentication algorithm.
It is understood that the first message and the second message may be border gateway protocol BGP messages or user datagram protocol UDP messages.
Wherein the first IPSec key in method 1400 may be an encryption key or an authentication key; the second IPSec key may also be an encryption key or an authentication key.
It should be noted that, for the method 1400 in the embodiment of the present application, specific implementation and achieved effects can be referred to in the embodiments shown in fig. 2, fig. 6 to fig. 11, and fig. 13 described above.
Fig. 15 shows a flowchart of another method 1500 for secure communication in this embodiment, where the method 1500 is applied in a scenario including a first device and a second device, and the second device is taken as an execution subject, the method 1500 for secure communication may include:
s1501, generating first indication information in a first Internet protocol security (IPSec) aging period of a second device, wherein the first indication information is used for indicating state information corresponding to a public and private key pair generated by the second device in the first IPSec aging period;
s1502, sending the first indication information to the first device.
It is understood that the first device may be device 1 in method 100 and the second device may be device 2 in method 100, then the first indication may be indication 1 in method 100 and the first IPSec aging period is IPSec aging period 1. The first device may also be device 2 in method 100, and the second device is device 1 in method 100, then the first indication information may be indication information 2 in method 100, and the first IPSec aging period is IPSec aging period 2.
In some possible implementations, in this embodiment, the sending, by S1501", the first indication information to the first device may include: sending keep-alive KeepAlive messages or Bidirectional Forwarding Detection (BFD) messages to the first equipment, wherein the first indication information is carried in the KeepAlive messages or the BFD messages.
In other possible implementations, the method 1500 further includes: in a first IPSec aging period, receiving second indication information sent by first equipment, wherein the second indication information is used for indicating state information corresponding to a public and private key pair generated by the first equipment in a second IPSec aging period; establishing a key negotiation template according to the second indication information and the first indication information; and generating a first IPSec key according to the key negotiation template, wherein the first IPSec key is used for protecting data transmitted by the first device and the second device in the first time period. The first indication information is the same as the second indication information, and the key negotiation template is a parallel key negotiation template; or the first indication information is different from the second indication information, and the key negotiation template is a cross key negotiation template.
It can be understood that, when the method 1500 is used to implement the method 100 corresponding to fig. 2 described above, the first device may be, for example, the device 1 in the method 100, and the second device may be the device 2 in the method 100, then the first indication information may be the indication information 1 in the method 100, the second indication information is the indication information 2 in the method 100, the second IPSec aging period is the IPSec aging period 2, the first IPSec aging period is the IPSec aging period 1, and the first IPSec key is the IPSec key 1. When the first device may be device 2 in method 100, and the second device may be device 1 in method 100, then the first indication information may be indication information 2 in method 100, the second indication information is indication information 1 in method 100, the second IPSec aging period is IPSec aging period 1, the first IPSec aging period is IPSec aging period 2, and the first IPSec key is IPSec key 1.
In still other possible implementations, the method 1500 further includes: and sending a first message to the first device in a third IPSec aging period of the second device, where the first message carries third indication information and a first public key generated by the second device in the third IPSec aging period, where the third indication information is used to indicate state information corresponding to the first public key, the third IPSec aging period is the first IPSec aging period or N aging periods are spaced between the third IPSec aging period and the first IPSec aging period, where N is a positive odd number, and the third indication information is the same as the first indication information.
In this implementation, "generating the first IPSec key according to the key negotiation template" may include: receiving a second message sent by the first device in a third IPSec aging period of the second device, where the second message carries a second public key and fourth indication information generated by the first device in a fourth IPSec aging period, the fourth indication information indicates state information corresponding to the second public key, the fourth IPSec aging period is the second IPSec aging period or M aging periods are spaced between the fourth IPSec aging period and the second IPSec aging period, M is a positive odd number, and the fourth indication information is the same as the second indication information; and generating a first IPSec key according to the key negotiation template, the fourth indication information, the second public key, the third indication information generated by the second device in the third IPSec aging period and the first private key.
When the method 1500 is used to implement the method 200 corresponding to fig. 6, the method 300 corresponding to fig. 7, or the method 500 corresponding to fig. 9, for example, the first device may be the device 1 in the foregoing method embodiment, and the second device is the device 2 in the foregoing method embodiment, then, the third indication information is the indication information 3, the fourth indication information is the indication information 4, the third IPSec aging period is the IPSec aging period 3, the fourth IPSec aging period is the IPSec aging period 4, the first packet is the packet 1 or the packet 3 in the foregoing method embodiment, and the second packet is the packet 2 or the packet 4 in the foregoing method embodiment. Or, for example, the first device may also be device 2 in the foregoing method embodiment, and the second device is device 1 in the foregoing method embodiment, then the third indication information is indication information 4, the fourth indication information is indication information 3, the third IPSec aging period is IPSec aging period 4, the fourth IPSec aging period is IPSec aging period 3, the first packet is packet 2 or packet 4 in the foregoing method embodiment, and the second packet is packet 1 or packet 3 in the foregoing method embodiment.
It is understood that the related description of the implementation and the achieved effect can be referred to the related description in the method 200, the method 300 or the method 500. Specifically, when each IPSec aging period of the first device is a first duration, each IPSec aging period of the second device is a second duration, and the first duration and the second duration are equal, the implementation manner may be as shown in method 200 or method 300; when the first duration and the second duration are not equal, see method 500, where "generating the first IPSec key" specifically is: generating the first IPSec key when the following conditions are satisfied, the conditions including: neither the second public key and the first private key that participate in generating the first IPSec key participate in generating IPSec keys other than the first IPSec key.
In still other possible implementations, the method 1500 further includes: and sending a third message to the first device in a fifth IPSec aging period of the second device, wherein the third message carries a third public key and fifth indication information generated by the second device in the fifth IPSec aging period, the fifth indication information indicates state information corresponding to the third public key, and an even number of IPSec aging periods are arranged between the fifth IPSec aging period and the first IPSec aging period. Moreover, the method 1500 further comprises: receiving a fourth message sent by the first device in a fifth IPSec aging period of the second device, wherein the fourth message carries a fourth public key and sixth indication information generated by the first device in a sixth IPSec aging period, the sixth indication information indicates state information corresponding to the fourth public key, an even number of IPSec aging periods are arranged between the sixth IPSec aging period and the second IPSec aging period, and an even number of IPSec aging periods are arranged between the fifth IPSec aging period and the first IPSec aging period; and generating a second IPSec key according to the key negotiation template, the fourth public key and the sixth indication information, a second private key and fifth indication information generated by the second device in a fifth IPSec aging period, wherein the third indication information indicates the fifth IPSec aging period.
It should be noted that, when the method 1500 is used to implement the method 400 corresponding to fig. 8 or the method 600 corresponding to fig. 10, for example, the first device may be the device 1 in the foregoing method embodiment, and the second device is the device 2 in the foregoing method embodiment, then, the fifth indication information is the indication information 5, the sixth indication information is the indication information 6, the fifth IPSec aging period is the IPSec aging period 5, the sixth IPSec aging period is the IPSec aging period 6, the third packet is the packet 5 in the foregoing method embodiment, and the fourth packet is the packet 6 in the foregoing embodiment. Or, for example, the first device may also be the device 2 in the foregoing method embodiment, and the second device is the device 1 in the foregoing method embodiment, then the fifth indication information is the indication information 6, the sixth indication information is the indication information 5, the fifth IPSec aging period is the IPSec aging period 6, the sixth IPSec aging period is the IPSec aging period 5, the third packet is the packet 6 in the foregoing method embodiment, and the fourth packet is the packet 5 in the foregoing embodiment.
It is understood that the related description of the implementation and the achieved effect can be referred to the related description in the method 400 or the method 600. Specifically, when each IPSec aging period of the first device is a first duration, each IPSec aging period of the second device is a second duration, and the first duration and the second duration are equal, the implementation manner may be referred to as method 400; when the first duration and the second duration are not equal, see method 600, where "generating the second IPSec key" specifically is: generating the second IPSec key when the following conditions are satisfied, the conditions including: neither the fourth public key and the second private key that participate in generating the second IPSec key have participated in generating IPSec keys other than the second IPSec key.
It is to be understood that, in the first message and the third message, at least one of the following security parameters of the second device may also be included: DH group, packaging mode, encryption algorithm and authentication algorithm. The second message and the fourth message may further include at least one of the following security parameters of the first device: DH group, packaging mode, encryption algorithm and authentication algorithm.
It is understood that the first message to the fourth message may be border gateway protocol BGP messages or user datagram protocol UDP messages.
Wherein the first IPSec key in method 1500 may be an encryption key or an authentication key; the second IPSec key may also be an encryption key or an authentication key.
It should be noted that, for the method 1500 in the embodiment of the present application, specific implementations and effects achieved by the method can be referred to in the embodiments shown in fig. 2, fig. 6 to fig. 11, and fig. 13 described above.
In addition, the embodiment of the present application further provides a first device 1600, which is shown in fig. 16. The first device 1600 includes a receiving unit 1601, a processing unit 1602, and a transmitting unit 1603. Wherein, the receiving unit 1601 is used for executing the receiving operation executed by the device 1 in the embodiment shown in fig. 2, 6-11, and 13, and the receiving operation in the embodiment shown in fig. 14; the sending unit 1603 is configured to perform the sending operation performed by the apparatus 1 in the embodiment shown in fig. 2, 6-11 and 13, and the sending operation in the embodiment shown in fig. 14; the processing unit 1602 is configured to perform the operations other than the receiving operation and the transmitting operation performed by the device 1 in the embodiments shown in fig. 2, 6-11 and 13, and the operations other than the receiving operation and the transmitting operation in the embodiment shown in fig. 14, for example: the processing unit 1602 may perform the operations in the embodiment of fig. 2: the device 1 establishes a key agreement template according to the indication information 1 and the indication information 2 by the device 1.
In addition, a second apparatus 1700 is also provided in the embodiment of the present application, as shown in fig. 17. The second apparatus 1700 comprises a receiving unit 1701, a processing unit 1702 and a transmitting unit 1703. Wherein, the receiving unit 1701 is used for executing the receiving operation executed by the device 2 in the embodiment shown in fig. 2, 6-11, the receiving operation executed by the device 3 in the embodiment shown in fig. 13, and the receiving operation in the embodiment shown in fig. 15; a sending unit 1703 is configured to perform the sending operation performed by the device 2 in the embodiments shown in fig. 2 and fig. 6 to fig. 11, the sending operation performed by the device 3 in the embodiment shown in fig. 13, and the sending operation in the embodiment shown in fig. 15; the processing unit 1702 is configured to perform the operations performed by the device 2 in the embodiments shown in fig. 2 and 6-11, the operations performed by the device 3 in the embodiment shown in fig. 13, and the operations performed by the device 15 in the embodiments shown in fig. 15, such as: the processing unit 1702 may perform the operations in the embodiment of fig. 2: in IPSec aging period 1 of device 2, device 2 generates indication information 1, and this indication information 1 is used to indicate IPSec aging period 1.
In addition, the embodiment of the present application further provides a first device 1800, which is shown in fig. 18. The first device 1800 includes a communication interface 1801 and a processor 1802 coupled to the communication interface 1801. The communication interface 1801 is configured to perform the foregoing receiving operation and sending operation performed by the device 1 in the embodiments shown in fig. 2, fig. 6 to fig. 11, and fig. 13, and the receiving operation and sending operation in the embodiment shown in fig. 14; the processor 1802 is configured to perform operations other than the receiving operation and the transmitting operation performed by the device 1 in the embodiment shown in fig. 2, 6-11, and 13, and operations other than the receiving operation and the transmitting operation in the embodiment shown in fig. 14. For example: the processor 1802 may perform the operations in the embodiment of fig. 2: the device 1 establishes a key agreement template according to the indication information 1 and the indication information 2 by the device 1.
In addition, a second device 1900 is further provided in the embodiment of the present application, as shown in fig. 19. The second device 1900 includes a communication interface 1901 and a processor 1902 connected to the communication interface 1901. Among them, the communication interface 1901 is used for executing the receiving operation and the sending operation executed by the device 2 in the embodiments shown in fig. 2 and fig. 6-11, the receiving operation and the sending operation executed by the device 3 in the embodiment shown in fig. 13, and the receiving operation and the sending operation in the embodiment shown in fig. 15; the processor 1902 is configured to perform the operations described above in the embodiments shown in fig. 2, 6-11, except for the receiving operation and the transmitting operation performed by the device 2, in the embodiment shown in fig. 13, except for the receiving operation and the transmitting operation performed by the device 3, and in the embodiment shown in fig. 15, except for the receiving operation and the transmitting operation. For example: the processor 1902 may perform the operations in the embodiment of fig. 2: in IPSec aging period 1 of device 2, device 2 generates indication information 1, and this indication information 1 is used to indicate IPSec aging period 1.
In addition, the embodiment of the present application further provides a first device 2000, which is shown in fig. 20. The first device 2000 comprises a memory 2001 and a processor 2002. Wherein the memory 2001 is used for storing program codes; the processor 2002 is configured to execute instructions in the program code, so that the first device 2000 performs the method performed by the device 1 side in the embodiments shown in fig. 2, 6-11 and 13, and the method provided in the embodiment shown in fig. 14.
In addition, a second apparatus 2100 is also provided in the embodiments of the present application, and is shown in fig. 21. The first device 2100 includes a memory 2101 and a processor 2102. Wherein, the memory 2101 is used to store program codes; the processor 2102 is configured to execute instructions in the program code, so that the second device 2100 performs the method performed by the device 2 side in the embodiments shown in fig. 2, 6-11, the method performed by the device 3 side in the embodiment shown in fig. 13, and the method provided in the embodiment shown in fig. 15.
It is understood that, in the above embodiments, the processor may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of a CPU and an NP. The processor may also be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), general Array Logic (GAL), or any combination thereof. The processor may refer to one processor or may include a plurality of processors. The memory may include a volatile memory (RAM), such as a random-access memory (RAM); the memory may also include a non-volatile memory (ROM), such as a read-only memory (read-only memory), a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); the memory may also comprise a combination of memories of the kind described above. The memory may refer to one memory or may include a plurality of memories. In one embodiment, the memory has stored therein computer-readable instructions comprising a plurality of software modules, such as a transmitting module, a processing module, and a receiving module. After the processor executes each software module, the processor can perform corresponding operation according to the instruction of each software module. In the present embodiment, the operation performed by one software module actually refers to an operation performed by the processor according to the instruction of the software module. The processor, upon executing the computer-readable instructions in the memory, may perform all operations that the combined device or remote attestation device may perform, as directed by the computer-readable instructions.
It is understood that, in the above embodiment, the communication interface 1801 of the first device 1800 may be specifically used as the receiving unit 1601 and the sending unit 1603 in the first device 1600, so as to implement data communication between the first device and the second device. Similarly, the communication interface 1901 of the second device 1900 may be specifically used as the receiving unit 1701 and the sending unit 1703 in the second device 1700, so as to implement data communication between the first device and the second device.
In addition, an embodiment of the present application further provides a communication system 2200, which is shown in fig. 22. The communication system 2200 includes a first device 2201 and a second device 2202, where the first device 2201 may specifically be the first device 1600, the first device 1800, or the first device 2000, and the second device 2202 may specifically be the second device 1700, the second device 1900, or the second device 2100.
In addition, the present application also provides a computer-readable storage medium, which stores instructions that, when executed on a computer, cause the computer to perform the method for secure communication in the embodiments shown in fig. 2, fig. 6 to fig. 11, and fig. 13 to fig. 15.
Furthermore, the present application also provides a computer program product, which when running on a computer, causes the computer to execute the method for secure communication in the embodiments shown in fig. 2, fig. 6 to fig. 11, and fig. 13 to fig. 15.
It should be noted that the "device" in this embodiment may be a network device, or may also be other devices such as a base station and a terminal, and the "device" may also be a chip, and specifically may include one chip or multiple chips. The Network device may be, for example, a router, a switch, or a Packet Transport Network (PTN) device.
In the embodiment of the present application, the "first" in the names of "first IPSec aging period", "first IPSec key", and the like is used only for name identification, and does not represent the first in sequence. The same applies to "second" etc.
As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the method of the above embodiments may be implemented by software plus a general hardware platform. Based on such understanding, the technical solution of the present application may be embodied in the form of a software product, which may be stored in a storage medium, such as a read-only memory (ROM)/RAM, a magnetic disk, an optical disk, or the like, and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the method according to the embodiments or some parts of the embodiments of the present application.
All the embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, apparatus embodiments, device embodiments, and system embodiments are described in relative simplicity as they are substantially similar to method embodiments, and reference may be made to some descriptions of method embodiments for related points. The above-described embodiments of the apparatus, device and system are only illustrative, and modules described as separate parts may or may not be physically separate, and parts shown as modules may or may not be physical modules, may be located in one position, or may be distributed on multiple network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement without inventive effort.
The above description is only a preferred embodiment of the present application and is not intended to limit the scope of the present application. It should be noted that, for a person skilled in the art, several improvements and modifications can be made without departing from the scope of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims (25)

1. A method of secure communication, applied to a first device, the method comprising:
receiving first indication information sent by a second device in a second internet protocol security (IPSec) aging period of the first device, wherein the first indication information is used for identifying state information corresponding to a public and private key pair generated in the first IPSec aging period of the second device;
establishing a key negotiation template according to the first indication information and second indication information, wherein the second indication information is used for identifying state information of a public and private key pair generated by the first device in the second IPSec aging period;
and generating a first IPSec key according to the key negotiation template, where the first IPSec key is used to protect data transmitted by the first device and the second device in a first time period, and the first time period is a time period in which the first IPSec key is valid between the first device and the second device.
2. The method of claim 1,
the first indication information is the same as the second indication information, the key agreement template is a parallel key agreement template, and the parallel key agreement template requires that the corresponding state information of a public key and a private key participating in generating the IPSec key are the same; or,
the first indication information is different from the second indication information, the key agreement template is a cross key agreement template, and the cross key agreement template requires that state information corresponding to a public key and a private key participating in generating an IPSec key are different.
3. The method of claim 1, wherein the receiving the first indication information sent by the second device comprises:
receiving keep-alive KeepAlive messages or Bidirectional Forwarding Detection (BFD) messages sent by the second equipment, wherein the first indication information is carried in the KeepAlive messages or the BFD messages.
4. The method of claim 1, further comprising:
and in a fourth IPSec aging period of the first device, receiving a first packet sent by the second device in the third IPSec aging period, where the first packet carries third indication information and a first public key generated by the second device in the third IPSec aging period, where the third indication information is used to indicate state information corresponding to the first public key, and the third indication information is the same as the first indication information.
5. The method of claim 4, wherein generating the first IPSec key based on the key agreement template comprises:
and generating the first IPSec key according to the key agreement template, the third indication information, the first public key, and a first private key and fourth indication information generated by the first device in the fourth IPSec aging period, where the fourth indication information is used to indicate state information corresponding to the first private key, and the fourth indication information is the same as the second indication information.
6. The method of claim 1, further comprising:
receiving a second message sent by the second device in a sixth IPSec aging period of the first device, where the second message carries a second public key and fifth indication information generated by the second device in a fifth IPSec aging period, and the fifth indication information indicates state information corresponding to the second public key;
and generating a second IPSec key according to the key agreement template, the second public key, the fifth indication information, and a second private key and sixth indication information generated by the first device in the sixth IPSec aging period, where the sixth indication information is used to indicate state information corresponding to the second private key, the second IPSec key is used to protect data transmitted by the first device and the second device in a second time period, and the second time period is a time period in which the second IPSec key is valid between the first device and the second device.
7. The method according to any one of claims 4-6, wherein at least one of the following parameters is further included in the first message: DH group, packaging mode, encryption algorithm and authentication algorithm.
8. The method according to any of claims 4-6, wherein the first packet is a Border Gateway Protocol (BGP) message or a User Datagram Protocol (UDP) message.
9. The method of any of claims 1-6, wherein the first IPSec key is an encryption key or an authentication key.
10. The method according to any one of claims 1 to 6, wherein each IPSec aging period of the first device is a first duration, each IPSec aging period of the second device is a second duration, and the first duration and the second duration are not equal to each other, and the generating the first IPSec key specifically includes:
generating the first IPSec key when the following conditions are satisfied, wherein the conditions comprise: and the first public key and the first private key which participate in generating the first IPSec key do not participate in generating other IPSec keys except the first IPSec key.
11. A method of secure communication, applied to a second device, the method comprising:
generating first indication information in a first internet protocol security (IPSec) aging period of the second device, wherein the first indication information is used for indicating state information corresponding to a public and private key pair generated by the second device in the first IPSec aging period;
and sending the first indication information to a first device, so that the first device establishes a key negotiation template according to the first indication information and second indication information, and generates a first IPSec key according to the key negotiation template, wherein the second indication information is used for identifying state information of a public and private key pair generated by the first device in a second IPSec aging period, the first IPSec key is used for protecting data transmitted by the first device and the second device in a first time period, and the first time period is a time period in which the first IPSec key is valid between the first device and the second device.
12. The method of claim 11, wherein the sending the first indication information to the first device comprises:
sending keep-alive KeepAlive messages or Bidirectional Forwarding Detection (BFD) messages to the first equipment, wherein the first indication information is carried in the KeepAlive messages or the BFD messages.
13. The method of claim 11, further comprising:
in the first IPSec aging period, receiving second indication information sent by the first device, wherein the second indication information is used for indicating state information corresponding to a public and private key pair generated by the first device in a second IPSec aging period;
establishing a key negotiation template according to the second indication information and the first indication information;
and generating a first IPSec key according to the key negotiation template, wherein the first IPSec key is used for protecting data transmitted by the first device and the second device in a first time period.
14. The method of claim 13,
the first indication information is the same as the second indication information, the key negotiation template is a parallel key negotiation template, and the parallel key negotiation template requires that the state information corresponding to the public key and the private key participating in generating the IPSec key are the same; or,
the first indication information is different from the second indication information, the key agreement template is a cross key agreement template, and the cross key agreement template requires that state information corresponding to a public key and a private key participating in generating an IPSec key are different.
15. The method of claim 11, further comprising:
and sending a first message to the first device in a third IPSec aging period of the second device, where the first message carries third indication information and a first public key generated by the second device in the third IPSec aging period, where the third indication information is used to indicate state information corresponding to the first public key, and the third indication information is the same as the first indication information.
16. The method of any of claims 13-15, wherein generating the first IPSec key based on the key agreement template comprises:
receiving a second message sent by the first device in a third IPSec aging period of the second device, where the second message carries a second public key and fourth indication information generated by the first device in a fourth IPSec aging period, and the fourth indication information indicates state information corresponding to the second public key, and the fourth indication information is the same as the second indication information;
and generating the first IPSec key according to the key negotiation template, the fourth indication information, the second public key, and third indication information and a first private key, which are generated by the second device in the third IPSec aging period, wherein the third indication information indicates state information corresponding to the first private key.
17. The method according to any one of claims 11-15, further comprising:
and sending a third message to the first device in a fifth IPSec aging period of the second device, where the third message carries a third public key and fifth indication information generated by the second device in the fifth IPSec aging period, and the fifth indication information indicates status information corresponding to the third public key.
18. The method according to any one of claims 13-15, further comprising:
receiving a fourth message sent by the first device in a fifth IPSec aging period of the second device, where the fourth message carries a fourth public key and sixth indication information generated by the first device in a sixth IPSec aging period, and the sixth indication information indicates status information corresponding to the fourth public key;
and generating a second IPSec key according to the key negotiation template, the fourth public key, the sixth indication information, and a second private key and fifth indication information generated by the second device in the fifth IPSec aging period, where the fifth indication information indicates status information corresponding to the second private key.
19. The method according to any one of claims 13 to 15, wherein each IPSec aging period of the first device is a first duration, each IPSec aging period of the second device is a second duration, and the first duration and the second duration are not equal to each other, and the generating the first IPSec key specifically includes:
generating the first IPSec key when the following conditions are satisfied, wherein the conditions comprise: and the second public key and the first private key which participate in generating the first IPSec key do not participate in generating other IPSec keys except the first IPSec key.
20. A first device, comprising:
a communication interface; and
a processor coupled to the communication interface;
the communication interface and the processor, the first device being configured to perform the method of any of the preceding claims 1-10.
21. A second apparatus, comprising:
a communication interface; and
a processor connected to the communication interface;
the communication interface and the processor, the second device being configured to perform the method of any of the preceding claims 11-19.
22. A first device, wherein the first device comprises a memory and a processor;
the memory for storing program code;
the processor, configured to execute instructions in the program code to cause the first device to perform the method of any of claims 1-10 above.
23. A second device, wherein the second device comprises a memory and a processor;
the memory for storing program code;
the processor, configured to execute the instructions in the program code, to cause the second device to perform the method of any of the preceding claims 11-19.
24. A computer-readable storage medium having stored therein instructions which, when run on a computer, cause the computer to perform the method of any of claims 1-10 or claims 11-19 above.
25. A communication system comprising a first device as claimed in claim 20 or 22 and a second device as claimed in claim 21 or 23.
CN201911253333.4A 2019-11-01 2019-12-09 Method and equipment for secure communication Active CN112787803B (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/CN2020/116962 WO2021082813A1 (en) 2019-11-01 2020-09-23 Secure communication method and device
EP20881986.2A EP4040752A4 (en) 2019-11-01 2020-09-23 Secure communication method and device
US17/732,165 US20220255911A1 (en) 2019-11-01 2022-04-28 Method for Secure Communication and Device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2019110609606 2019-11-01
CN201911060960 2019-11-01

Publications (2)

Publication Number Publication Date
CN112787803A CN112787803A (en) 2021-05-11
CN112787803B true CN112787803B (en) 2023-01-13

Family

ID=75749942

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911253333.4A Active CN112787803B (en) 2019-11-01 2019-12-09 Method and equipment for secure communication

Country Status (1)

Country Link
CN (1) CN112787803B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115333839B (en) * 2022-08-15 2023-11-07 中国电信股份有限公司 Data security transmission method, system, equipment and storage medium

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101645771A (en) * 2008-08-04 2010-02-10 深圳华为通信技术有限公司 Method, device and system for key synchronization
CN107682284B (en) * 2017-08-02 2021-06-01 华为技术有限公司 Method and network equipment for sending message
CN110166426A (en) * 2019-04-11 2019-08-23 北京媒球信息科技有限公司 Information sends terminal, receives terminal and its secret communication method, storage medium

Also Published As

Publication number Publication date
CN112787803A (en) 2021-05-11

Similar Documents

Publication Publication Date Title
EP3286896B1 (en) Scalable intermediate network device leveraging ssl session ticket extension
US20070271606A1 (en) Apparatus and method for establishing a VPN tunnel between a wireless device and a LAN
CN107046495B (en) Method, device and system for constructing virtual private network
US9516065B2 (en) Secure communication device and method
WO2021068777A1 (en) Methods and systems for internet key exchange re-authentication optimization
CN101572644B (en) Data encapsulation method and equipment thereof
US20180176230A1 (en) Data packet transmission method, apparatus, and system, and node device
CN113950802B (en) Gateway device and method for performing site-to-site communication
US11006346B2 (en) X2 service transmission method and network device
CN108924157B (en) Message forwarding method and device based on IPSec VPN
US11943209B2 (en) Rekeying a security association SA
CN112787803B (en) Method and equipment for secure communication
CN117254976B (en) National standard IPsec VPN realization method, device and system based on VPP and electronic equipment
US11888982B2 (en) Rekeying a security association SA
CN113438094B (en) Method and equipment for automatically updating manually configured IPSec SA
WO2023231311A1 (en) Vxlan tunnel authentication method and system, and access gateway and network access device
EP4040752A1 (en) Secure communication method and device
CN111740893B (en) Method, device, system, medium and equipment for realizing software-defined VPN
Badra et al. Adding identity protection to eap-tls smartcards
WO2014100967A1 (en) Method, apparatus, device and system for ipsec negotiation
EP3131269B1 (en) Method and device for conducting ah authentication on ipsec packet which has gone through nat traversal
US20220038443A1 (en) Methods and systems of a packet orchestration to provide data encryption at the ip layer, utilizing a data link layer encryption scheme
US20240106647A1 (en) Methods and systems of a packet orchestration to provide data encryption at the ip layer, utilizing a data link layer encryption scheme
CN114567478A (en) Communication method and device
CN112733175A (en) Data encryption method and device based on ESP (electronic stability program) protocol

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant