Encryption communication method and device based on IPSec VPN and medium

Abstract

The embodiment of the invention relates to the technical field of communication, and discloses an IPSec VPN (Internet Protocol Security Virtual Private Network)-based encryption communication method, equipment and a medium. The encryption communication method based on the IPSec VPN comprises the following steps: performing quantum key negotiation with an opposite terminal in quantum keys pre-stored at a home terminal; exchanging data with an opposite terminal; key derivation is carried out according to the negotiated quantum key and key derivation parameters in the exchange data, a target key is obtained, and the target key is a key needed by IPSec VPN encryption communication; and carrying out negotiation verification with the opposite terminal, so as to carry out encrypted communication with the opposite terminal according to the target key after the verification is passed. The method at least facilitates more stable and effective combination of the quantum key to establish the IPSec VPN tunnel, and can realize more stable, effective and secure IPSec VPN encryption communication.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communication technology, and in particular to an encrypted communication method, device and medium based on IPSec VPN. Background Art

[0002] Internet Protocol Security Virtual Private Network (IPSec VPN) equipment is a dedicated device for Internet Protocol (IP) network layer encryption. It is used to provide tunnel transmission and encryption functions at the network layer of the Transmission Control Protocol / Internet Protocol (TCP / IP) system, and provide two-way identity authentication based on digital certificates for both communicating parties to ensure the authenticity of the identities of both communicating parties, and the integrity and confidentiality of the transmitted data; IPSec VPN equipment provides IP data transmission protection capabilities to the protected subnets of both parties through IP data links. Among them, in the original (or classic) IPSec VPN solution, IPSec VPN generates consistent data encryption keys for both communicating parties through identity authentication and key negotiation based on the SM2 algorithm.

[0003] However, as the computing power of attackers increases, the communication security of existing IPSec VPN devices will be threatened. To this end, a solution is proposed, that is, based on the existing IPSec VPN solution, combined with quantum key distribution (QKD), where QKDN is a typical application of quantum communication. It uses the basic principles of quantum mechanics to enable both parties in communication to share a random and secure key, and it has been proven to be unconditionally secure, that is, no matter how powerful the computing power (including quantum computers) used by the attacker is, it is secure. In this way, based on the existing IPSec VPN solution, combined with quantum key distribution, due to the unconditional security of quantum key distribution, when the two parties negotiate the key, they can determine the quantum key pair used when establishing the tunnel by exchanging key description information, thereby avoiding the security risks of identity authentication and key negotiation processes.

[0004] However, the current solution based on the existing IPSec VPN solution combined with quantum key distribution has the problem of unstable IPSecVPN encrypted communication, and may cause problems such as failure to establish the IPSec VPN tunnel and inability to communicate. Summary of the invention

[0005] The embodiments of the present application provide an encrypted communication method, device, and medium based on IPSec VPN, which at least facilitates more stable and effective establishment of IPSec VPN tunnels in combination with quantum keys, and can achieve more stable, effective, and secure encrypted communication of IPSec VPN.

[0006] According to some embodiments of the present application, a first aspect of the embodiments of the present application provides an encrypted communication method based on IPSec VPN, including: performing quantum key negotiation with a peer end in a quantum key pre-stored in the local end; exchanging data with the peer end; performing key derivation according to the negotiated quantum key and key derivation parameters in the exchanged data to obtain a target key, wherein the target key is the key required for IPSec VPN encrypted communication; and performing a negotiation and exchange process verification with the peer end, so as to perform encrypted communication with the peer end according to the target key after the verification is passed.

[0007] In some embodiments, the quantum key negotiation with the other end in the quantum key pre-stored on the local end includes: in the process of initiating the quantum key negotiation, sending key version information of the quantum key pre-stored on the local end to the other end; and / or, in the process of responding to the quantum key negotiation, according to the received key version information of the quantum key pre-stored on the other end, selecting a matching key version information from the key version information in the quantum key pre-stored on the local end and sending it to the other end, wherein the matching key version information is the key version information pre-stored on both the local end and the other end; wherein the key version information carries at least a key identifier of the quantum key.

[0008] In some embodiments, the key derivation is performed according to the negotiated quantum key and the key derivation parameters in the exchanged data to obtain the target key, which is implemented by the following expression: SKEYID=PRF((HASH(Ni_b|Nr_b), QKEY|CKY-I|CKY-R); SKEYID_d=PRF(SKEYID, QKEY|CKY-I|CKY-R|0); SKEYID_a=PRF(SKEYID, SKEYID_d|QKEY|CKY-I|CKY-R|1); SKEYID_e=PRF(SKEYID, SKEYID_a|QKEY|CKY-I|CKY-R|2); wherein SKEYID_d, SKEYID_a and SKEYID_e all belong to the target key, SKEYID_d is used to generate session keys, SKEYID_a is used to verify message integrity and data source identity and SKEYID_e is used to protect message confidentiality, PRF(x, y) indicates a pseudo-random function operation on data block y based on x as the key, HASH(x) indicates a hash operation on x, x1|x2|x3|…|xi indicates concatenation of data blocks x1, x2, x3…xi, i is a positive integer greater than 1, Ni_b and Nr_b are the Nonce payload bodies in the key derivation parameters exchanged with the peer end, QKEY is the quantum key, the numbers 0, 1, 2 indicate the values ​​of a single byte, CKY-I and CKY-R are the cookie information of the local end and the peer end respectively carried in the ISAKMP header of the data exchanged with the peer end.

[0009] In some embodiments, the negotiation and exchange process verification with the peer end includes: encrypting through a symmetric cryptographic algorithm, and verifying the negotiation and exchange process with the peer end, wherein the algorithm type of the symmetric cryptographic algorithm is determined according to the negotiation with the peer end, the key of the symmetric cryptographic algorithm is determined according to the target key, the symmetric cryptographic algorithm adopts a ciphertext block linking mode, and the initialization vector of the symmetric cryptographic algorithm is determined by the following expression: IV = HASH(Ski_b|Skr_b); wherein IV is the initialization vector, HASH(x) represents a hash operation on x, x1|x2|x3|…|xi represents concatenation of data blocks x1, x2, x3…xi, i is a positive integer greater than 1, Ski_b and Skr_b are respectively the temporary key SK payload bodies of the local and peer ends in the data exchanged with the peer end.

[0010] In some embodiments, the verification of the negotiation exchange process with the peer end includes: sending a first parameter to the peer end and receiving a second parameter sent by the peer end to verify the second parameter, wherein the first parameter and the second parameter are determined by the following expressions: HASHi=PRF(SKEYID, QKEY|CKY-I|CKY-R|SAi_b|IDi_b); HASHr=PRF(SKEYID, QKEY|CKY-R|CKY-I|SAr_b|IDr_b); SKEYID=PRF((HASH(Ni_b|Nr_b), QKEY|CKY-I|CKY-R); wherein HASHi is one of the first parameter and the second parameter, and HASHr is the first parameter and the second parameter. The other one of them, PRF(x, y) indicates that a pseudo-random function is used to operate the data block y based on x as the key, HASH(x) indicates that a hash operation is performed on x, x1|x2|x3|…|xi indicates that the data blocks x1, x2, x3…xi are concatenated, i is a positive integer greater than 1, Ni_b and Nr_b are the Nonce payload bodies in the key derivation parameters exchanged with the other end, QKEY is the quantum key, IDi_b and IDr_b are the identification payload bodies in the key derivation parameters exchanged with the other end, SAi_b and SAr_b are the SA payload bodies of the local end and the other end exchanged during the negotiation process, respectively, and CKY-I and CKY-R are the cookie information of the local end and the other end carried in the ISAKMP header of the exchanged data, respectively.

[0011] In some embodiments, in the locally pre-stored quantum key, before performing quantum key negotiation with the peer, the method includes: obtaining the quantum key and storing the obtained quantum key in a preset format, wherein the preset format is to encapsulate at least one of the following information together with the quantum key: the version of the quantum key, the IP address of the peer allowed to communicate, the key validity period, and the key update strategy.

[0012] In some embodiments, before performing quantum key negotiation with the other end in the quantum key pre-stored in the local end, the method further includes: determining that the working mode is quantum mode or hybrid mode; after performing quantum key negotiation with the other end in the quantum key pre-stored in the local end, the method further includes: when the quantum key negotiation fails and the working mode is the hybrid mode, establishing a classic IPSec VPN encrypted communication channel with the other end, and performing encrypted communication with the other end based on the classic IPSec VPN encrypted communication channel; and / or, when the quantum key negotiation fails and the working mode is the quantum mode, abandoning encrypted communication with the other end based on IPSec VPN.

[0013] In some embodiments, when the working mode is the hybrid mode, the method further includes: in the process of establishing the classic IPSec VPN encrypted communication channel with the other end, if the same pre-stored quantum key exists with the other end, returning to execute the step of performing quantum key negotiation with the other end in the quantum key pre-stored on the local end.

[0014] According to some embodiments of the present application, the second aspect of the embodiments of the present application also provides an IPSec VPN device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the encrypted communication method based on IPSec VPN as described in any one of the first aspects.

[0015] According to some embodiments of the present application, a third aspect of the embodiments of the present application further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the IPSec VPN-based encrypted communication method as described in any one of the first aspects.

[0016] The technical solution provided in the embodiment of the present application has at least the following advantages:

[0017] By performing quantum key negotiation with the other end using the quantum key pre-stored at this end, the success of the quantum key negotiation is related to the quantum key storage at both ends of the encrypted communication, but has nothing to do with the key generation and distribution of the quantum key distribution network. Therefore, it will not be interfered by the quantum key distribution network, and the problem of failure in IPSec VPN tunnel establishment caused by the inability to successfully obtain the quantum key from the quantum key distribution network in real time is avoided. In this way, the quantum key can be combined with the IPSec VPN tunnel establishment more stably and effectively, and more stable, effective and secure IPSec VPN encrypted communication can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0019] Figure 1 This is the process of the encrypted communication method based on IPSec VPN provided in the embodiment of the present application Figure 1 ;

[0020] Figure 2 This is the process of the encrypted communication method based on IPSec VPN provided in the embodiment of the present application Figure 2 ;

[0021] Figure 3 This is the process of the encrypted communication method based on IPSec VPN provided in the embodiment of the present application Figure 3 ;

[0022] Figure 4 It is a schematic diagram of the interaction process of the encrypted communication method based on IPSec VPN provided in the embodiment of the present application;

[0023] Figure 5 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] As can be seen from the background technology, the current solution of introducing quantum keys in the encrypted communication process based on IPSec VPN has the problem that the IPSec VPN encrypted communication is unstable, and problems such as failure to establish the IPSec VPN tunnel and inability to communicate may occur.

[0025] After analysis, it is found that the reason for the above problems is at least that: there are currently two main ideas for combining quantum key distribution on the basis of the existing IPSec VPN solution: 1. Incorporating a tunnel negotiation solution of quantum key on the basis of the conventional IPSec protocol. When IPSec VPN performs IKE key negotiation and quantum key negotiation, the session key negotiated by the IKE protocol is used as the first key factor, and the shared quantum key of the quantum key negotiation is used as the second key factor. The first key factor and the second key factor are confidentiality enhanced to obtain a third key factor, and the session key negotiated by the IKE key negotiation is replaced with the third key factor, thereby enhancing the security of IPSec VPN. Second, by processing the negotiation of quantum key and IKE negotiation key in parallel, the quantum key is used as the first session key to be used first, and the IKE negotiation key is used as the second session key for secure communication, which simplifies the process of combining quantum key and IKE negotiation key, and improves the update frequency of session key in IPSec SA. However, for the first idea, the entire quantum key negotiation process needs to interact frequently with the quantum key distribution network, which increases the connection load pressure of the quantum key distribution network. The second approach does not have key reserves. Once the key quantity of the quantum key distribution network fluctuates or there is a network problem, the IPSec VPN tunnel will not be able to negotiate smoothly due to the lack of quantum keys.

[0026] There is an urgent need to address the insecurity issues in existing technologies, such as the inability of traditional IPSec VPNs to resist the increased computing power of attackers, as well as the reliance on the real-time and stability of network communications on quantum key distribution networks after the integration of quantum keys.

[0027] Based on this, the embodiments of the present application provide an encrypted communication method, device and medium based on IPSec VPN, which no longer performs quantum key negotiation in real time, but instead performs key negotiation among locally pre-stored quantum keys, thereby overcoming the reliance on real-time key distribution of the quantum key distribution network, and avoiding the problem of failure in establishing the IPSec VPN tunnel due to the inability to successfully obtain the quantum key from the quantum key distribution network in real time, thereby more stably and effectively combining the quantum key to establish the IPSec VPN tunnel, and achieving more stable, effective and secure encrypted communication of the IPSec VPN.

[0028] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present application, many technical details are provided in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented.

[0029] The division of the following embodiments is for the convenience of description and shall not constitute any limitation on the specific implementation of the present application. The embodiments may be combined with each other and referenced to each other without contradiction.

[0030] The embodiment of the present application provides an encryption communication method based on IPSec VPN, which is applied to any IPSec VPN device. In order to facilitate those skilled in the art to better understand the encryption communication method based on IPSec VPN provided by the embodiment of the present application, the following will be combined with Figures 1 to 3 The flowchart shown is used for explanation.

[0031] In some embodiments, Figure 1 As shown, the process of the encrypted communication method based on IPSec VPN may include the following steps:

[0032] Step 101, performing quantum key negotiation with the other end using the quantum key pre-stored in the local end.

[0033] Step 102: Exchange data with the other end.

[0034] Step 103, performing key derivation according to the negotiated quantum key and the key derivation parameters in the exchanged data to obtain a target key, wherein the target key is the key required for IPSec VPN encrypted communication.

[0035] Step 104, verify the negotiation exchange process with the other end, and after the verification is passed, perform encrypted communication with the other end according to the target key.

[0036] In this way, by using the quantum key pre-stored at the local end to negotiate the quantum key with the other end, whether the quantum key negotiation is successful is related to the quantum key storage at both ends of the encrypted communication, and has nothing to do with the key generation and distribution of the quantum key distribution network. Therefore, it will not be interfered by the quantum key distribution network, and avoids the problem of failure to establish the IPSec VPN tunnel caused by the inability to successfully obtain the quantum key from the quantum key distribution network in real time, thereby more stably and effectively combining the quantum key to establish the IPSec VPN tunnel, and can achieve more stable, effective and secure IPSec VPN encrypted communication. In addition, its process division is roughly the same as that of the existing classic IPSec VPN encrypted communication scheme, and can be better compatible with the existing classic IPSec VPN encrypted communication scheme.

[0037] For ease of understanding, the following Figure 1 The steps shown are explained.

[0038] In step 101, quantum key negotiation is performed with the other end in the quantum key pre-stored at the local end. In the embodiment of the present application, it is emphasized that the negotiation scope of the quantum key is limited to the quantum key pre-stored at the local end. Since the quantum key is pre-stored, there is no need to interact with the quantum key distribution network in real time (such as no need to negotiate quantum keys with the other end in real time through the quantum key distribution network) to obtain the quantum key, and it will not be affected by the working state of the quantum key distribution network (such as the generation and distribution of quantum keys, etc.), and it is more stable and reliable.

[0039] It should be noted that the embodiments of the present application do not limit the pre-storage method of the quantum key on the IPSec VPN device. It is understandable that the quantum key needs to ensure security. Therefore, when the IPSec VPN device has a module such as a password card that can ensure the security of the key, the quantum key pre-stored on this end can be pre-stored in the IPSec VPN device, such as the password card of the IPSec VPN device. When the IPSec VPN device does not have a corresponding module, the quantum key pre-stored on this end can be pre-stored in a key library that opens a corresponding port to this end, so that the local end can store or read the corresponding quantum key by calling the corresponding interface. In this case, the quantum key can also be considered to be pre-stored on this end. That is, any quantum key storage method that can ensure the security of the quantum key and can be obtained by the IPSec VPN device on this end later after the quantum key distribution network generates and distributes the quantum key can be understood as a pre-storage method of the quantum key on this end, and will not be listed one by one here.

[0040] It is understandable that communication involves two ends: the initiator and the responder. Therefore, the negotiation of quantum keys will also involve the initiator and the responder. For an IPSec VPN device, according to different communication requirements, it acts as the initiator in some communication processes and as the responder in other communication processes. Therefore, an IPSec VPN device may involve two negotiation scenarios, namely, quantum key negotiation as the initiator and quantum key negotiation as the responder.

[0041] Based on this, when acting as an initiator, in some embodiments, quantum key negotiation with the other end in the quantum key pre-stored at the local end can be implemented in the following manner: during the initiation process of quantum key negotiation, key version information of the quantum key pre-stored at the local end is sent to the other end. The key version information carries at least a key identifier of the quantum key.

[0042] In addition, during the quantum key negotiation process, other information may also be negotiated, such as information indicating a key algorithm and information indicating a key derivation algorithm.

[0043] It should be noted that, in the above embodiments, the number of quantum keys involved in the key version information of the quantum key sent by the IPSec VPN device as the initiator is not limited. For example, the IPSec VPN device as the initiator can send the key version information corresponding to all currently available quantum keys pre-stored at the local end to the opposite end, so that the opposite end can negotiate the maximum number of quantum keys and it is easier to negotiate successfully. For another example, the IPSec VPN device as the initiator can estimate the current communication duration, select the currently available quantum keys that will not expire within the estimated communication duration from the pre-stored quantum keys, and send the corresponding key version information to the opposite end. Of course, the above is only an example description of the sending of key version information by the IPSec VPN device as the initiator. In some embodiments, other strategies can be adopted to achieve this, which will not be listed here one by one.

[0044] It should also be noted that the embodiments of the present application do not limit the information to be negotiated. It is understandable that the information to be negotiated during the quantum key negotiation process will be different according to different requirements and scenarios. For example, in some embodiments, the information to be negotiated may include the information shown in Table 1 below.

[0045] Table 1 Negotiated information

[0046]

[0047] Of course, the above Table 1 is only an example of information that needs to be negotiated. In some embodiments, the information therein may be increased or decreased, and will not be described in detail here.

[0048] When acting as a responding end, in some embodiments, quantum key negotiation with the other end in the quantum key pre-stored in the local end can be achieved in the following manner: in the response process of quantum key negotiation, according to the key version information of the quantum key pre-stored by the other end, a matching key version information is selected from the key version information in the quantum key pre-stored in the local end and sent to the other end, wherein the matching key version information is the key version information pre-stored by both the local end and the other end.

[0049] It should be noted that the explanation of the relevant features in the above embodiment is the same as that in the previous embodiment, and will not be repeated here.

[0050] It should also be noted that the above examples are given of quantum key negotiation methods with IPSec VPN devices as initiators and responders, but this does not mean that quantum key negotiation can only be performed in the manner given in the above embodiments. For example, in some embodiments, the information exchanged by the IPSec VPN device whether as an initiator or a responder may also be an identifier of a pre-stored quantum key. Other information, such as PRF, etc. may be default, negotiated offline, or the identifier of the quantum key may uniquely determine the quantum key using parameters such as the specified PRF, rather than just the quantum key itself, etc., which will not be listed one by one here.

[0051] In step 102, data is exchanged with the peer end. The embodiment of the present application does not limit the data exchanged. In this step, the data exchanged involves data required for the subsequent key derivation and verification process. Depending on the requirements, the data to be exchanged may be different. For ease of understanding, the exchanged data will be explained in the subsequent key derivation step and verification step.

[0052] Step 103, perform key derivation according to the negotiated quantum key and the key derivation parameters in the exchanged data to obtain a target key, wherein the target key is the key required for IPSec VPN encrypted communication. It should be noted that the embodiment of the present application does not limit the key derivation method, the number of derivations, etc. It can be understood that the number of keys required to be derived or the number of keys allowed to be used may be different according to different requirements, different device capabilities, different security requirements, etc. In addition, there may be multiple derivation functions that can be used for key derivation, such as PBKDF2 (CPU-Hard algorithm), key derivation function (KDF), etc.

[0053] In some embodiments, referring to the existing classical IPSec VPN implementation scheme, key derivation is performed according to the negotiated quantum key and the key derivation parameters in the exchanged data to obtain the target key, which can be implemented by the following expression:

[0054] SKEYID=PRF((HASH(Ni_b|Nr_b), QKEY|CKY-I|CKY-R);

[0055] SKEYID_d=PRF(SKEYID, QKEY|CKY-I|CKY-R|0);

[0056] SKEYID_a=PRF(SKEYID,SKEYID_d|QKEY|CKY-I|CKY-R|1);

[0057] SKEYID_e=PRF(SKEYID,SKEYID_a|QKEY|CKY-I|CKY-R|2);

[0058] Among them, SKEYID_d, SKEYID_a and SKEYID_e are all target keys, SKEYID_d is used to generate session keys, SKEYID_a is used to verify message integrity and data source identity, and SKEYID_e is used to protect its message confidentiality, PRF(x, y) means using pseudo-random function operation on data block y based on x as key, HASH(x) means hash operation on x, x1|x2|x3|…|xi means concatenating data blocks x1, x2, x3…xi, i is a positive integer greater than 1, Ni_b and Nr_b are the Nonce payload bodies in the key derivation parameters exchanged with the peer end, QKEY is the quantum key, the numbers 0, 1, 2 represent the values ​​of a single byte, CKY-I and CKY-R are the cookie information of the local end and the peer end respectively carried in the ISAKMP header of the data exchanged with the peer end. Among them, "I" and "R" in CKY-I and CKY-R correspond to the communication initiator and the communication responder, respectively. The subsequent subscripts or characters "i" and "r" used to indicate the information (or data, parameters, etc.) corresponding to the interaction between the initiator and the responder have the same meaning. For example, "i" and "r" in Ski_b and Skr_b indicate the corresponding relationship between the data and the initiator and the responder, which will not be repeated later.

[0059] In this way, the key derivation based on quantum keys basically corresponds to the key derivation process of the existing classic IPSec VPN solution, so that it can be better compatible with the existing classic IPSec VPN solution, especially it can provide different working modes so that the communicating parties can more flexibly choose the encrypted communication method according to their needs, which is conducive to better meeting user needs and improving user experience.

[0060] Of course, the above is only an example of key derivation. In some embodiments, key derivation can be further performed on the basis of the previous embodiment, and keys with a certain derivation order can be selected as target keys. Alternatively, in some embodiments, a key can be taken as a root key (or target key). In the subsequent encrypted communication process, according to different key usage requirements, derivation can be performed based on the root key, etc., which will not be described one by one here.

[0061] Step 104, the negotiation exchange process is verified with the other end, and after the verification is passed, encrypted communication is performed with the other end according to the target key. It should be noted that the embodiment of the present application does not limit the verification method. It is understandable that the verification method may be different according to different requirements, different device capabilities, different security requirements, etc.

[0062] In some embodiments, referring to the existing classic IPSec VPN implementation scheme, the negotiation exchange process verification with the peer end can be implemented in the following manner: encrypting through a symmetric encryption algorithm and negotiating and verifying with the peer end, wherein the algorithm type of the symmetric encryption algorithm is determined according to the negotiation with the peer end, the key of the symmetric encryption algorithm is determined according to the target key, the symmetric encryption algorithm adopts the ciphertext group link mode, and the initialization vector of the symmetric encryption algorithm is determined by the following expression:

[0063] IV = HASH(Ski_b|Skr_b);

[0064] Where, IV is the initialization vector, HASH(x) represents the hash operation on x, x1|x2|x3|…|xi represents the concatenation of data blocks x1, x2, x3…xi, i is a positive integer greater than 1, and Ski_b and Skr_b are the temporary key SK (Security Key) payload bodies of the local and peer ends in the data exchanged with the peer end, respectively.

[0065] In some embodiments, referring to the existing classic IPSec VPN implementation scheme, the negotiation exchange process verification with the peer end can be implemented in the following manner: sending a first parameter to the peer end and receiving a second parameter sent by the peer end to verify the second parameter, wherein the first parameter and the second parameter are determined by the following expression:

[0066] HASHi=PRF(SKEYID,QKEY|CKY-I|CKY-R|SAi_b|IDi_b);

[0067] HASHr=PRF(SKEYID,QKEY|CKY-R|CKY-I|SAr_b|IDr_b);

[0068] SKEYID=PRF((HASH(Ni_b|Nr_b), QKEY|CKY-I|CKY-R);

[0069] Among them, HASHi is one of the first parameter and the second parameter, HASHr is the other of the first parameter and the second parameter, PRF(x, y) indicates that a pseudo-random function operation is performed on data block y based on x as the key, HASH(x) indicates a hash operation on x, x1|x2|x3|…|xi indicates concatenation of data blocks x1, x2, x3…xi, i is a positive integer greater than 1, Ni_b and Nr_b are the Nonce payload bodies in the key derivation parameters exchanged with the peer end, QKEY is the quantum key, IDi_b and IDr_b are the identification payload bodies in the key derivation parameters exchanged with the peer end, SAi_b and SAr_b are the SA payload bodies of the local end and the peer end exchanged during the negotiation process, respectively, and CKY-I and CKY-R are the cookie information of the local end and the peer end carried in the ISAKMP header of the exchanged data, respectively.

[0070] Specifically, when the IPSec VPN device acts as an initiator, it sends HASHi to the opposite end and receives HASHr sent by the opposite end; when the IPSec VPN device acts as a responder, it sends HASHr to the opposite end and receives HASHi sent by the opposite end.

[0071] In this way, the verification based on quantum keys basically corresponds to the verification process of the existing classic IPSec VPN solution, so that it can be better compatible with the existing classic IPSec VPN solution and achieve greater simplicity and efficiency.

[0072] Of course, the above is only an example of verification. In some embodiments, other methods (such as combining to obtain hash values, etc.) can be used to jointly process the exchanged data and the negotiated quantum key, and then exchange the results of their respective processing for verification, etc., which will not be described in detail here.

[0073] In some embodiments, Figure 2 As shown, the process of the encrypted communication method based on IPSec VPN may also include the following steps:

[0074] Step 201, obtaining a quantum key and storing the obtained quantum key in a preset format, wherein the preset format is to encapsulate at least one of the following information together with the quantum key: the version of the quantum key, the IP address of the peer end allowed to communicate, the key validity period, and the key update strategy.

[0075] Step 202: Perform quantum key negotiation with the other end using the quantum key pre-stored in the local end.

[0076] Step 203: Exchange data with the other end.

[0077] Step 204: perform key derivation based on the negotiated quantum key and the key derivation parameters in the exchanged data to obtain a target key, wherein the target key is the key required for IPSec VPN encrypted communication.

[0078] Step 205, verify the negotiation exchange process with the other end, and after the verification is passed, perform encrypted communication with the other end according to the target key.

[0079] In this way, on the basis of the above-mentioned embodiment, a step of obtaining and storing keys by the IPSec VPN device is further introduced, so that the IPSec VPN device can be supported to better maintain the pre-stored quantum keys, so that the quantum keys can be updated through continuous acquisition, avoiding the security risks caused by the leakage of quantum keys, and further improving the security and reliability of encrypted communications.

[0080] For ease of understanding Figure 2 The steps of the embodiment shown will be explained below. Among them, step 202 to step 205 are substantially the same as step 101 to step 104 in the above embodiment, and the main difference is that step 201 is also performed before step 202, and steps 202 to step 205 will not be described one by one here.

[0081] In step 201, a quantum key is obtained and the obtained quantum key is stored in a preset format. The embodiment of the present application does not limit the method of obtaining the quantum key. For example, the quantum key can be implemented by a quantum key distribution operation performed by a quantum key distribution network. For example, the quantum key can be obtained by pulling from a key management server, etc., which will not be listed here one by one.

[0082] It should be noted that when the preset format involves a validity period, the IPSec VPN device can periodically detect the quantum keys pre-stored on this end to regularly process quantum keys that have exceeded their validity period and replenish the pre-stored quantum keys in a timely manner; when the preset format involves a key update policy, the IPSec VPN device can update the corresponding quantum key based on the policy, so that the quantum key can be better maintained and the security of the quantum key can be guaranteed, thereby further improving the security and reliability of encrypted communications.

[0083] In some embodiments, Figure 3 As shown, the process of the encrypted communication method based on IPSec VPN may also include the following steps:

[0084] Step 301, determining whether the working mode is a quantum mode or a hybrid mode.

[0085] Step 302: Perform quantum key negotiation with the other end using the quantum key pre-stored in the local end.

[0086] Step 303: When the quantum key negotiation is successful, data is exchanged with the other end.

[0087] Step 304: perform key derivation based on the negotiated quantum key and the key derivation parameters in the exchanged data to obtain a target key, wherein the target key is the key required for IPSec VPN encrypted communication.

[0088] Step 305, verify the negotiation exchange process with the other end, and after the verification is passed, perform encrypted communication with the other end according to the target key.

[0089] Step 306: When quantum key negotiation fails and the working mode is the hybrid mode, a classic IPSec VPN encrypted communication channel is established with the peer end, and encrypted communication is performed with the peer end based on the classic IPSec VPN encrypted communication channel; and / or, when quantum key negotiation fails and the working mode is the quantum mode, encrypted communication based on IPSec VPN is abandoned with the peer end.

[0090] In this way, on the basis of the above embodiments, the influence of different working modes and whether the negotiation is successful is further considered, and corresponding processing is performed when the negotiation fails, so as to better meet the user needs and improve the user experience.

[0091] For ease of understanding Figure 3The steps of the embodiment shown are explained below. Among them, step 302 to step 305 are substantially the same as step 101 to step 104 in the aforementioned embodiment, the main difference being that step 301 is also executed before step 302 and the execution of step 303 is conditional, i.e., quantum key negotiation is successful, and steps 302 to step 305 will not be described one by one here.

[0092] In step 301, it is determined that the working mode is a quantum mode or a hybrid mode. The embodiment of the present application does not limit the method for determining the working mode. For example, it can be determined by a user instruction, that is, when the user uses the IPSec VPN device for encrypted communication, the user can issue a corresponding instruction to determine the working mode of the current communication. For example, the IPSec VPN device can determine it according to the most recent encrypted communication state, such as when the quantum key negotiation of encrypted communication fails for many times recently, the IPSec VPN device determines the hybrid mode, etc., which will not be listed here one by one.

[0093] In step 306, when the quantum key negotiation fails and the working mode is the hybrid mode, a classic IPSec VPN encrypted communication channel is established with the peer, and encrypted communication is performed with the peer based on the classic IPSec VPN encrypted communication channel; and / or, when the quantum key negotiation fails and the working mode is the quantum mode, encrypted communication based on IPSecVPN with the peer is abandoned. The establishment and use of the classic IPSec VPN encrypted communication channel have been described in the relevant art, and will not be described here one by one.

[0094] It is understandable that, compared with the classic IPSec VPN encrypted communication channel, the scheme combining quantum key is obviously more secure. Therefore, in some embodiments, in order to better ensure the security of encrypted communication, when the working mode is a hybrid mode, the encrypted communication method based on IPSec VPN also includes: in the process of establishing a classic IPSec VPN encrypted communication channel with the opposite end, if there is the same pre-stored quantum key as the opposite end, return to execute the step of performing quantum key negotiation with the opposite end in the quantum key pre-stored at this end. That is to say, in the hybrid mode, if the quantum key negotiation fails, switch to the classic IPSec VPN encrypted communication, and before the encrypted transmission of communication information begins, the negotiation attempt of the quantum key can be maintained. If the negotiation is successful, switch back to the IPSec VPN encrypted communication process combined with quantum key, that is, continue the previous data exchange, key derivation, verification and other processes. In this way, IPSec VPN encrypted communication can be combined with quantum key to the greatest extent, making encrypted communication more secure and reliable.

[0095] Furthermore, in some embodiments, the working mode can also support the classic mode, that is, directly enter the execution of the classic IPSec VPN solution. At this time, the IPSec VPN device supports three modes for each tunnel: quantum, classic and hybrid. In the quantum mode, the communicating parties determine the key pair that can be used for this communication by exchanging the version number group of their own available keys. If one party does not find an available quantum key version, the tunnel cannot be established; the classic mode uses the process specified in the "GMT0022-2023 IPSec VPN Technical Specification" to establish a tunnel; in the hybrid mode, the communicating parties give priority to establishing a tunnel using quantum keys. If one party does not find an available quantum key version, the communication tunnel is converted from quantum mode to classic mode. If both parties have available quantum keys later, the communication tunnel is switched from classic mode to quantum mode.

[0096] It should be noted that Figure 3 The embodiment shown is only based on Figure 1 Based on the embodiment shown, further combining the processing strategies in different working modes as examples to provide an explanation, in some embodiments, it is also possible to Figure 2 The illustrated embodiment further provides an explanation by combining the processing strategies under different working modes as examples, that is, Figure 3 In the illustrated embodiment, step 201 is introduced, and will not be described in detail here.

[0097] In order to facilitate those skilled in the art to better understand the encryption communication method based on IPSec VPN provided in the embodiment of the present application. Figure 4 The interaction flow chart shown is explained.

[0098] In some embodiments, Figure 4 As shown, among the quantum keys pre-stored at the local end, quantum key negotiation with the other end is achieved through the interaction of message 1 and message 2.

[0099] Among them, message 1: the initiator sends the key version information of its own available quantum key in the first phase SA payload according to the IP address and key validity period of the responder. At this time, the information sent by the initiator together with the key version information can be seen in Table 1 above. Message 2: After receiving the protocol sent by the initiator, the responder queries its own quantum key library according to the available quantum key version in the protocol, and returns the consistent quantum key version and other information in the first phase SA payload.

[0100] The exchange of key derivation parameters with the other end is achieved through the interaction of message 3 and message 4. The content of the interaction involves information such as nonce and identity payload.

[0101] After the interaction of message 3 and message 4 is completed, the key will be derived according to the negotiated quantum key and the key derivation parameters in the exchanged data to obtain the target key. Specifically, the initiator and the responder call the interface respectively (in this case, the quantum key is pre-stored in the key library, and the key library develops corresponding port call permissions to the communicating parties) to obtain the quantum key QKEY. The two parties involved in the communication generate the basic key parameter SKEYID to generate the subsequent keys SKEYID_d, SKEYID_a, and SKEYID_e. The calculation methods are as follows:

[0102] SKEYID=PRF(HASH(Ni_b|Nr_b), QKEY|CKY-I|CKY-R);

[0103] SKEYID_d=PRF(SKEYID, QKEY|CKY-I|CKY-R|0);

[0104] SKEYID_a=PRF(SKEYID,SKEYID_d|QKEY|CKY-I|CKY-R|1);

[0105] SKEYID_e=PRF(SKEYID,SKEYID_a|QKEY|CKY-I|CKY-R|2);

[0106] The negotiation exchange process verification with the other end is realized through the interaction of message 5 and message 6. Specifically, the initiator and the responder authenticate the previous exchange process. The information transmitted in these two messages is encrypted using a symmetric encryption algorithm. The symmetric encryption algorithm is determined by message 1 and message 2, and the key is SKEYID_e. The symmetric encryption operation uses the CBC mode, and the initialization vector IV is obtained by concatenating the Ski in message 3 and the Skr in message 4 through a hash operation, that is:

[0107] IV = HASH(Ski_b|Skr_b);

[0108] The HASH algorithm is determined by Message 1 and Message 2. The message before encryption should be padded so that its length is equal to an integer multiple of the symmetric encryption algorithm block length. The value of all padding bytes is 0. The message length in the header should include the length of the padding bytes, because this reflects the length of the ciphertext. To authenticate the exchange, the initiator generates HASHi and the responder generates HASHr, calculated as follows:

[0109] HASHi=PRF(SKEYID,QKEY|CKY-I|CKY-R|SAi_b|IDi_b);

[0110] HASHr=PRF(SKEYID,QKEY|CKY-R|CKY-I|SAr_b|IDr_b).

[0111] It should be noted that the meaning of each parameter in the above expression has been described before and will not be repeated here.

[0112] It can be seen that obtaining quantum keys through the quantum key distribution network and integrating them into the IPSec protocol improves the security of IPSec VPN encrypted communications.

[0113] In addition, IPSecVPN devices can also store the acquired quantum key group in the key library through custom packaging, and update it regularly according to the key update strategy. IPSecVPN devices do not need to connect to the quantum key distribution network in real time, reducing the dependence of IPSecVPN encrypted communication on the real-time performance of the quantum key distribution network. The communicating parties determine the key pair that can be used for this communication by exchanging the version number group of their own available keys. Therefore, as long as there is a pair of identical keys, the communicating parties can communicate, which greatly reduces the dependence on the stability of the quantum key distribution network. The adaptive switching of the three tunnel modes of classical, quantum and hybrid makes it have good compatibility, so that it can be compatible with a variety of communication needs, which is conducive to promoting the large-scale application of quantum keys.

[0114] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0115] Another aspect of the present application embodiment further provides an electronic device, such as Figure 5 As shown, it includes: at least one processor 501; and a memory 502 that is communicatively connected to the at least one processor 501; wherein the memory 502 stores instructions that can be executed by the at least one processor 501, and the instructions are executed by the at least one processor 501 so that the at least one processor 501 can execute the IPSec VPN-based encryption communication method described in any of the above method embodiments.

[0116] The memory 502 and the processor 501 are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors 501 and the memory 502 together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor 501 is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor 501.

[0117] The processor 501 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management and other control functions. The memory 502 can be used to store data used by the processor 501 when performing operations.

[0118] Another aspect of the present application embodiment further provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the above method embodiment is implemented.

[0119] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including a number of instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0120] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present application, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present application.

Claims

1. An encrypted communication method based on IPSec VPN, characterized in that: include: Using the quantum key pre-stored on the local end, the quantum key is negotiated with the other end; Exchange data with the peer end; Performing key derivation according to the negotiated quantum key and the key derivation parameters in the exchanged data to obtain a target key, wherein the target key is the key required for IPSec VPN encrypted communication; The negotiation exchange process is verified with the other end, so that after the verification is passed, encrypted communication is performed with the other end according to the target key.

2. The IPSec VPN-based encrypted communication method according to claim 1, characterized in that: The step of performing quantum key negotiation with the other end using the quantum key pre-stored at the local end includes: During the initiation of quantum key negotiation, the key version information of the quantum key pre-stored at the local end is sent to the other end; and / or, In the response process of quantum key negotiation, according to the received key version information of the quantum key pre-stored by the other end, a matching key version information is selected from the key version information of the quantum key pre-stored by the local end and sent to the other end, wherein the matching key version information is the key version information pre-stored by both the local end and the other end; The key version information at least carries a key identifier of the quantum key.

3. The encrypted communication method based on IPSec VPN according to claim 1 or 2, characterized in that: The key derivation is performed according to the negotiated quantum key and the key derivation parameters in the exchanged data to obtain the target key, which is achieved by the following expression: SKEYID=PRF((HASH(Ni_b|Nr_b), QKEY|CKY-I|CKY-R); SKEYID_d=PRF(SKEYID, QKEY|CKY-I|CKY-R|0); SKEYID_a=PRF(SKEYID,SKEYID_d|QKEY|CKY-I|CKY-R|1); SKEYID_e=PRF(SKEYID,SKEYID_a|QKEY|CKY-I|CKY-R|2); Among them, SKEYID_d, SKEYID_a and SKEYID_e all belong to the target key, SKEYID_d is used to generate a session key, SKEYID_a is used to verify the message integrity and data source identity, and SKEYID_e is used to protect the confidentiality of its message, PRF(x, y) represents a pseudo-random function operation based on x as a key and y as a data block, HASH(x) represents a hash operation on x, x1|x2|x3|...|xi represents the concatenation of data blocks x1, x2, x3...xi, i is a positive integer greater than 1, Ni_b and Nr_b are the Nonce payload bodies in the key derivation parameters exchanged with the peer end, QKEY is the quantum key, the numbers 0, 1, and 2 represent the numerical values ​​of a single byte, and CKY-I and CKY-R are the cookie information of the local end and the peer end respectively carried in the ISAKMP header of the data exchanged with the peer end.

4. The IPSec VPN-based encrypted communication method according to claim 1 or 2, characterized in that: The verification of the negotiation exchange process with the other end includes: Encrypted by a symmetric encryption algorithm, and verified by a negotiation exchange process with the peer end, wherein the algorithm type of the symmetric encryption algorithm is determined according to the negotiation with the peer end, the key of the symmetric encryption algorithm is determined according to the target key, the symmetric encryption algorithm adopts a ciphertext group linking mode, and the initialization vector of the symmetric encryption algorithm is determined by the following expression: IV = HASH(Ski_b|Skr_b); Wherein, IV is the initialization vector, HASH(x) represents a hash operation on x, x1|x2|x3|…|xi represents the concatenation of data blocks x1, x2, x3…xi, i is a positive integer greater than 1, and Ski_b and Skr_b are the temporary key SK payload bodies of the local end and the peer end in the data exchanged with the peer end, respectively.

5. The encrypted communication method based on IPSec VPN according to claim 1 or 2, characterized in that: The verification of the negotiation exchange process with the other end includes: Sending a first parameter to a peer end and receiving a second parameter sent by the peer end to verify the second parameter, wherein the first parameter and the second parameter are determined by the following expression: HASHi=PRF(SKEYID,QKEY|CKY-I|CKY-R|SAi_b|IDi_b); HASHr=PRF(SKEYID,QKEY|CKY-R|CKY-I|SAr_b|IDr_b); SKEYID=PRF((HASH(Ni_b|Nr_b), QKEY|CKY-I|CKY-R); Among them, HASHi is one of the first parameter and the second parameter, HASHr is the other of the first parameter and the second parameter, PRF(x, y) indicates that a pseudo-random function operation is performed on data block y based on x as a key, HASH(x) indicates that a hash operation is performed on x, x1|x2|x3|...|xi indicates that data blocks x1, x2, x3...xi are concatenated, i is a positive integer greater than 1, Ni_b and Nr_b are the Nonce payload bodies in the key derivation parameters exchanged with the opposite end, QKEY is the quantum key, IDi_b and IDr_b are respectively the identification payload bodies in the key derivation parameters exchanged with the opposite end, SAi_b and SAr_b are respectively the SA payload bodies of the local end and the opposite end exchanged during the negotiation process, and CKY-I and CKY-R are respectively the cookie information of the local end and the opposite end carried in the ISAKMP header of the exchanged data.

6. The IPSec VPN-based encrypted communication method according to claim 1 or 2, characterized in that: In the locally pre-stored quantum key, before performing quantum key negotiation with the other end, the method includes: Acquire a quantum key and store the acquired quantum key in a preset format, wherein the preset format is to encapsulate at least one of the following information together with the quantum key: the version of the quantum key, the IP address of the peer end allowed to communicate, the key validity period, and the key update strategy.

7. The IPSec VPN-based encrypted communication method according to claim 1 or 2, characterized in that: In the quantum key pre-stored at the local end, before performing quantum key negotiation with the other end, the method further includes: Determine whether the working mode is quantum mode or hybrid mode; After performing quantum key negotiation with the other end in the quantum key pre-stored at the local end, the method further includes: In the case where quantum key negotiation fails and the working mode is the hybrid mode, establishing a classic IPSec VPN encrypted communication channel with the peer end, and performing encrypted communication with the peer end based on the classic IPSec VPN encrypted communication channel; and / or, When quantum key negotiation fails and the working mode is the quantum mode, the encrypted communication based on IPSec VPN with the other end is abandoned.

8. The IPSec VPN-based encrypted communication method according to claim 7, characterized in that: When the working mode is the mixed mode, the method further includes: In the process of establishing the classical IPSec VPN encrypted communication channel with the other end, if the same pre-stored quantum key exists with the other end, the step of performing quantum key negotiation with the other end in the quantum key pre-stored at the local end is returned.

9. An IPSec VPN device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the encryption communication method based on IPSecVPN as claimed in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the encryption communication method based on IPSec VPN according to any one of claims 1 to 8 is implemented.

Images