Patent Description:
Internet protocol security (IPSec) is a set of framework protocols defined by the Internet Engineering Task Force (IETF), which ensures security of communication over the Internet by using encrypted secure transmission channels. For secure transmission of data packets between devices based on an IPSec technology, a current commonly - used manner is to perform IPSec key negotiation based on an Internet key exchange (IKE) protocol. Based on IKE, IPSec security configuration parameters are exchanged by exchanging a plurality of session messages, to complete IPSec security association (SA) negotiation. Security protection is performed on packets based on an IPSec key determined through the negotiation.

In the context of the Internet of everything, for example, in a network scenario such as the Internet of things (IoT), a quantity of devices continuously increases. If an IPSec key is still determined through negotiation by using the IKE protocol, each device needs to exchange massive packets with other devices. This takes a long time, reduces efficiency, and wastes a large quantity of network resources.

<CIT> relates to a system and methodology facilitating network security and data access in an industrial control environment. An industrial control system is provided that includes an industrial controller to communicate with a network. At least one security layer can be configured in the industrial controller, wherein the security layer can be associated with one or more security components to control and/or restrict data access to the controller. An operating system manages the security layer in accordance with a processor to limit or mitigate communications from the network based upon the configured security layer or layers.

<CIT> discloses a communication device which performs automatic rekeying in a secured communication system.

<NPL> describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm.

<NPL> describes version <NUM> of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).

In view of this, embodiments of this application provide a method for secure communication and a device. When IPSec needs to be used between devices for secure communication, an IPSec key between the devices can be quickly and efficiently obtained, to implement secure communication in a network. The IPSec key in embodiments of this application may include an IPSec encryption key and/or an IPSec authentication key. Advantageous features are defined in the dependent claims.

To describe technical solutions in embodiments of this application more clearly, the following briefly describes the accompanying drawings for describing embodiments. It is clear that the accompanying drawings in the following description show merely some embodiments of this application, and a person of ordinary skill in the art may derive other drawings from these accompanying drawings.

With popularization of the Internet, more and more data packets are transmitted by using the Internet. To overcome a problem that data transmission in the Internet in a plaintext form is insecure, an Internet protocol security (English: Internet Protocol Security, IPSec for short) technology is proposed. The IPSec technology is a set of open network security protocols based on cryptography, works at an Internet protocol (English: Internet Protocol, IP for short) layer, and provides protection for IP layer and upper-layer protocols, for example, may provide security services such as IP packet encryption, data integrity check, data source verification, and anti-replay.

IPSec includes a set of network security protocols, for example, may include an authentication header (English: Authentication Header, AH for short) protocol, an encapsulating security payload (Encapsulating Security Payload, ESP for short) protocol, an encryption algorithm, an authentication algorithm, and an Internet key exchange (English: Internet Key Exchange, IKE for short) protocol. The AH protocol can provide data source verification and data integrity check functions. In addition to the data source verification and data integrity check functions, the ESP protocol can further provide an IP packet encryption function. The encryption algorithm may include a data encryption standard (English: Data Encryption Standard, DES for short) algorithm, a triple data encryption standard (3DES) algorithm, an advanced encryption standard (AES) algorithm, and the like. The authentication algorithm may include a message digest (MD) algorithm and a secure hash algorithm (SHA), such as MD5, SHA1, and SHA2. The IKE protocol may include, for example, a key DH exchange algorithm and an Internet security association key management protocol (ISAKMP). Essentially, the IKE protocol may be used to determine an IPSec SA through negotiation by exchanging packets between devices.

The IPSec SA is a data basis for IPSec communication between the devices. The devices determine an IPSec SA through negotiation and perform IPSec communication based on the IPSec SA. The IPSec SA may specifically include: a key DH exchange group, an encapsulation mode, an authentication algorithm, an encryption algorithm, an encryption key, an authentication key, and the like. The IPSec SA is used to guide secure data packet transmission between the devices.

An IPSec key is a key that is synthesized based on a private key generated by a local device and a public key sent by a peer device after public key exchange between the two devices. An IPSec key generated by using a symmetric key algorithm is a shared key consistent between two devices communicating with each other, and is used to protect data packets exchanged between the devices.

In an example, the IPSec key is an encryption key. <FIG> shows a process of determining an encryption key through negotiation based on a key DH exchange algorithm. The scenario includes a device <NUM>, a device <NUM>, and a route reflector (English: Route Reflector, RR for short) <NUM>. The device <NUM> and the device <NUM> are two devices participating in communication (which are referred to as communication peers for short). Referring to <FIG>, for example, the process of determining an encryption key through negotiation may include the following steps. The device <NUM>, the device <NUM>, and the RR <NUM> respectively generate corresponding private keys a, b, and c. The device <NUM>, the device <NUM>, and the RR <NUM> respectively calculate corresponding public keys based on the generated private keys, to obtain public keys A, B, and C. The device <NUM> and the device <NUM> respectively send the public keys A and B to the RR <NUM>, and the RR <NUM> floods a network with the public keys A and B, as well as the public key C of the RR <NUM>. The device <NUM> generates an encryption key<NUM> based on the public key B and the private key a, and the device <NUM> generates an encryption key<NUM> based on the public key C and the private key a. Similarly, the device <NUM> generates an encryption key<NUM> based on the public key A and the private key b, and the device <NUM> generates an encryption key<NUM> based on the public key C and the private key b. The RR <NUM> generates an encryption key<NUM> based on the public key A and the private key c, and the RR <NUM> generates an encryption key<NUM> based on the public key B and the private key c. The encryption key<NUM> and the encryption key<NUM> are consistent, denoted as an encryption key (also referred to as a shared key) between the device <NUM> and the device <NUM>. Similarly, the encryption key<NUM> and the encryption key<NUM> are consistent, and the encryption key<NUM> and the encryption key<NUM> are consistent.

An IPSec security parameter (such as the public key and the private key) of the device is continuously updated. Each time the IPSec security parameter is updated, it is considered that another IPSec aging period starts. Therefore, IPSec key negotiation needs to be performed again to determine an IPSec key corresponding to the new IPSec aging period starting.

Currently, IPSec key negotiation between devices is generally implemented in a process in which an IPSec SA is dynamically negotiated by using the IKE protocol. The IKE protocol is an application layer protocol based on a user datagram protocol (UDP). However, when the IKE protocol is used to negotiate and determine an IPSec key for a pair of devices, at least six messages need to be exchanged between the pair of devices. In many large-scale networking scenarios (such as an IoT scenario), due to an increasing quantity of devices and a continuously updated IPSec security parameter, each device needs to exchange massive messages with other devices to negotiate an IPSec key in each IPSec aging period. This consumes many resources in the device and the network. Moreover, the manner of IPSec key negotiation using the IKE protocol has problems of long time consumption and low efficiency. In a scenario with an increasing quantity of devices in the network, a requirement to determine an IPSec key to implement quick and efficient secure communication cannot be met.

Based on this, in embodiments of this application, a method for quick, efficient, and convenient secure communication is provided. A key negotiation template is established on two devices communicating with each other, and each time an IPSec key needs to be negotiated, a local device may generate the IPSec key according to a negotiation rule of the key negotiation template based on a received public key generated by a peer device in a current IPSec aging period and received status information corresponding to the public key that are sent by the peer device, and a private key generated by the local device in a current IPSec aging period and status information corresponding to the private key. In the technical solution of this application, IPSec key negotiation is not performed based on the IKE protocol. Compared with a manner in which a plurality of packets need to be exchanged when an IPSec key is negotiated between two devices by using the IKE protocol, the technical solution of this application reduces a quantity of packets exchanged between the two devices, and improves IPSec key negotiation efficiency, and reduces system resource usage. In large-scale networking scenarios such as IoT, when massive devices are interconnected, massive packets exchanged due to negotiation performed based on the IKE protocol are greatly reduced, thereby reducing system resource usage. In this application, status information corresponding to a public-private key pair in an IPSec aging period, status information corresponding to a public key in the IPSec aging period, and status information corresponding to a private key in the IPSec aging period are a same piece of status information.

Before specific embodiments of this application are described, some basic concepts in this application are briefly described first.

The IPSec aging period is a validity period of an IPSec security parameter on the device, and is used to indicate a frequency of updating the IPSec security parameter. The device may predefine an IPSec aging period (for example, one day) of the device, generate, in each IPSec aging period, a public-private key pair in the IPSec aging period, and obtain, by exchanging a public key in the newly generated public-private key pair, an IPSec key corresponding to the IPSec aging period, to implement secure communication in the IPSec aging period. For example, assuming that the device <NUM> defines an IPSec aging period to be <NUM> hours, the device <NUM> generates a private key <NUM> and a public key <NUM> when the first IPSec aging period starts, and after <NUM> hours, the device <NUM> enters the second IPSec aging period, and generates a private key <NUM> and a public key <NUM> that correspond to the second IPSec aging period. Durations of IPSec aging periods defined by devices in the network may be the same or different. This is not specifically limited herein. The public-private key pair in this application includes a public key and a private key.

It may be understood that, in each IPSec aging period, the device generates a new public-private key pair different from a public-private key pair in a previous IPSec aging period.

The key negotiation template is a template that is established based on indication information exchanged between devices communicating with each other and used to indicate status information of a public-private key pair generated in an IPSec aging period, and that is used to guide determining of a corresponding IPSec key in each IPSec aging period. For example, when establishing the first communication connection, two devices (the two devices may also be referred to as communication peers) establish a key negotiation template. The key negotiation template may be classified into a parallel key negotiation template and a cross key negotiation template based on whether indication information exchanged between the communication peers during establishment of the key negotiation template is the same. If the exchanged indication information is the same, the established key negotiation template is a parallel key negotiation template; otherwise, if the exchanged indication information is different, the established key negotiation template is a cross key negotiation template.

Once established between the two devices, the key negotiation template generally cannot be changed until the communication connection between the two devices is disconnected. For details and implementations of establishing the key negotiation template, refer to related descriptions in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG>.

It should be noted that, in the IPSec SA, the IPSec key changes with the IPSec aging period, but other IPSec security parameters (such as an encryption algorithm, an authentication algorithm, and an encapsulation mode) may change or remain unchanged in different aging periods. Embodiments of this application focus on a process of determining an IPSec key through negotiation.

<FIG> is a schematic flowchart of a method <NUM> for secure communication according to an embodiment of this application. Referring to <FIG>, the method <NUM> is applied to a network including a device <NUM> and a device <NUM>. For example, the method <NUM> may include the following steps.

The device <NUM> generates indication information <NUM> in an IPSec aging period <NUM> of the device <NUM>, where the indication information <NUM> is used to indicate status information corresponding to a public-private key pair generated in the IPSec aging period <NUM> of the device <NUM>.

Indication information mentioned in this application, or indication information numbered by using Arabic numerals, such as the indication information <NUM>, indication information <NUM>,. , or indication information numbered by using ordinal numerals, such as first indication information, second indication information,. , is used to indicate status information corresponding to a public key and/or a private key generated in a current IPSec aging period by a device that sends the indication information. Status information corresponding to a public key and/or a private key generated in each IPSec aging period is iterated according to an agreed rule when each IPSec aging and updating occurs, that is, indication information is iterated according to an agreed rule when each IPSec aging and updating occurs.

In a specific implementation, the indication information may be a numerical value, and IPSec aging period changes are indicated by using numerical values that occur alternately. The numerical values that occur alternately are used as indication information, and may be denoted as tick values. The tick value is used to indicate a state of a public-private key pair generated by the device in an IPSec aging period. State changes of the device from one IPSec aging period to a next IPSec aging period are indicated by using alternate occurrences of two values, which may also be understood as indicating state changes of the device from one public-private key pair to another public-private key pair. For example, the tick values are <NUM> and <NUM>. The tick value equal to <NUM> may indicate an ith IPSec aging period (i=<NUM>, <NUM>, <NUM>,. ), the tick value equal to <NUM> indicates a jth IPSec aging period (j=<NUM>, <NUM>, <NUM>,. ), and the ith IPSec aging period and the jth IPSec aging period occur alternately. Public-private key pair updates and IPSec aging period changes of the device are indicated by using alternate occurrences of the tick values <NUM> and <NUM>.

In another specific implementation, alternatively, the indication information may be a character string, and public-private key pair updates and IPSec aging period changes of the device are indicated by using character strings that occur alternately. For example, when the indication information of the device changes from a character string a to a character string b or changes from the character string b to the character string a, it indicates that the device is updated from a current IPSec aging period to a next IPSec aging period.

It should be noted that the indication information includes, but is not limited to, forms of the character string and the tick value, and any form in which the IPSec aging period change may be indicated by using a predetermined rule falls in the scope of the indication information in this embodiment of this application.

The device <NUM> and the device <NUM> may respectively define their own IPSec aging periods, and define, as indication information, status information indicating a public-private key pair generated after the IPSec aging period changes. For example, the device <NUM> may define a duration of each IPSec aging period of the device <NUM> to be <NUM> hours, and define indication information to be a tick value, and the device <NUM> may define a duration of each IPSec aging period of the device <NUM> to be <NUM> hours, and define indication information to be a tick value. The indication information <NUM> in S101 may be, for example, <NUM>, and is used to indicate the IPSec aging period <NUM> of the device <NUM>.

The device <NUM> sends the indication information <NUM> to the device <NUM>.

During specific implementation, S102 may be implemented by the device <NUM> by sending a packet to the device <NUM>. The packet may be, for example, a connection detection packet, or the packet may be, for example, a newly defined packet, used to negotiate a key negotiation template. A specific packet format is not specifically limited in this application. For example, the device <NUM> sends a connection detection packet <NUM> to the device <NUM>. The connection detection packet <NUM> includes a field <NUM>, and is used to carry the indication information <NUM> of the device <NUM>. The field <NUM> is used to indicate the device <NUM> to establish a key negotiation template. The connection detection packet is a detection packet used to detect whether a connection exists between devices. The connection detection packet is frequently exchanged between devices and is regular. Therefore, by selecting the connection detection packet to exchange indication information, current indication information of a local device can be reliably and quickly notified to a peer device, to reliably and quickly trigger establishment of a key negotiation template, and enable secure communication.

The connection detection packet includes, but is not limited to, a keepalive (English: KeepAlive) packet and a bidirectional forwarding detection (English: Bidirectional Forwarding Detection, BFD for short) packet. In this application, the connection detection packet is extended with a new field. For example, a type-length-value (English: Type-Length-Value, TLV for short) field or a type-value (English: Type-Value, TV for short) field is added, to carry the indication information. The KeepAlive packet is used as an example. Referring to <FIG>, the KeepAlive packet includes an IP header, a generic routing encapsulation (English: Generic Routing Encapsulation, GRE for short) header, and payload (English: payload). In this case, a TLV field or a TV field may be added to the payload, and the indication information <NUM> is carried in a Value part of the added TLV field or TV field. The added TLV field or TV field is used to indicate the device <NUM> to establish a key negotiation template based on the indication information <NUM>. The indication information is carried in the connection detection packet that needs to be transmitted between the devices, so that a new packet does not need to be defined to transmit the indication information. This saves network resources. Moreover, because the connection detection packet is characterized by frequent exchange and strong regularity, it is more reliable and quick to exchange the indication information by using the connection detection packet so as to trigger establishment of a key negotiation template, thereby improving efficiency of obtaining an IPSec key.

The device <NUM> receives, in an IPSec aging period <NUM> of the device <NUM>, the indication information <NUM> sent by the device <NUM>.

The device <NUM> generates indication information <NUM> in the IPSec aging period <NUM> of the device <NUM>, where the indication information <NUM> is used to indicate status information of a public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>.

It may be understood that, the indication information <NUM> includes, but is not limited to, a character string and a tick value. For a specific description, refer to the description about the indication information in S101.

For example, the indication information <NUM> of the device <NUM> in the IPSec aging period <NUM> is <NUM>. For another example, the indication information <NUM> of the device <NUM> in the IPSec aging period <NUM> is <NUM>.

The device <NUM> establishes a key negotiation template based on the indication information <NUM> and the indication information <NUM>.

The key negotiation template is used to guide the device <NUM> to generate a corresponding IPSec key in each IPSec aging period. Based on whether the indication information <NUM> and the indication information <NUM> are the same, the established key negotiation templates may be classified into a parallel key negotiation template and a cross key negotiation template. When the indication information <NUM> and the indication information <NUM> are the same, the key negotiation template is a parallel key negotiation template. When the indication information <NUM> and the indication information <NUM> are different, the key negotiation template is a cross key negotiation template.

For example, the indication information is a tick value. In a specific implementation, the indication information <NUM> and the indication information <NUM> are the same. For example, assuming that both the indication information <NUM> and the indication information <NUM> are <NUM>, the key negotiation template established by the device <NUM> in S105 is a parallel key negotiation template. For another example, assuming that both the indication information <NUM> and the indication information <NUM> are <NUM>, the key negotiation template established by the device <NUM> in S105 is also a parallel key negotiation template. It should be noted that, in subsequent IPSec aging periods, provided that tick values of the device <NUM> and the device <NUM> are the same, that is, the tick values of the device <NUM> and the device <NUM> are both <NUM>, or the tick values of the device <NUM> and the device <NUM> are both <NUM>, it may be considered that the parallel key negotiation template is met. For example, referring to <FIG>, which shows an example in which durations of IPSec aging periods on the device <NUM> and the device <NUM> are consistent, on the device <NUM>, starting from the first IPSec aging period, corresponding tick values are <NUM>, <NUM>, <NUM>, <NUM>,. , respectively; and on the device <NUM>, starting from the first IPSec aging period, corresponding tick values are <NUM>, <NUM>, <NUM>, <NUM>,. , respectively. After the parallel key negotiation template is established, when an IPSec key is subsequently generated based on the parallel key negotiation template, a matching condition of the parallel key negotiation template needs to be met, that is, a public key of a peer end and a private key of a local end that are used to generate the IPSec key correspond to a same tick value.

In another specific manner, the indication information <NUM> and the indication information <NUM> are different. For example, the indication information <NUM> is <NUM>, the indication information <NUM> is <NUM>, and the key negotiation template established by the device <NUM> in S105 is a cross key negotiation template. For another example, the indication information <NUM> is <NUM>, the indication information <NUM> is <NUM>, and the key negotiation template established by the device <NUM> in S105 is also a cross key negotiation template. It should be noted that, in subsequent IPSec aging periods, provided that tick values of the device <NUM> and the device <NUM> are different, that is, the tick value of the device <NUM> is <NUM> and the tick value of the device <NUM> is <NUM>, or the tick value of the device <NUM> is <NUM> and the tick value of the device <NUM> is <NUM>, it may be considered that the cross key negotiation template is met. For example, referring to <FIG>, which shows an example in which durations of IPSec aging periods on the device <NUM> and the device <NUM> are consistent, on the device <NUM>, starting from the first IPSec aging period, corresponding tick values are <NUM>, <NUM>, <NUM>, <NUM>,. , respectively; and on the device <NUM>, starting from the first IPSec aging period, corresponding tick values are <NUM>, <NUM>, <NUM>, <NUM>,. , respectively. After the cross key negotiation template is established, when an IPSec key is subsequently generated based on the cross key negotiation template, a matching condition of the cross key negotiation template needs to be met, that is, a public key of a peer end and a private key of a local end that are used to generate the IPSec key correspond to different tick values. It may be understood that, because an IPSec aging period generally has a relatively long duration, and time for the device <NUM> and the device <NUM> to establish a key negotiation template is very close, in this embodiment of this application, key negotiation templates established on the device <NUM> and the device <NUM> are a same key negotiation template.

The device <NUM> generates an IPSec key <NUM> based on the key negotiation template, where the IPSec key <NUM> is used to protect data transmitted between the device <NUM> and the device <NUM> in a time period <NUM>.

It may be understood that, after the key negotiation template is established, the device <NUM> may determine, through negotiation based on the established key negotiation template, an IPSec key corresponding to a current IPSec aging period, or the device <NUM> may also determine, through negotiation based on the established key negotiation template, an IPSec key corresponding to a subsequent IPSec aging period.

The IPSec key is used to perform security protection on data transmitted between the devices. The device generally determines whether current indication information of a local end and current indication information of a peer end meet a matching condition of the key negotiation template. If the matching condition is met, the device may generate an IPSec key based on a current private key of the local end and a current public key of the peer end.

In a specific implementation, S106 may include: S1061. The device <NUM> sends a packet <NUM> to the device <NUM> in an IPSec aging period <NUM> of the device <NUM>. The packet <NUM> carries indication information <NUM> and a public key <NUM>, and the public key <NUM> is generated by the device <NUM> in the IPSec aging period <NUM>. The device <NUM> receives, in an IPSec aging period <NUM> of the device <NUM>, the packet <NUM> sent by the device <NUM>. The device <NUM> generates the IPSec key <NUM> based on the key negotiation template, the indication information <NUM>, the public key <NUM>, and indication information <NUM> and a private key <NUM> of the device <NUM> in the IPSec aging period <NUM>.

In a specific implementation, the packet <NUM> may be a border gateway protocol (English: Border Gateway Protocol, BGP for short) message or a user datagram protocol (English: User Datagram Protocol, UDP for short) packet. Alternatively, the packet <NUM> may be a newly defined dedicated packet.

When the packet <NUM> is a BGP message, the BGP message may be extended to carry the current public key <NUM> and indication information <NUM>. For example, a tunnel attribute may be added to the BGP message, to carry the public key <NUM> and the indication information <NUM>.

In an example, a tunnel attribute may be extended in the BGP message, and the extended tunnel attribute may be, for example, a TLV field or a TV field. The TLV field is used as an example. As shown in <FIG>, a tunnel attribute type Tunnel Type field in the extended tunnel attribute TLV field is used to indicate that the tunnel attribute carries an IPSec security parameter, and a tunnel attribute value Tunnel Value field is shown in <FIG>. A plurality of TLV fields may be extended to carry IPSec security parameters.

In another example, alternatively, a plurality of tunnel attributes may be extended in the BGP message, and each extended tunnel attribute may be a TLV field or a TV field. The TLV field is used as an example. A Tunnel Type field in each extended tunnel attribute TLV field is used to indicate one or more IPSec security parameters carried in the tunnel attribute, and one or more TLV fields may be extended in a Value field, to indicate a specific value of the IPSec security parameter indicated in the Tunnel Type field.

It may be understood that, in one case, if the IPSec key is an encryption key, the BGP message may include two extended TLV fields, and Value fields of the two extended TLV fields are respectively used to carry the public key <NUM> for encryption and the indication information <NUM>. In another case, if the IPSec key is an authentication key, the BGP message may include two extended TLV fields, and Value fields of the two extended TLV fields are respectively used to carry the public key <NUM> for authentication and the indication information <NUM>. In still another case, if the IPSec key includes an authentication key and an encryption key, the BGP message may include three extended TLV fields, and Value fields of the three extended TLV fields are respectively used to carry the public key <NUM> for encryption, the public key <NUM> for authentication, and the indication information <NUM>. It should be noted that, the BGP message may further carry security parameters such as a DH group, an encapsulation mode, an encryption algorithm, and an authentication algorithm by extending more TLV fields in an added tunnel attribute or adding more tunnel attributes, to negotiate content that needs to be met for secure communication other than the IPSec key in an IPSec SA.

In a specific implementation, the packet <NUM> is a UDP packet, and the UDP packet may be extended to carry the indication information <NUM> and the public key <NUM>. The UDP packet may be further extended to carry security parameters such as a DH group, an encapsulation mode, an encryption algorithm, and an authentication algorithm. For example, a TLV field or a TV field may be extended in payload (English: payload) of the UDP packet, and the extended TLV field or TV field is used to carry the current public key <NUM> and indication information <NUM>.

In some possible implementations, in addition to carrying the public key <NUM> and the indication information <NUM> of the device <NUM> in the current IPSec aging period, the packet <NUM> further carries at least one of the following IPSec security parameters: an encapsulation mode <NUM>, a DH group <NUM>, an encryption algorithm <NUM>, and an authentication algorithm of the device <NUM>. In this case, the method <NUM> may further include: The device <NUM> determines whether the security parameter of the device <NUM> matches a current security parameter of the device <NUM>, and if they match, determines that the matched security parameter and the IPSec key <NUM> are an IPSec SA. The IPSec SA is used to implement secure communication between the device <NUM> and the device <NUM> in the time period <NUM>, and the current security parameter of the device <NUM> is at least one of an encapsulation mode <NUM>, an encryption algorithm <NUM>, and an authentication algorithm <NUM>.

In some specific implementations, the DH group, the encapsulation mode, the encryption algorithm, and the authentication algorithm may also be carried in an extended TLV field of the BGP message or the UDP packet. The BGP message is used as an example. In one case, a tunnel attribute may be added to the BGP message, at least six TLV fields are extended in the tunnel attribute, and each TLV field carries one of the parameters: the public key, the indication information, the DH group, the encapsulation mode, the encryption algorithm, and the authentication algorithm. In another case, at least six tunnel attributes may be added to the BGP message, and the indication information, the public key, the DH group, the encapsulation mode, the encryption algorithm, and the authentication algorithm are respectively carried in the tunnel attributes.

In this way, according to the method provided in this embodiment of this application, a function of quickly and accurately determining an IPSec key can be implemented, and more content in an IPSec SA can be determined through negotiation by carrying another security parameter, thereby providing more data bases for implementing secure communication based on IPSec.

After "the device <NUM> generates indication information <NUM> in the IPSec aging period <NUM> of the device <NUM>" in S104, the method <NUM> may further include: S107. The device <NUM> sends the indication information <NUM> to the device <NUM>. The device <NUM> receives, in the IPSec aging period <NUM> of the device <NUM>, the indication information <NUM> sent by the device <NUM>. The device <NUM> establishes a key negotiation template based on the indication information <NUM> and the indication information <NUM>. The device <NUM> generates the IPSec key <NUM> based on the key negotiation template. For S107 and S108, refer to the related descriptions of S102 and S103, for S109, refer to the related description of S105, and for S110, refer to the related description of S106. Specific implementations are not described in detail again. S110 may specifically include: The device <NUM> may determine, through negotiation based on the established key negotiation template, an IPSec key corresponding to a current IPSec aging period, or the device <NUM> may also determine, through negotiation based on the established key negotiation template, an IPSec key corresponding to a subsequent IPSec aging period.

In the time period <NUM>, the method <NUM> may further include: After S106, the device <NUM> sends, to the device <NUM>, data on which security protection is performed by using the IPSec key <NUM>. After S110, the device <NUM> sends, to the device <NUM>, data on which security protection is performed by using the IPSec key <NUM>.

In an example, if exchanged data needs to be encrypted, the IPSec key may be configured as an encryption key, and the IPSec key <NUM> generated in S106 and S <NUM> is an encryption key <NUM>. In this case, that the device <NUM> performs security protection on data <NUM> by using the IPSec key <NUM> means that the device <NUM> encrypts the data <NUM> by using the encryption key <NUM> and then transmits the data <NUM> to the device <NUM>, and the device <NUM> decrypts received data based on the encryption key <NUM> to obtain the data <NUM>.

In another example, if authentication needs to be performed on exchanged data, the IPSec key may be configured as an authentication key, and the IPSec key <NUM> generated in S106 and S110 is an authentication key <NUM>. In this case, that the device <NUM> performs security protection on data <NUM> by using the IPSec key <NUM> means that the device <NUM> authenticates the data <NUM> by using the authentication key <NUM>. For example, for an IP packet, a digital signature is generated based on the authentication key and an authentication algorithm, and the device <NUM> authenticates integrity and authenticity of the IP packet based on the digital signature, to ensure secure communication.

In still another example, if encryption and authentication need to be performed on an exchanged data packet, the IPSec key may be configured to include an encryption key and an authentication key, and the IPSec key <NUM> generated in S106 and S110 includes an encryption key <NUM> and an authentication key <NUM>. In this case, that the device <NUM> performs security protection on data <NUM> by using the IPSec key <NUM> means that the device <NUM> first encrypts the data <NUM> by using the encryption key <NUM>, then issues a digital signature to encrypted data by using the authentication key <NUM>, and sends the encrypted data to the device <NUM>, and the device <NUM> performs integrity and authenticity authentication on the digital signature based on the authentication key <NUM>, and after the authentication succeeds, performs decryption by using the encryption key <NUM> to obtain the data <NUM>.

It should be noted that, this embodiment of this application is applicable to the following scenarios: Scenario <NUM>: The device <NUM> and the device <NUM> may be directly connected. In this case, operations such as sending and receiving in the embodiment shown in <FIG> are performed through direct information exchange between the device <NUM> and the device <NUM>. Scenario <NUM>: The device <NUM> and the device <NUM> may alternatively be indirectly connected. For example, the device <NUM> is connected to the device <NUM> by using another device such as a controller. In this case, operations such as sending and receiving in the embodiment shown in <FIG> are completed by using the device such as the controller by forwarding information exchanged between the device <NUM> and the device <NUM>. Scenario <NUM> is used as an example for related descriptions in this embodiment of this application.

In this way, in this embodiment of this application, when a secure connection needs to be established, two devices participating in communication pre-establish a key negotiation template, so that during subsequent IPSec key negotiation, each device can quickly generate a corresponding IPSec key in a current IPSec aging period of the device based on the pre-established key negotiation template. In this way, in the technical solution of this application, IPSec key negotiation is not performed based on an IKE protocol. Therefore, compared with a manner in which a plurality of packets need to be exchanged when an IPSec key is negotiated between two devices by using the IKE protocol, the technical solution of this application effectively reduces a quantity of packets exchanged between the two devices, and improves IPSec key negotiation efficiency, and reduces system resource usage. Especially in large-scale networking scenarios such as IoT, when massive devices are interconnected, massive packets exchanged due to negotiation performed based on the IKE protocol are greatly reduced, thereby reducing system resource usage.

In some specific embodiments, to avoid insecure or ineffective data transmission caused by inconsistent time in synthesizing a new IPSec key by the devices, in this embodiment of this application, the method may further include: The device stores an IPSec key used before, and when synthesizing the new IPSec key, performs security protection on to-be-transmitted data by using an IPSec key synthesized in a previous IPSec aging period. In this way, it can be ensured that communication peers use a same IPSec key to perform security protection on data in a same time period, thereby improving effectiveness of security protection performed on the to-be-transmitted data by using the IPSec key, and improving a probability of secure and effective data transmission.

Generally, durations of all IPSec aging periods defined on a same device may be the same, and durations of IPSec aging periods of different devices may be the same or different. The device <NUM> or the device <NUM> generates the IPSec key according to a negotiation rule based on the key negotiation template. The negotiation rule includes: (<NUM>) status information corresponding to a latest private key generated by a local device and status information corresponding to a latest public key of a peer device meet a matching condition of the key negotiation template; (<NUM>) an IPSec key is generated by using the latest private key of the local device and the latest public key of the peer device; and (<NUM>) the public key and the private key that participate in generating the IPSec key cannot participate in generating a next IPSec key. Optionally, the rule may further include: an IPSec key synthesized in a current IPSec aging period of the device is used to protect data transmitted in a next IPSec aging period adjacent to the current IPSec aging period.

In some possible implementations, assuming that each IPSec aging period of the device <NUM> has a duration <NUM>, each IPSec aging period of the device has a duration <NUM>, and the duration <NUM> and the duration <NUM> are equal, an IPSec key corresponding to each IPSec aging period may be obtained based on the pre-established key negotiation template and a public key exchanged in each IPSec aging period.

In an example, an embodiment of this application provides a method <NUM> for secure communication. Referring to <FIG>, the method <NUM> includes the following steps.

The device <NUM> sends a packet <NUM> to the device <NUM> in an IPSec aging period <NUM> of the device <NUM>. The packet <NUM> carries indication information <NUM> and a public key <NUM>, and the indication information <NUM> is used to indicate status information of a public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> receives, in an IPSec aging period <NUM> of the device <NUM>, the packet <NUM> sent by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> generates an IPSec key <NUM> based on the key negotiation template, the indication information <NUM>, the public key <NUM>, and a private key <NUM> and indication information <NUM> that are generated by the device <NUM> in the IPSec aging period <NUM>. The indication information <NUM> is used to indicate status information of a public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>.

It should be noted that, the method <NUM> may further include:.

In the method <NUM>, the public key <NUM> and the private key <NUM> are the public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>, and the public key <NUM> and the private key <NUM> are the public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>.

In a specific implementation, both the packet <NUM> and the packet <NUM> may be BGP messages or UDP packets. For details, refer to related descriptions about the public key and the indication information that are carried in the BGP message or the UDP packet in S106 in the embodiment shown in the method <NUM>.

S201 and S202 may be performed at any moment after S101, and S204 and S205 may be performed at any moment after S104. S203 is a specific implementation of S106. S206 is a specific implementation of S110.

In another example, in an IPSec aging period <NUM> of the device <NUM> and an IPSec aging period <NUM> of the device <NUM>, where the IPSec aging period <NUM> and the IPSec aging period <NUM> are separated by an odd quantity of IPSec aging periods, and the IPSec aging period <NUM> and the IPSec aging period <NUM> are also separated by an odd quantity of IPSec aging periods, an embodiment of this application further provides a method <NUM> for secure communication. Referring to <FIG>, for example, the method <NUM> may include the following steps.

The device <NUM> sends a packet <NUM> to the device <NUM> in the IPSec aging period <NUM> of the device <NUM>. The packet <NUM> carries indication information <NUM> and a public key <NUM>, and the indication information <NUM> is used to indicate status information of a public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> receives, in the IPSec aging period <NUM> of the device <NUM>, the packet <NUM> sent by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> generates an IPSec key <NUM> based on the key negotiation template, the indication information <NUM>, the public key <NUM>, and a private key <NUM> and indication information <NUM> that are generated by the device <NUM> in the IPSec aging period <NUM>.

Because IPSec updates are indicated by using alternate occurrences of indication information, the device generates a same piece of indication information after an odd quantity of IPSec aging periods. Because the IPSec aging period <NUM> and the IPSec aging period <NUM> are separated by an odd quantity of IPSec aging periods, and the IPSec aging period <NUM> and the IPSec aging period <NUM> are separated by an odd quantity of IPSec aging periods, the indication information <NUM> and the indication information <NUM> are the same, and the indication information <NUM> and the indication information <NUM> are the same. Moreover, because the duration <NUM> and the duration <NUM> are equal, the quantities of IPSec aging periods of the separation are the same.

In a specific implementation, S303 may include: The device <NUM> determines whether the indication information <NUM> and the indication information <NUM> meet the matching condition of the key negotiation template. If the matching condition is met, the device <NUM> synthesizes the IPSec key <NUM> based on the public key <NUM> and the private key <NUM>. Otherwise, the device <NUM> does not synthesize the IPSec key <NUM>. S306 may include: The device <NUM> determines whether the indication information <NUM> and the indication information <NUM> meet the matching condition of the key negotiation template. If the matching condition is met, the device <NUM> synthesizes the IPSec key <NUM> based on the public key <NUM> and the private key <NUM>. Otherwise, the device <NUM> does not synthesize the IPSec key <NUM>. In a scenario in which IPSec aging periods of devices are consistent, after a key negotiation template is established for the first time, the foregoing determining operations are not mandatory because subsequent IPSec aging periods are consistent.

S301 to S303 may be performed at any moment after the device <NUM> enters the IPSec aging period <NUM>. Similarly, S304 to S306 may be performed at any moment after the device <NUM> enters the IPSec aging period <NUM>. S301 to S303 and S304 to S306 are not necessarily performed in a specific order. S303 is a specific implementation of S106. S306 is a specific implementation of S110.

In still another example, in an IPSec aging period <NUM> of the device <NUM> and an IPSec aging period <NUM> of the device <NUM>, where the IPSec aging period <NUM> and the IPSec aging period <NUM> are separated by an even quantity of IPSec aging periods, and the IPSec aging period <NUM> and the IPSec aging period <NUM> are also separated by an even quantity of IPSec aging periods, an embodiment of this application further provides a method <NUM> for secure communication. Referring to <FIG>, for example, the method <NUM> may include the following steps.

The device <NUM> sends a packet <NUM> to the device <NUM> in the IPSec aging period <NUM> of the device <NUM>. The packet <NUM> carries indication information <NUM> and a public key <NUM>, and the indication information <NUM> is used to indicate status information of a public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> receives, in the IPSec aging period <NUM> of the device <NUM>, the packet <NUM> sent by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> generates an IPSec key <NUM> based on the key negotiation template, the indication information <NUM>, the public key <NUM>, and a private key <NUM> and indication information <NUM> that are generated by the device <NUM> in the IPSec aging period <NUM>.

Because IPSec updates are indicated by using alternate occurrences of indication information, the device generates a different piece of indication information after an even quantity of IPSec aging periods. Because the IPSec aging period <NUM> and the IPSec aging period <NUM> are separated by an even quantity of IPSec aging periods, and the IPSec aging period <NUM> and the IPSec aging period <NUM> are separated by an even quantity of IPSec aging periods, the indication information <NUM> and the indication information <NUM> are different, and the indication information <NUM> and the indication information <NUM> are different. Moreover, because the duration <NUM> and the duration <NUM> are equal, the quantities of IPSec aging periods of the separation are the same.

S403 may specifically include: The device <NUM> determines whether the indication information <NUM> and the indication information <NUM> meet the matching condition of the key negotiation template. If the matching condition is met, the device <NUM> synthesizes the IPSec key <NUM> based on the public key <NUM> and the private key <NUM>. Otherwise, the device <NUM> does not synthesize the IPSec key <NUM>. S306 may specifically include: The device <NUM> determines whether the indication information <NUM> and the indication information <NUM> meet the matching condition of the key negotiation template. If the matching condition is met, the device <NUM> synthesizes the IPSec key <NUM> based on the public key <NUM> and the private key <NUM>. Otherwise, the device <NUM> does not synthesize the IPSec key <NUM>. In a scenario in which IPSec aging periods of devices are consistent, after a key negotiation template is established for the first time, the foregoing determining operations are not mandatory because subsequent IPSec aging periods are consistent.

In a specific implementation, the packet <NUM> and the packet <NUM> may be BGP messages or UDP packets. For details, refer to related descriptions about the public key and the indication information that are carried in the BGP message or the UDP packet in S106 in the embodiment shown in the method <NUM>.

S401 to S403 may be performed at any moment after the device <NUM> enters the IPSec aging period <NUM>. Similarly, S404 to S406 may be performed at any moment after the device <NUM> enters the IPSec aging period <NUM>. S401 to S403 and S404 to S406 are not necessarily performed in a specific order. S403 is a specific implementation of S106. S406 is a specific implementation of S110.

In a specific implementation, in an IPSec aging period (which may also be denoted as the first IPSec aging period) in which a key negotiation template is established, the method <NUM> may be performed; when the second IPSec aging period starts, the method <NUM> may be performed; when the third IPSec aging period starts, the method <NUM> may be performed; when the fourth IPSec aging period starts, the method <NUM> may be performed; when the fifth IPSec aging period starts, the method <NUM> may be performed; and so on. The method <NUM> and the method <NUM> are repeatedly performed, to obtain an IPSec key in each IPSec aging period.

For two devices whose IPSec aging periods have a same duration, an IPSec key corresponding to each IPSec aging period can be quickly and effectively generated by performing the method <NUM>, the method <NUM>, and the method <NUM>, to provide a data basis for secure communication between the devices.

In the following embodiment shown in <FIG>, how to implement the method <NUM>, the method <NUM>, and the method <NUM> in embodiments of this application is specifically described by using an example in which indication information is alternate tick values <NUM> and <NUM>.

In some other possible implementations, each IPSec aging period of the device <NUM> has a duration <NUM>, and each IPSec aging period of the device has a duration <NUM>, but the duration <NUM> and the duration <NUM> are not equal.

In an example, in an IPSec aging period <NUM> of the device <NUM> and an IPSec aging period <NUM> of the device <NUM>, where the IPSec aging period <NUM> and the IPSec aging period <NUM> are separated by an odd quantity of IPSec aging periods, indication information <NUM> corresponding to the IPSec aging period <NUM> is the same as the indication information <NUM>, the IPSec aging period <NUM> and the IPSec aging period <NUM> are also separated by an odd quantity of IPSec aging periods, and indication information <NUM> corresponding to the IPSec aging period <NUM> is the same as the indication information <NUM>, an embodiment of this application further provides a method <NUM> for secure communication. Referring to <FIG> and <FIG>, for example, the method <NUM> may include the following steps.

The device <NUM> sends a packet <NUM> to the device <NUM> in the IPSec aging period <NUM> of the device <NUM>. The packet <NUM> carries the indication information <NUM> and a public key <NUM>, and the indication information <NUM> is used to indicate status information of a public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> receives the packet <NUM> sent by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> determines whether a condition (which may also be referred to as a predetermined negotiation rule) is met. If the condition is met, S504 is performed.

The condition includes: neither of the public key <NUM> and a private key <NUM> generated by the device <NUM> in the IPSec aging period <NUM> participates in IPSec key synthesis.

The device <NUM> determines whether the indication information <NUM> and the indication information <NUM> generated by the device <NUM> in the IPSec aging period <NUM> meet the matching condition of the key negotiation template. If the matching condition is met, S505 is performed.

The device <NUM> generates an IPSec key <NUM> based on the public key <NUM> and the private key <NUM> generated by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> determines whether the indication information <NUM> and the indication information <NUM> generated by the device <NUM> in the IPSec aging period <NUM> meet the matching condition of the key negotiation template. If the matching condition is met, S510 is performed.

The device <NUM> generates an IPSec key <NUM> based on the public key <NUM> and the private key <NUM> generated by the device <NUM> in the IPSec aging period <NUM>. The IPSec key <NUM> generated in S510 is the same as the IPSec key <NUM> generated in S505.

In another example, in an IPSec aging period <NUM> of the device <NUM> and an IPSec aging period <NUM> of the device <NUM>, where the IPSec aging period <NUM> and the IPSec aging period <NUM> are separated by an even quantity of IPSec aging periods, indication information <NUM> corresponding to the IPSec aging period <NUM> is different from the indication information <NUM>, the IPSec aging period <NUM> and the IPSec aging period <NUM> are also separated by an even quantity of IPSec aging periods, and indication information <NUM> corresponding to the IPSec aging period <NUM> is different from the indication information <NUM>, an embodiment of this application further provides a method <NUM> for secure communication. Refer to <FIG> and <FIG>. For example, the method <NUM> may include the following steps.

The device <NUM> sends a packet <NUM> to the device <NUM> in the IPSec aging period <NUM> of the device <NUM>. The packet <NUM> carries the indication information <NUM> and a public key <NUM>, and the indication information <NUM> is used to indicate status information of a public-private key pair generated by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> receives the packet <NUM> sent by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> determines whether a condition is met. If the condition is met, S604 is performed.

The device <NUM> determines whether the indication information <NUM> and the indication information <NUM> generated by the device <NUM> in the IPSec aging period <NUM> meet the matching condition of the key negotiation template. If the matching condition is met, S605 is performed.

The device <NUM> generates an IPSec key <NUM> based on the public key <NUM> and the private key <NUM> generated by the device <NUM> in the IPSec aging period <NUM>.

The device <NUM> determines whether the indication information <NUM> and the indication information <NUM> generated by the device <NUM> in the IPSec aging period <NUM> meet the matching condition of the key negotiation template. If the matching condition is met, S610 is performed.

The device <NUM> generates an IPSec key <NUM> based on the public key <NUM> and the private key <NUM> generated by the device <NUM> in the IPSec aging period <NUM>. The IPSec key <NUM> generated in S610 is the same as the IPSec key <NUM> generated in S605.

In a specific implementation, in an IPSec aging period (which may also be denoted as the first IPSec aging period) in which a key negotiation template is established, the method <NUM> may be performed; when a device with a longer IPSec aging period enters the second IPSec aging period, the method <NUM> may be performed; when the device with the longer IPSec aging period enters the third IPSec aging period, the method <NUM> may be performed; when the device with the longer IPSec aging period enters the fourth IPSec aging period, the method <NUM> may be performed; when the device with the longer IPSec aging period enters the fifth IPSec aging period, the method <NUM> may be performed; and so on. The method <NUM> and the method <NUM> are repeatedly performed, to obtain an IPSec key in each IPSec aging period.

For two devices whose IPSec aging periods have different durations, an IPSec key corresponding to each IPSec aging period can be quickly and effectively generated by performing the method <NUM>, the method <NUM>, and the method <NUM>, to provide a data basis for secure communication between the devices.

In the following embodiment shown in <FIG> and <FIG>, how to implement the method <NUM>, the method <NUM>, and the method <NUM> in embodiments of this application is described by using an example in which indication information is alternate tick values <NUM> and <NUM>.

To describe embodiments of this application more clearly and specifically, for example, the indication information is a tick value and the IPSec key is an encryption key, and the IPSec key negotiation process in embodiments of this application is specifically described below with reference to <FIG>, and <FIG> and <FIG> by using two examples.

In this scenario, a device <NUM> and a device <NUM> are communication peers, and the device <NUM> and a device <NUM> are also communication peers. It is assumed that IPSec aging periods of the device <NUM> and the device <NUM> has a duration of <NUM> hours, and an IPSec aging period of the device <NUM> has a duration of <NUM> hours. Starting from connection establishment, tick values <NUM> and <NUM> of the device <NUM> and <NUM> alternate, and tick values <NUM> and <NUM> of the device <NUM> alternate. The following example <NUM> describes IPSec key negotiation between the device <NUM> and the device <NUM> in the first two IPSec aging periods, and the following example <NUM> describes IPSec key negotiation between the device <NUM> and the device <NUM> in the first two IPSec aging periods.

Example <NUM>: Referring to <FIG>, an IPSec key negotiation method <NUM> may include a process of obtaining an IPSec key in the first IPSec aging period and a process of obtaining an IPSec key in the second IPSec aging period.

The process of obtaining an IPSec key in the first IPSec aging period includes the following steps.

The device <NUM> sends a KeepAlive packet <NUM> to the device <NUM>. The KeepAlive packet <NUM> carries the tick value <NUM>.

The device <NUM> sends a KeepAlive packet <NUM> to the device <NUM>. The KeepAlive packet <NUM> carries the tick value <NUM>.

The device <NUM> generates a key negotiation template based on the tick value <NUM> and the current tick value <NUM> of the device <NUM>. The device <NUM> generates a key negotiation template based on the tick value <NUM> and the current tick value <NUM> of the device <NUM>.

The device <NUM> sends a BGP message <NUM> to the device <NUM>. The BGP message <NUM> carries the tick value <NUM> and a public key H1 in the first IPSec aging period. The device <NUM> sends a BGP message <NUM>' to the device <NUM>. The BGP message <NUM>' carries the tick value <NUM> and a public key H2 in the first IPSec aging period.

The device <NUM> synthesizes an encryption key K1 based on a private key D1 generated by the device <NUM> and the received public key H2.

The device <NUM> synthesizes an encryption key K2 based on a private key D2 generated by the device <NUM> and the received public key H1.

A data packet <NUM> encrypted by using the encryption key is transmitted between the device <NUM> and the device <NUM>.

After the first IPSec aging period lasts <NUM> hours, the second IPSec aging period starts, and a new IPSec key needs to be determined through negotiation. For example, a process of negotiating an IPSec key in the second IPSec aging period may include:.

The device <NUM> sends a BGP message <NUM> to the device <NUM>. The BGP message <NUM> carries the tick value <NUM> and a public key H3. The device <NUM> sends a BGP message <NUM> to the device <NUM>. The BGP message <NUM> carries the tick value <NUM> and a public key H4.

The device <NUM> synthesizes an encryption key K3 based on a private key D3 generated by the device <NUM> and the received public key H4.

The device <NUM> synthesizes an encryption key K4 based on a private key D4 generated by the device <NUM> and the received public key H3.

A data packet <NUM> encrypted by using the encryption key is transmitted between the device <NUM> and the device <NUM>.

In a specific implementation, after S1108 and before S1109, the method may further include: The device <NUM> determines, based on the received tick value <NUM> and the current tick value <NUM> of the device <NUM>, that a matching condition of the key negotiation template is met, and then performs S1109.

In a specific implementation, in S1111, the data packet <NUM> on which security protection is performed by using K3 or K4 may also be transmitted between the device <NUM> and the device <NUM>.

In this way, when IPSec aging periods of two devices have a same duration and update periods are consistent, a key negotiation template may be established before IPSec key negotiation, and when an IPSec key needs to be negotiated, the IPSec key is quickly and efficiently negotiated based on the key negotiation template, so that secure and quick packet transmission may be performed based on IPSec in a network.

Example <NUM>: <FIG> is a diagram of a relationship between IPSec aging periods of the device <NUM> and the device <NUM>. Referring to <FIG> and <FIG>, an IPSec key negotiation method <NUM> includes a process of obtaining an IPSec key in the first IPSec aging period of the device <NUM> and a process of obtaining an IPSec key in the second IPSec aging period. The method <NUM> includes the following steps.

The device <NUM> sends a KeepAlive packet <NUM> to the device <NUM>. The KeepAlive packet <NUM> carries the tick value <NUM>.

The device <NUM> sends a KeepAlive packet <NUM> to the device <NUM>. The KeepAlive packet <NUM> carries the tick value <NUM>.

The device <NUM> generates a key negotiation template based on the tick value <NUM> and the current tick value <NUM> of the device <NUM>. The device <NUM> generates a key negotiation template based on the tick value <NUM> and the current tick value <NUM> of the device <NUM>.

The device <NUM> sends a BGP message <NUM> to the device <NUM>. The BGP message <NUM> carries the tick value <NUM> and a public key H1 in the first IPSec aging period. The device <NUM> sends a BGP message <NUM>' to the device <NUM>. The BGP message <NUM>' carries the tick value <NUM> and a public key H2 in the first IPSec aging period.

The device <NUM> synthesizes an encryption key K1 based on a private key D1 generated by the device <NUM> and the received public key H2.

The device <NUM> synthesizes an encryption key K2 based on a private key D2 generated by the device <NUM> and the received public key H1.

In a specific implementation, it should be noted that, after S1306, BGP messages and data packets exchanged between the device <NUM> and the device <NUM> may all be encrypted by using the encryption key K1 or K2 to implement security protection.

After the first IPSec aging period of the device <NUM> lasts <NUM> hours, the second IPSec aging period of the device <NUM> starts. This embodiment of this application includes:.

The device <NUM> sends a BGP message <NUM> to the device <NUM>. The BGP message <NUM> carries the tick value <NUM> and a public key H3.

Because the cross key negotiation template is not met currently, and the private key D1 of the device <NUM> has participated in IPSec key synthesis, the device <NUM> does not synthesize a new IPSec key, and still uses K1 or K2 as a shared encryption key.

After the second IPSec aging period of the device <NUM> lasts <NUM> hours, the third IPSec aging period of the device <NUM> starts. In this case, this embodiment of this application includes:
S1308. The device <NUM> sends a BGP message <NUM> to the device <NUM>. The BGP message <NUM> carries the tick value <NUM> and a public key H4.

Although the cross key negotiation template is met, because the private key D1 of the device <NUM> has participated in IPSec key synthesis, the device <NUM> still does not synthesize a new IPSec key, but still uses K1 or K2 as a shared IPSec key.

After the first IPSec aging period of the device <NUM> lasts <NUM> hours, the third IPSec aging period of the device <NUM> has lasted <NUM> hours, and the second IPSec aging period of the device <NUM> starts. For example, a process of obtaining an IPSec key may include:
S1309. The device <NUM> sends a BGP message <NUM> to the device <NUM>. The BGP message <NUM> carries the tick value <NUM> and a public key H5.

Although the private key D4 of the device <NUM> has not participated in IPSec key synthesis, because the cross key negotiation template is met, the device <NUM> does not synthesize a new IPSec key, but still uses K1 or K2 as a shared encryption key.

After the third IPSec aging period of the device <NUM> lasts <NUM> hours, the fourth IPSec aging period of the device <NUM> starts. In this case, this embodiment of this application includes:.

The key synthesis condition (that is, the "condition" in the foregoing embodiment, which may also be referred to as a predetermined negotiation rule) may specifically include: the private key D5 is a latest private key generated by the device <NUM>, the public key H6 is a latest public key received from the device <NUM>, and neither of the private key D5 and the public key H6 participates in encryption key synthesis.

After the fourth IPSec aging period of the device <NUM> lasts <NUM> hours, the fifth IPSec aging period of the device <NUM> starts. This embodiment of this application includes:
S1312. The device <NUM> sends a BGP message <NUM> to the device <NUM>. The BGP message <NUM> carries the tick value <NUM> and a public key H7.

Because the cross key negotiation template is not met, and the private key D5 of the device <NUM> has participated in IPSec key synthesis, the device <NUM> does not synthesize a new IPSec key, and still uses K1 or K2 as a shared encryption key, or still uses K3 as a shared encryption key.

After the second IPSec aging period of the device <NUM> lasts <NUM> hours, the fifth IPSec aging period of the device <NUM> has lasted <NUM> hours, and the third IPSec aging period of the device <NUM> starts. For example, a process of negotiating an IPSec key may include:.

The key synthesis condition may specifically include: the private key D7 is a latest private key generated by the device <NUM>, the public key H8 is a latest public key received from the device <NUM>, and neither of the private key D7 and the public key H8 participates in encryption key synthesis.

It may be understood that, in the remaining two hours of the fifth IPSec aging period of the device <NUM>, a data packet <NUM> on which security protection is performed by using any encryption key of K1, K2, K3, or K4 is transmitted between the device <NUM> and the device <NUM>.

In this way, when IPSec aging periods of two devices have different durations, a key negotiation template may be established before IPSec key negotiation, and when an IPSec key needs to be negotiated, the IPSec key is quickly and efficiently negotiated based on the key negotiation template, so that secure and quick data transmission may be performed based on IPSec in a network.

<FIG> is a schematic flowchart of a method <NUM> for secure communication according to an embodiment of this application. The method <NUM> is applied to a scenario including a first device and a second device, and performed by the first device. For example, the method <NUM> for secure communication may include the following steps.

Step <NUM>: Receive, in a second Internet protocol security IPSec aging period of the first device, first indication information sent by the second device, where the first indication information is used to indicate status information corresponding to a public-private key pair generated in a first IPSec aging period of the second device.

Step <NUM>: Establish a key negotiation template based on the first indication information and second indication information, where the second indication information is used to indicate status information of a public-private key pair generated by the first device in the second IPSec aging period.

Step <NUM>: Generate a first IPSec key based on the key negotiation template, where the first IPSec key is used to protect data transmitted between the first device and the second device in a first time period.

In an example, the first device may be the device <NUM> in the method <NUM>, and the second device may be the device <NUM> in the method <NUM>. In this case, the first indication information may be the indication information <NUM> in the method <NUM>, the second indication information is the indication information <NUM> in the method <NUM>, the second IPSec aging period is the IPSec aging period <NUM>, the first IPSec aging period is the IPSec aging period <NUM>, and the first IPSec key is the IPSec key <NUM>.

In another example, the first device may be the device <NUM> in the method <NUM>, and the second device may be the device <NUM> in the method <NUM>. In this case, the first indication information may be the indication information <NUM> in the method <NUM>, the second indication information is the indication information <NUM> in the method <NUM>, the second IPSec aging period is the IPSec aging period <NUM>, the first IPSec aging period is the IPSec aging period <NUM>, and the first IPSec key is the IPSec key <NUM>.

The first indication information is the same as the second indication information, and the key negotiation template is a parallel key negotiation template. Alternatively, the first indication information is different from the second indication information, and the key negotiation template is a cross key negotiation template.

In some possible implementations, S1401 of "receiving first indication information sent by the second device" in this embodiment of this application may include: receiving a keepalive (KeepAlive) packet or a bidirectional forwarding detection BFD packet sent by the second device. The first indication information is carried in the KeepAlive packet or the BFD packet.

In some other possible implementations, the method <NUM> further includes: receiving, in a fourth IPSec aging period of the first device, a first packet sent by the second device in a third IPSec aging period. The first packet 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 status information corresponding to the first public key. The third IPSec aging period is the first IPSec aging period, or the third IPSec aging period and the first IPSec aging period are separated by N aging periods, and N is a positive odd number. The third indication information is the same as the first indication information. In this case, S1403 of "generating a first IPSec key based on the key negotiation template" in the method <NUM> may include: generating the first IPSec key based on the key negotiation template, the third indication information, the first public key, and a first private key and fourth indication information that are generated by the first device in the fourth IPSec aging period. The fourth indication information is used to indicate the fourth IPSec aging period. The fourth IPSec aging period is the second IPSec aging period, or the fourth IPSec aging period and the second IPSec aging period are separated by M aging periods, and M is a positive odd number. The fourth indication information is the same as the second indication information.

It should be noted that, when the method <NUM> is used to implement the method <NUM> corresponding to <FIG>, the method <NUM> corresponding to <FIG>, or the method <NUM> corresponding to <FIG> and <FIG>, the first device may be, for example, the device <NUM> in the foregoing method embodiment, and the second device is the device <NUM> in the foregoing method embodiment. In this case, the third indication information is the indication information <NUM>, the fourth indication information is the indication information <NUM>, the third IPSec aging period is the IPSec aging period <NUM>, the fourth IPSec aging period is the IPSec aging period <NUM>, and the first packet is the packet <NUM> or the packet <NUM> in the foregoing method embodiment. Alternatively, the first device may be, for example, the device <NUM> in the method <NUM>, <NUM>, or <NUM>, and the second device is the corresponding device <NUM>. In this case, the third indication information is the indication information <NUM>, the fourth indication information is the indication information <NUM>, the third IPSec aging period is the IPSec aging period <NUM>, the fourth IPSec aging period is the IPSec aging period <NUM>, and the first packet is the packet <NUM> or the packet <NUM> in the foregoing method embodiment.

It may be understood that, for related descriptions and achieved effects of the implementation, refer to related descriptions in the method <NUM>, the method <NUM>, or the method <NUM>. Specifically, when each IPSec aging period of the first device has a first duration, each IPSec aging period of the second device has a second duration, and the first duration and the second duration are equal, refer to the method <NUM> or the method <NUM> for the implementation. When the first duration and the second duration are not equal, refer to the method <NUM>. The generating a first IPSec key in S1403 is specifically: generating the first IPSec key when the following condition is met. The condition includes: neither of the first public key and the first private key that participate in generating the first IPSec key participates in generating another IPSec key other than the first IPSec key.

In still some other possible implementations, the method <NUM> may further include: receiving, in a sixth IPSec aging period of the first device, a second packet sent by the second device, where the second packet carries a second public key and fifth indication information that are generated by the second device in a fifth IPSec aging period, the fifth indication information indicates status information corresponding to the second public key, and the fifth IPSec aging period and the first IPSec aging period are separated by an even quantity of IPSec aging periods; and generating a second IPSec key based on the key negotiation template, the second public key, the fifth indication information, and a second private key and sixth indication information that are generated by the first device in the sixth IPSec aging period, where the sixth indication information is used to indicate status information corresponding to the second private key, the second IPSec key is used to protect data transmitted between the first device and the second device in a second time period, and the sixth IPSec aging period and the second IPSec aging period are separated by an even quantity of IPSec aging periods.

It should be noted that, when the method <NUM> is used to implement the method <NUM> corresponding to <FIG> or the method <NUM> corresponding to <FIG> and <FIG>, the first device may be, for example, the device <NUM> in the foregoing method embodiment, and the second device is the device <NUM> in the foregoing method embodiment. In this case, the fifth indication information is the indication information <NUM>, the sixth indication information is the indication information <NUM>, the fifth IPSec aging period is the IPSec aging period <NUM>, the sixth IPSec aging period is the IPSec aging period <NUM>, and the second packet is the packet <NUM> in the foregoing method embodiment. Alternatively, the first device may be, for example, the device <NUM> in the foregoing method embodiment, and the second device is the device <NUM> in the foregoing method embodiment. In this case, the fifth indication information is the indication information <NUM>, the sixth indication information is the indication information <NUM>, the fifth IPSec aging period is the IPSec aging period <NUM>, the sixth IPSec aging period is the IPSec aging period <NUM>, and the second packet is the packet <NUM> in the foregoing method embodiment.

It may be understood that, for related descriptions and achieved effects of the implementation, refer to related descriptions in the method <NUM> or the method <NUM>. Specifically, when each IPSec aging period of the first device has a first duration, each IPSec aging period of the second device has a second duration, and the first duration and the second duration are equal, refer to the method <NUM> for the implementation. When the first duration and the second duration are not equal, refer to the method <NUM>. The "generating a second IPSec key" is specifically: generating the second IPSec key when the following condition is met. The condition includes: neither of the second public key and the second private key that participate in generating the second IPSec key participates in generating another IPSec key other than the second IPSec key.

It may be understood that the first packet and the second packet may further include at least one of the following security parameters: a DH group, an encapsulation mode, an encryption algorithm, and an authentication algorithm.

It may be understood that both the first packet and the second packet may be border gateway protocol BGP messages or user datagram protocol UDP packets.

The first IPSec key in the method <NUM> may be an encryption key or an authentication key, and the second IPSec key may also be an encryption key or an authentication key.

It should be noted that, for a specific implementation and an achieved effect of the method <NUM> in this embodiment of this application, refer to related descriptions in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG>.

<FIG> is a schematic flowchart of another method <NUM> for secure communication according to an embodiment of this application. The method <NUM> is applied to a scenario including a first device and a second device, and performed by the second device. For example, the method <NUM> for secure communication may include the following steps.

Generate first indication information in a first Internet protocol security IPSec aging period of the second device, where the first indication information is used to indicate status information corresponding to a public-private key pair generated by the second device in the first IPSec aging period.

Send the first indication information to the first device.

It may be understood that, the first device may be the device <NUM> in the method <NUM>, and the second device may be the device <NUM> in the method <NUM>. In this case, the first indication information may be the indication information <NUM> in the method <NUM>, and the first IPSec aging period is the IPSec aging period <NUM>. Alternatively, the first device may be the device <NUM> in the method <NUM>, and the second device is the device <NUM> in the method <NUM>. In this case, the first indication information may be the indication information <NUM> in the method <NUM>, and the first IPSec aging period is the IPSec aging period <NUM>.

In some possible implementations, S1501 of "sending the first indication information to the first device" in this embodiment of this application may include: sending a keepalive (KeepAlive) packet or a bidirectional forwarding detection BFD packet to the first device. The first indication information is carried in the KeepAlive packet or the BFD packet.

In some other possible implementations, the method <NUM> further includes: receiving, in the first IPSec aging period, second indication information sent by the first device, where the second indication information is used to indicate status information corresponding to a public-private key pair generated by the first device in a second IPSec aging period; establishing a key negotiation template based on the second indication information and the first indication information; and generating a first IPSec key based on the key negotiation template, where the first IPSec key is used to protect data transmitted between the first device and the second device in a 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. Alternatively, the first indication information is different from the second indication information, and the key negotiation template is a cross key negotiation template.

It may be understood that, when the method <NUM> is used to implement the method <NUM> corresponding to <FIG>, the first device may be, for example, the device <NUM> in the method <NUM>, and the second device may be the device <NUM> in the method <NUM>. In this case, the first indication information may be the indication information <NUM> in the method <NUM>, the second indication information is the indication information <NUM> in the method <NUM>, the second IPSec aging period is the IPSec aging period <NUM>, the first IPSec aging period is the IPSec aging period <NUM>, and the first IPSec key is the IPSec key <NUM>. When the first device may be the device <NUM> in the method <NUM>, the second device may be the device <NUM> in the method <NUM>. In this case, the first indication information may be the indication information <NUM> in the method <NUM>, the second indication information is the indication information <NUM> in the method <NUM>, the second IPSec aging period is the IPSec aging period <NUM>, the first IPSec aging period is the IPSec aging period <NUM>, and the first IPSec key is the IPSec key <NUM>.

In still some other possible implementations, the method <NUM> further includes: sending a first packet to the first device in a third IPSec aging period of the second device. The first packet 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 status information corresponding to the first public key. The third IPSec aging period is the first IPSec aging period, or the third IPSec aging period and the first IPSec aging period are separated by N aging periods, and N is a positive odd number. The third indication information is the same as the first indication information.

In this implementation, the "generating a first IPSec key based on the key negotiation template" may include: receiving, in the third IPSec aging period of the second device, a second packet sent by the first device, where the second packet carries a second public key and fourth indication information that are generated by the first device in a fourth IPSec aging period, the fourth indication information indicates status information corresponding to the second public key, the fourth IPSec aging period is the second IPSec aging period, or the fourth IPSec aging period and the second IPSec aging period are separated by M aging periods and M is a positive odd number, and the fourth indication information is the same as the second indication information; and generating the first IPSec key based on the key negotiation template, the fourth indication information, the second public key, and the third indication information and a first private key that are generated by the second device in the third IPSec aging period.

When the method <NUM> is used to implement the method <NUM> corresponding to <FIG>, the method <NUM> corresponding to <FIG>, or the method <NUM> corresponding to <FIG> and <FIG>, the first device may be, for example, the device <NUM> in the foregoing method embodiment, and the second device is the device <NUM> in the foregoing method embodiment. In this case, the third indication information is the indication information <NUM>, the fourth indication information is the indication information <NUM>, the third IPSec aging period is the IPSec aging period <NUM>, the fourth IPSec aging period is the IPSec aging period <NUM>, the first packet is the packet <NUM> or the packet <NUM> in the foregoing method embodiment, and the second packet is the packet <NUM> or the packet <NUM> in the foregoing method embodiment. Alternatively, the first device may be, for example, the device <NUM> in the foregoing method embodiment, and the second device is the device <NUM> in the foregoing method embodiment. In this case, the third indication information is the indication information <NUM>, the fourth indication information is the indication information <NUM>, the third IPSec aging period is the IPSec aging period <NUM>, the fourth IPSec aging period is the IPSec aging period <NUM>, the first packet is the packet <NUM> or the packet <NUM> in the foregoing method embodiment, and the second packet is the packet <NUM> or the packet <NUM> in the foregoing method embodiment.

It may be understood that, for related descriptions and achieved effects of the implementation, refer to related descriptions in the method <NUM>, the method <NUM>, or the method <NUM>. Specifically, when each IPSec aging period of the first device has a first duration, each IPSec aging period of the second device has a second duration, and the first duration and the second duration are equal, refer to the method <NUM> or the method <NUM> for the implementation. When the first duration and the second duration are not equal, refer to the method <NUM>. The "generating a first IPSec key" is specifically: generating the first IPSec key when the following condition is met. The condition includes: neither of the second public key and the first private key that participate in generating the first IPSec key participates in generating another IPSec key other than the first IPSec key.

In yet some other possible implementations, the method <NUM> further includes: sending a third packet to the first device in a fifth IPSec aging period of the second device. The third packet carries a third public key and fifth indication information that are 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 the fifth IPSec aging period and the first IPSec aging period are separated by an even quantity of IPSec aging periods. Moreover, the method <NUM> further includes: receiving, in the fifth IPSec aging period of the second device, a fourth packet sent by the first device, where the fourth packet carries a fourth public key and sixth indication information that are generated by the first device in a sixth IPSec aging period, the sixth indication information indicates status information corresponding to the fourth public key, the sixth IPSec aging period and the second IPSec aging period are separated by an even quantity of IPSec aging periods, and the fifth IPSec aging period and the first IPSec aging period are separated by an even quantity of IPSec aging periods; and generating a second IPSec key based on the key negotiation template, the fourth public key, the sixth indication information, and a second private key and the fifth indication information that are generated by the second device in the fifth IPSec aging period, where the third indication information indicates fifth IPSec aging period.

It should be noted that, when the method <NUM> is used to implement the method <NUM> corresponding to <FIG> or the method <NUM> corresponding to <FIG> and <FIG>, the first device may be, for example, the device <NUM> in the foregoing method embodiment, and the second device is the device <NUM> in the foregoing method embodiment. In this case, the fifth indication information is the indication information <NUM>, the sixth indication information is the indication information <NUM>, the fifth IPSec aging period is the IPSec aging period <NUM>, the sixth IPSec aging period is the IPSec aging period <NUM>, the third packet is the packet <NUM> in the foregoing method embodiment, and the fourth packet is the packet <NUM> in the foregoing method embodiment. Alternatively, the first device may be, for example, the device <NUM> in the foregoing method embodiment, and the second device is the device <NUM> in the foregoing method embodiment. In this case, the fifth indication information is the indication information <NUM>, the sixth indication information is the indication information <NUM>, the fifth IPSec aging period is the IPSec aging period <NUM>, the sixth IPSec aging period is the IPSec aging period <NUM>, the third packet is the packet <NUM> in the foregoing method embodiment, and the fourth packet is the packet <NUM> in the foregoing method embodiment.

It may be understood that, for related descriptions and achieved effects of the implementation, refer to related descriptions in the method <NUM> or the method <NUM>. Specifically, when each IPSec aging period of the first device has a first duration, each IPSec aging period of the second device has a second duration, and the first duration and the second duration are equal, refer to the method <NUM> for the implementation. When the first duration and the second duration are not equal, refer to the method <NUM>. The "generating a second IPSec key" is specifically: generating the second IPSec key when the following condition is met. The condition includes: neither of the fourth public key and the second private key that participate in generating the second IPSec key participates in generating another IPSec key other than the second IPSec key.

It may be understood that the first packet and the third packet may further include at least one of the following security parameters of the second device: a DH group, an encapsulation mode, an encryption algorithm, and an authentication algorithm. The second packet and the fourth packet may further include at least one of the following security parameters of the first device: a DH group, an encapsulation mode, an encryption algorithm, and an authentication algorithm.

It may be understood that the first packet to the fourth packet may all be border gateway protocol BGP messages or user datagram protocol UDP packets.

In addition, an embodiment of this application further provides a first device <NUM>, as shown in <FIG>. The first device <NUM> includes a receiving unit <NUM>, a processing unit <NUM>, and a sending unit <NUM>. The receiving unit <NUM> is configured to perform receiving operations performed by the device <NUM> in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG>, and receiving operations in the embodiment shown in <FIG>. The sending unit <NUM> is configured to perform sending operations performed by the device <NUM> in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG>, and sending operations in the embodiment shown in <FIG>. The processing unit <NUM> is configured to perform other operations other than the receiving operations and the sending operations performed by the device <NUM> in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG>, and other operations other than the receiving operations and the sending operations in the embodiment shown in <FIG>. For example, the processing unit <NUM> may perform the operation in the embodiment in <FIG>: the device <NUM> establishes a key negotiation template based on the indication information <NUM> and the indication information <NUM>.

In addition, an embodiment of this application further provides a second device <NUM>, as shown in <FIG>. The second device <NUM> includes a receiving unit <NUM>, a processing unit <NUM>, and a sending unit <NUM>. The receiving unit <NUM> is configured to perform receiving operations performed by the device <NUM> in embodiments shown in <FIG> and <FIG> to <FIG>, receiving operations performed by the device <NUM> in the embodiment shown in <FIG> and <FIG>, and receiving operations in the embodiment shown in <FIG>. The sending unit <NUM> is configured to perform sending operations performed by the device <NUM> in embodiments shown in <FIG> and <FIG> to <FIG>, sending operations performed by the device <NUM> in the embodiment shown in <FIG> and <FIG>, and sending operations in the embodiment shown in <FIG>. The processing unit <NUM> is configured to perform other operations other than the receiving operations and the sending operations performed by the device <NUM> in embodiments shown in <FIG> and <FIG> to <FIG>, and other operations other than the receiving operations and the sending operations performed by the device <NUM> in the embodiment shown in <FIG> and <FIG>, and other operations other than the receiving operations and the sending operations in the embodiment shown in <FIG>. For example, the processing unit <NUM> may perform the operation in the embodiment in <FIG>: the device <NUM> generates indication information <NUM> in an IPSec aging period <NUM> of the device <NUM>, where the indication information <NUM> is used to indicate the IPSec aging period <NUM>.

In addition, an embodiment of this application further provides a first device <NUM>, as shown in <FIG>. The first device <NUM> includes a communications interface <NUM> and a processor <NUM> connected to the communications interface <NUM>. The communications interface <NUM> is configured to perform receiving operations and sending operations performed by the device <NUM> in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG>, and receiving operations and sending operations in the embodiment shown in <FIG>. The processor <NUM> is configured to perform other operations other than the receiving operations and the sending operations performed by the device <NUM> in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG>, and other operations other than the receiving operations and the sending operations in the embodiment shown in <FIG>. For example, the processor <NUM> may perform the operation in the embodiment in <FIG>: the device <NUM> establishes a key negotiation template based on the indication information <NUM> and the indication information <NUM>.

In addition, an embodiment of this application further provides a second device <NUM>, as shown in <FIG>. The second device <NUM> includes a communications interface <NUM> and a processor <NUM> connected to the communications interface <NUM>. The communications interface <NUM> is configured to perform receiving operations and sending operations performed by the device <NUM> in embodiments shown in <FIG> and <FIG> to <FIG>, and receiving operations and sending operations performed by the device <NUM> in the embodiment shown in <FIG> and <FIG>, and receiving operations and sending operations in the embodiment shown in <FIG>. The processor <NUM> is configured to perform other operations other than the receiving operations and the sending operations performed by the device <NUM> in embodiments shown in <FIG> and <FIG> to <FIG>, and other operations other than the receiving operations and the sending operations performed by the device <NUM> in the embodiment shown in <FIG> and <FIG>, and other operations other than the receiving operations and the sending operations in the embodiment shown in <FIG>. For example, the processor <NUM> may perform the operation in the embodiment in <FIG>: the device <NUM> generates indication information <NUM> in an IPSec aging period <NUM> of the device <NUM>, where the indication information <NUM> is used to indicate the IPSec aging period <NUM>.

In addition, an embodiment of this application further provides a first device <NUM>, as shown in <FIG>. The first device <NUM> includes a memory <NUM> and a processor <NUM>. The memory <NUM> is configured to store program code. The processor <NUM> is configured to run instructions in the program code, to enable the first device <NUM> to perform the method performed on the device <NUM> side in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG>, and the method provided in the embodiment shown in <FIG>.

In addition, an embodiment of this application further provides a second device <NUM>, as shown in <FIG>. The first device <NUM> includes a memory <NUM> and a processor <NUM>. The memory <NUM> is configured to store program code. The processor <NUM> is configured to run instructions in the program code, to enable the second device <NUM> to perform the method performed on the device <NUM> side in embodiments shown in <FIG> and <FIG> to <FIG>, the method performed on the device <NUM> side in the embodiment shown in <FIG> and <FIG>, and the method provided in the embodiment shown in <FIG>.

It may be understood that, in the foregoing embodiment, the processor may be a central processing unit (English: central processing unit, CPU for short), a network processor (English: network processor, NP for short), or a combination of the CPU and the NP. Alternatively, the processor may be an application-specific integrated circuit (English: application-specific integrated circuit, ASIC for short), a programmable logic device (English: programmable logic device, PLD for short), or a combination thereof. The PLD may be a complex programmable logic device (English: complex programmable logic device, CPLD for short), a field programmable gate array (English: field-programmable gate array, FPGA for short), generic array logic (English: generic array logic, GAL for short), or any combination thereof. The processor may be one processor, or may include a plurality of processors. The memory may be a volatile memory (English: volatile memory) such as a random-access memory (English: random-access memory, RAM for short); a non-volatile memory (English: non-volatile memory) such as a read-only memory (English: read-only memory, ROM for short), a flash memory (English: flash memory), a hard disk drive (English: hard disk drive, HDD for short), or a solid-state drive (English: solid-state drive, SSD for short), or a combination of the foregoing types of memories. The memory may be one memory, or may include a plurality of memories. In a specific implementation, the memory stores computer-readable instructions, and the computer-readable instructions include a plurality of software modules, for example, a sending module, a processing module, and a receiving module. After executing each software module, the processor may perform a corresponding operation based on an indication of each software module. In this embodiment, an operation performed by a software module is actually an operation performed by the processor based on an indication of the software module. After executing the computer-readable instructions in the memory, the processor may perform, as instructed by the computer-readable instruction, all operations that can be performed by the combined device or the remote attestation device.

It may be understood that, in the foregoing embodiment, the communications interface <NUM> of the first device <NUM> may be specifically used as the receiving unit <NUM> and the sending unit <NUM> in the first device <NUM>, to implement data communication between the first device and the second device. Similarly, the communications interface <NUM> of the second device <NUM> may be specifically used as the receiving unit <NUM> and the sending unit <NUM> in the second device <NUM>, to implement data communication between the first device and the second device.

In addition, an embodiment of this application further provides a communications system <NUM>, as shown in <FIG>. The communications system <NUM> includes a first device <NUM> and a second device <NUM>. The first device <NUM> may be specifically the first device <NUM>, the first device <NUM>, or the first device <NUM>, and the second device <NUM> may be specifically the second device <NUM>, the second device <NUM>, or the second device <NUM>.

In addition, an embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium stores instructions, and when the instructions are run on a computer, the computer is enabled to perform the method for secure communication in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG> to <FIG>.

In addition, this embodiment of this application further provides a computer program product. When the computer program product runs on a computer, the computer is enabled to perform the method for secure communication in embodiments shown in <FIG>, <FIG>, and <FIG> and <FIG> to <FIG>.

It should be noted that, in embodiments of this application, the "device" may be a network device, or may be another device such as a base station or a terminal. The "device" may alternatively be a chip, and may specifically include one or more chips. The network device may be, for example, a router, a switch, or a packet transport network (English: Packet Transport Network, PTN for short) device.

The "first" in names such as "first IPSec aging period" and "first IPSec key" mentioned in embodiments of this application is merely used for name identification, and does not indicate the first in order. This rule is also applicable to "second" and the like.

Claim 1:
A method (<NUM>) for secure communication, applied to a first device, wherein the method comprises:
receiving (<NUM>), in a second Internet protocol security, IPSec, aging period of the first device, first indication information sent by a second device, wherein the first indication information is used to indicate status information corresponding to a public-private key pair generated in a first IPSec aging period of the second device, wherein the status information comprises tick values or character strings, and wherein IPSec aging period changes on the device are indicated by using alternate occurrences of the status information;
establishing (<NUM>) a key negotiation template from a set of key negotiation templates, which are pre-established on the first and the second device,
wherein the key negotiation template is chosen based on whether the first indication information and second indication information are the same or not,
wherein the second indication information is used to indicate status information of a public-private key pair generated by the first device in the second IPSec aging period, and
wherein the key negotiation template is used to initiate the first device to generate a corresponding IPSec key in each IPSec aging period, when a matching condition defined in the chosen key negotiation template is met; and
generating (<NUM>) a first IPSec key based on the key negotiation template, wherein the first IPSec key is used to protect data transmitted between the first device and the second device in a first time period.