Communication session key negotiation method, device, equipment and medium

Abstract

Disclosed are a communication session key negotiation method, apparatus, device and medium, which relate to the field of communication security, are applied to an initiator, and comprise: generating an authentication key and an encryption key based on a preset authentication key material and an encryption key material, calculating a first hash value based on the authentication key, encrypting the first hash load, the first security alliance load, the first random number load and the identification load by using the encryption key, sending the first encrypted information to a responder so that the responder verifies the received load, calculating a second hash value by using the authentication key, and sending the second hash value to the responder; encrypting a second hash load, a second security alliance load, a second random number load and an identification load by using the encryption key, and sending second encrypted information to the initiator; verifying the received load, calculating a third hash value based on the authentication key, and generating third encrypted information through the encryption key, so that a responder verifies a third hash load; and generating a material generation session key.

Description

Technical Field

[0001] The present invention relates to the field of communication security, and in particular to a communication session key negotiation method, device, equipment and medium. Background Art

[0002] In encrypted communication devices, before symmetric cipher data transmission begins, both parties must negotiate a session key, needed for encryption and authentication. After a certain period of encrypted communication or a certain amount of data has been transmitted, the session key must be renegotiated and updated. Negotiating and updating the session key requires the two parties to use a key agreement (key exchange) protocol. However, existing key agreement protocols utilize computationally intensive algorithms during the key agreement process, making them difficult to apply in scenarios where cryptographic chips have low processing power or limited computing power, such as IoT communications. Existing key agreement protocols require sending a large number of messages to complete session key negotiation, making them difficult to apply in scenarios with limited communication bandwidth, high negotiation latency requirements, and limited processing power and power consumption of the chips running the protocols, such as IoT communications. Therefore, addressing the computationally intensive algorithms used in existing key agreement protocols and the large number of messages required to complete session key negotiation remains a challenge. Summary of the Invention

[0003] In view of this, the present invention aims to provide a communication session key negotiation method, apparatus, device, and medium that can address the problem that existing key negotiation protocols use algorithms with relatively high computational complexity during the key negotiation process, and the problem that existing key negotiation protocols require sending a large number of messages to complete session key negotiation. The specific solution is as follows:

[0004] In a first aspect, the present application discloses a communication session key negotiation method, which is applied to an initiator, comprising:

[0005] generating authentication keys and encryption keys for both communicating parties based on preset authentication key material and encryption key material, calculating a first hash value corresponding to a message digest in a first hash payload based on the initiator's authentication key, and encrypting the first hash payload, the first security association payload, the first random number payload, and the identification payload using the initiator's encryption key to obtain first encrypted information; wherein the first hash value is encapsulated in the first hash payload;

[0006] Sending the first encrypted information to the responder so that the responder verifies the received payload based on the first hash value. Upon successful verification, calculating a second hash value corresponding to the message digest in the second hash payload using the responder authentication key, encrypting the second hash payload, the second security association payload, the second random number payload, and the identification payload using the responder encryption key, and sending the corresponding second encrypted information to the initiator; wherein the second hash value is encapsulated in the second hash payload;

[0007] Verifying the received payload based on the second hash value, and after the verification passes, calculating a third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key, encrypting the third hash payload using the initiator's encryption key to generate third encrypted information, and sending the third encrypted information to the responder so that the responder can verify the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload;

[0008] After the responder passes the verification, session key generation materials of both communicating parties are determined, and a session key is generated based on the session key generation materials.

[0009] Optionally, before generating the authentication key and encryption key of the communicating parties based on the preset authentication key material and encryption key material, the method further includes:

[0010] Generate encryption key material and authentication key material using a key management system;

[0011] Determining the authentication key material as the authentication key;

[0012] Hash the initiator ID, responder ID, message ID, and random number to obtain the corresponding cookies for each communicating party;

[0013] The encryption key is generated by using the initiator cookie, the responder cookie, the message ID, and the encryption key material.

[0014] Optionally, generating the authentication key and encryption key of both communicating parties based on the preset authentication key material and encryption key material includes:

[0015] Establishing a first mapping relationship between a communication device IP address and a communication device ID, and a second mapping relationship between the communication device ID and authentication key material and encryption key material;

[0016] Based on the first mapping relationship and the second mapping relationship, the communication device IP address is used to query the authentication key material and encryption key material of the communication parties, and the authentication key and encryption key of the communication parties are generated based on the authentication key material and the encryption key material.

[0017] Optionally, the message digest in the first hash payload includes the initiator cookie, the message ID, the first random number payload, the first security association payload, and the identification payload including the initiator identification payload and the responder identification payload; the message digest in the second hash payload includes the responder cookie, the initiator cookie, the message ID, the first random number payload, the second security association payload, the second random number payload, and the identification payload including the initiator identification payload and the responder identification payload; the message digest in the third hash payload includes the responder cookie, the initiator cookie, the message ID, the first random number payload, and the second random number payload.

[0018] Optionally, the verifying the received payload based on the second hash value includes:

[0019] Calculate a target hash value corresponding to the message digest in the received payload, and complete verification of the received payload based on a magnitude relationship between the target hash value and the second hash value.

[0020] Optionally, determining session key generation materials of both communicating parties includes:

[0021] Determine a first parameter based on a hash value of the random number in the initiator's first random number payload and the random number in the responder's second random number payload, the initiator's cookie, and the responder's cookie;

[0022] determining a second parameter based on the first parameter, the initiator cookie, the responder cookie, the initiator authentication key material, the responder authentication key material, the initiator encryption key material, and the responder encryption key material;

[0023] Determine a target byte sequence based on the second parameter, the random number in the first random number payload, the random number in the second random number payload, and the session protocol and security association payload identifier negotiated from the security association payload;

[0024] The target byte sequence is determined as a session key generation material for both communicating parties.

[0025] Optionally, the generating a session key based on the session key generation material includes:

[0026] A first session key for encryption and a second session key for integrity verification are sequentially selected from the target byte sequence according to the length required by the algorithm.

[0027] In a second aspect, the present application discloses a communication session key negotiation device, which is applied to an initiator, comprising:

[0028] a first encryption module, configured to generate an authentication key and an encryption key for both communicating parties based on preset authentication key material and encryption key material, calculate a first hash value corresponding to a message digest in a first hash payload based on the initiator's authentication key, and encrypt the first hash payload, the first security association payload, the first random number payload, and the identification payload using the initiator's encryption key to obtain first encrypted information; wherein the first hash value is encapsulated in the first hash payload;

[0029] a second encryption module, configured to send the first encrypted information to the responder, so that the responder verifies the received payload based on the first hash value; upon successful verification, calculate a second hash value corresponding to the message digest in the second hash payload using the responder's authentication key, encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload using the responder's encryption key, and send the corresponding second encrypted information to the initiator; wherein the second hash value is encapsulated in the second hash payload;

[0030] a third encryption module, configured to verify the received payload based on the second hash value, calculate a third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key if the verification is successful, encrypt the third hash payload using the initiator's encryption key to generate third encrypted information, and send the third encrypted information to the responder so that the responder can verify the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload;

[0031] The session key generation module is used to determine session key generation materials of both communicating parties after the responder is verified, and generate a session key based on the session key generation materials.

[0032] In a third aspect, the present application discloses an electronic device, comprising:

[0033] Memory, used to store computer programs;

[0034] The processor is configured to execute the computer program to implement the aforementioned communication session key negotiation method.

[0035] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the communication session key negotiation method as described above is implemented.

[0036] The initiator of this application first generates the authentication key and encryption key of the communicating parties based on the preset authentication key material and encryption key material, calculates the first hash value corresponding to the message digest in the first hash payload based on the initiator's authentication key, and uses the initiator's encryption key to encrypt the first hash payload, the first security association payload, the first random number payload and the identification payload to obtain the first encrypted information; wherein, the first hash value is encapsulated in the first hash payload; the first encrypted information is sent to the responder so that the responder verifies the received payload based on the first hash value. After the verification is successful, the responder authentication key is used to calculate the second hash value corresponding to the message digest in the second hash payload, and the responder encryption key is used to encrypt the second hash payload, the second security association payload, the first random number payload and the identification payload. The second encrypted information is sent to the initiator using two random number payloads and the identification payload; the second hash value is encapsulated in the second hash payload; the received payload is verified based on the second hash value; if the verification is successful, a third hash value corresponding to the message digest in the third hash payload is calculated based on the initiator's authentication key; the third hash payload is encrypted using the initiator's encryption key to generate third encrypted information; the third encrypted information is sent to the responder so that the responder can verify the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload; if the verification is successful, the session key generation material of the communicating parties is determined, and a session key is generated based on the session key generation material. This eliminates the first phase of negotiation in the IKE (Internet Key Exchange) protocol and directly enters session key negotiation, thereby reducing the number of messages and computational overhead. Session key negotiation is protected by encryption keys and authentication keys. The encryption keys and authentication keys generated using pre-set encryption key material and authentication key material, respectively, are used to ensure confidentiality, integrity, and authentication of negotiation messages. As a result, this application does not require the use of computationally intensive algorithms, making it more suitable for use in scenarios where cryptographic chips have low processing power or where power consumption is limited. Furthermore, fewer messages need to be sent during key negotiation, making it more suitable for use in scenarios where communication bandwidth is limited, negotiation latency is high, and the chip running the protocol has low processing power and power consumption is limited. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0038] Figure 1 This is a flow chart of a communication session key negotiation method disclosed in this application;

[0039] Figure 2 This is a schematic diagram of CBC mode encryption disclosed in this application;

[0040] Figure 3 A schematic diagram of the exchange process in the session key negotiation phase disclosed in this application;

[0041] Figure 4 This is a schematic diagram of the structure of a communication session key agreement device disclosed in this application;

[0042] Figure 5 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0043] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0044] Existing key negotiation protocols all use algorithms with relatively large computational load during the key negotiation process. In scenarios where the processing power of cryptographic chips is low or computing power consumption is limited, such as in IoT communications, current key negotiation protocols are difficult to apply. Existing key negotiation protocols require sending a large number of messages to complete the negotiation of session keys. In scenarios where communication bandwidth is limited, negotiation latency requirements are high, the processing power of the chip running the protocol is low, and power consumption is limited, such as in IoT communications, current key negotiation protocols are difficult to apply. In order to solve the above technical problems, the present application discloses a communication session key negotiation method, apparatus, device, and medium, which can solve the problem that existing key negotiation protocols use algorithms with relatively large computational load during the key negotiation process; and solve the problem that existing key negotiation protocols need to send a large number of messages to complete the negotiation of session keys.

[0045] See also Figure 1As shown, an embodiment of the present invention discloses a communication session key negotiation method, which is applied to an initiator, including:

[0046] Step S11: Generate authentication keys and encryption keys for both communicating parties based on preset authentication key material and encryption key material, calculate a first hash value corresponding to the message digest in the first hash payload based on the initiator's authentication key, and encrypt the first hash payload, the first security association payload, the first random number payload, and the identification payload using the initiator's encryption key to obtain first encrypted information; wherein the first hash value is encapsulated in the first hash payload.

[0047] In this embodiment, the overall design concept of the lightweight key agreement protocol of the present invention is to remove the first phase of negotiation from the national encryption IKE protocol, retaining only the second phase. The protection key for the second phase of negotiation is generated based on pre-set key material. Corresponding adjustments are made to some of the payloads and session key generation methods of the second phase of negotiation. This lightweight key agreement protocol does not have a working key negotiation phase, but only a session key negotiation phase. The communicating parties use encryption and authentication keys generated from pre-set encryption and authentication key material to protect the confidentiality and integrity of negotiation messages and authenticate the identities of both parties. The communicating parties negotiate to establish an Internet Protocol Security Association (IPSec) SA, which is a shared policy and key used to protect data communications between them. Prior to generating the authentication and encryption keys for the communicating parties, this application utilizes a key management system to generate encryption and authentication key material; determines the authentication key material as the authentication key; performs a hash operation on the initiator ID (identity document), responder ID, message ID, and a random number to obtain cookies corresponding to each communicating party; and generates an encryption key using the initiator cookie, responder cookie, message ID, and encryption key material.

[0048] The solution of pre-setting key materials in this application requires that the pre-setting key materials can be queried from the plaintext information, or that both parties have an implicit agreement. For ease of implementation, the message format and payload format definitions of this lightweight key negotiation protocol are fully compatible with the national encryption IKE, and the plaintext part of the message does not contain the information required to query the pre-setting key materials. The negotiating parties can establish a mapping relationship between the device IP (Internet Protocol) address and the device ID, and a mapping relationship between the device ID and the pre-setting key materials. In this way, the pre-setting key materials used for encryption can be queried from the source IP address of the message. Starting from the first negotiation message, all payloads can be encrypted, thereby directly entering the session key negotiation phase.

[0049] During the session key negotiation phase, the payload is encrypted using the CBC (Cipher-blockchaining) mode of the symmetric cryptographic algorithm. The key is generated using the preset encryption key material of the message sender. That is, the negotiation initiator uses SKEYID_e_i as the encryption key material to generate the encryption key, and the negotiation responder uses SKEYID_e_r as the encryption key material to generate the encryption key. The initiator cookie and IV (Initialization Vector) of the first message (Message 1) are obtained by hashing the initiator ID, responder ID, MsgID (Message ID) during the session key negotiation phase, and a random number, namely:

[0050] cookie=Hash(initiator ID|responder ID|MsgID|random number A);

[0051] This formula applies to the initiator and responder generating their own cookies. MsgID is the MsgID in message 1 of this negotiation instance, and both the initiator and responder use the same MsgID. Random number A is a 24-byte random number, generated by each initiator and responder when they generate their own cookies. From the 32-byte (256-bit) result of the hash algorithm SM3, bytes 1 to 8 are sequentially taken as the cookie. The cookie is required to uniquely identify an SA generated by this party. If the newly generated cookie is the same as the cookie corresponding to a currently valid SA or an SA being negotiated, random number A needs to be modified to generate a non-conflicting cookie.

[0052] IV=(Initiator ID|Responder ID|MsgID|Initiator cookie);

[0053] The IV of message 1 is generated according to the above formula, and the IV of subsequent messages (message 2, message 3) is the last set of ciphertext of the previous message.

[0054] It should be noted that cookies are usually a small piece of information generated temporarily, usually used as a cache or identifier, and have a certain degree of unpredictability. In CBC working mode, IV is required. Each time encryption is performed, a different bit sequence must be randomly generated as the initialization vector, such as Figure 2 shown.

[0055] The exchange process of the session key negotiation phase is as follows Figure 3As shown, message 1 is a message sent from the initiator to the responder, consisting of a hash payload, a security association payload (which encapsulates one or more suggestion payloads, each of which encapsulates one or more transform payloads), a nonce payload, and an identification payload. The message digest in the hash payload is calculated as follows:

[0056] HASH(1)=PRF(SKEYID_a_i, initiator cookie|MsgID|Ni_b|SA|IDi|IDr);

[0057] Among them, SKEYID_a_i is the preset authentication key material of the initiator. PRF (key, msg) is the data digest operation of the message msg using the key key; MsgID is the message ID; Ni_b is the main body of the initiator's nonce payload, that is, a random number; SA is the security association payload with one or more recommended payloads. IDi is the identification payload of the initiator; IDr is the identification payload of the responder. That is to say, this application calculates the first hash value corresponding to the message digest in the first hash payload based on the initiator's authentication key, and then uses the initiator's encryption key to encrypt the first hash payload, the first security association payload, the first random number payload and the identification payload to obtain the first encrypted information. It is to encrypt the transmitted information using the encryption key. Among them, the first hash value is encapsulated in the first hash payload and encrypted as a whole, and the hash value is not encrypted separately. In this way, the first phase negotiation in the IKE protocol is removed, and the session key negotiation is directly entered, thereby reducing the number of messages and computing overhead. Session key negotiation is protected by encryption and authentication keys, which are derived from pre-set encryption and authentication key materials, respectively, to ensure confidentiality, integrity, and authentication of negotiation messages. The pre-set encryption and authentication key materials can be retrieved from information such as the device IP address and device ID. In this lightweight key negotiation protocol, all payloads are encrypted, with only the message header being plaintext. Therefore, the plaintext header allows both negotiating parties to quickly locate the current negotiation instance, which includes two IPSec SAs. Therefore, the cookie generation method includes the device IDs of both parties, the MsgID (message ID) for this negotiation, and a random number. Consequently, the cookie generation method and its function differ from those of the IKE protocol.

[0058] Step S12: Send the first encrypted information to the responder, so that the responder verifies the received payload based on the first hash value. After successful verification, use the responder authentication key to calculate a second hash value corresponding to the message digest in the second hash payload, use the responder encryption key to encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload, and send the corresponding second encrypted information to the initiator; wherein the second hash value is encapsulated in the second hash payload.

[0059] In this embodiment, the initiator sends the first encrypted information to the responder. After receiving the first encrypted information, the responder verifies the received payload based on the first hash value, that is, the responder calculates the hash value corresponding to the message digest in the received payload, and then completes the verification of the received payload based on the size relationship between its hash value and the first hash value. If the hash value calculated this time is equal to the first hash value, it indicates that the information received by the responder is complete and has not been tampered with. After that, the responder can proceed to the next step of information transmission. That is, message 2: the responder sends a hash payload, a security association payload, a nonce payload and an identification payload to the initiator. The calculation method of the message digest in the hash payload is as follows:

[0060] HASH(2)=PRF(SKEYID_a_r, initiator cookie|responder cookie|MsgID|Ni_b|SA|Nr_b|IDi|IDr);

[0061] Here, SKEYID_a_r is the preset authentication key material of the responder. PRF(key, msg) represents the data digest calculation performed on the message msg using the key key; MsgID is the message ID; Ni_b is the main body of the initiator's nonce payload, also known as a random number; Nr_b is the main body of the responder's nonce payload, also known as a random number; SA is the security association payload with one or more suggestion payloads. IDi is the initiator's identification payload; IDr is the responder's identification payload. Specifically, the responder verifies the received payload based on the first hash value. Upon successful verification, it calculates a second hash value corresponding to the message digest in the second hash payload using the responder's authentication key. It then encrypts the second hash payload, the second security association payload, the second random number payload, and the identification payload using the responder's encryption key, and sends the corresponding second encrypted information to the initiator. The second hash value is encapsulated in the second hash payload. Similarly, the hash value is calculated using the authentication key, and the transmitted information is encrypted using the encryption key. The second encrypted information is then sent to the initiator.

[0062] Step S13: Verify the received payload based on the second hash value. After the verification is successful, calculate a third hash value corresponding to the message digest in the third hash payload based on the initiator authentication key, encrypt the third hash payload using the initiator encryption key, generate third encrypted information, and send the third encrypted information to the responder, so that the responder verifies the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload.

[0063] In this embodiment, after the responder sends the second encrypted message to the sender, the sender verifies the received payload based on the second hash value. Specifically, the sender calculates the target hash value corresponding to the message digest in the received payload and verifies the received payload based on the magnitude relationship between the target hash value and the second hash value. If the two hash values ​​are identical, verification is successful, and the initiator can then proceed to the next information transmission, namely, Message 3: The initiator sends a hash payload to the responder to authenticate the previous exchange. The message digest in the hash payload is calculated as follows:

[0064] HASH(3)=PRF(SKEYID_a_i, initiator cookie|responder cookie|MsgID|Ni_b|Nr_b);

[0065] Among them, SKEYID_a_i is the preset authentication key material of the initiator. PRF(key, msg) is to perform data digest operation on message msg using key key; MsgID is the message ID; Ni_b is the main body of the initiator's nonce payload, that is, a random number; Nr_b is the main body of the responder's nonce payload, that is, a random number. In this process, the third hash value is encapsulated in the third hash payload, and the initiator calculates the third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key, and then encrypts the third hash payload with the initiator's encryption key to generate the third encrypted information, and sends the third encrypted information to the responder so that the responder can verify the received third hash payload based on the third hash value. The verification method is the same as the above verification method and will not be repeated here. If the verification is successful, the information exchanged in the session key negotiation phase can be used to perform subsequent session key generation operations.

[0066] Step S14: After the responder passes the verification, determine the session key generation materials of the communicating parties, and generate a session key based on the session key generation materials.

[0067] In this embodiment, after the verification of the responder of this application is passed, the first parameter is determined based on the hash value of the random number in the first random number payload of the initiator and the random number in the second random number payload of the responder, the initiator cookie, and the responder cookie; the second parameter is determined based on the first parameter, the initiator cookie, the responder cookie, the initiator authentication key material, the responder authentication key material, the initiator encryption key material, and the responder encryption key material; the target byte sequence is determined based on the second parameter, the random number in the first random number payload, the random number in the second random number payload, and the session protocol and security association payload identifier negotiated from the security association payload; the target byte sequence is determined as the session key generation material for the communicating parties. The first session key for encryption and the second session key for integrity verification are selected from the target byte sequence in sequence according to the length required by the algorithm. Specifically, the session key material is defined as:

[0068] SKEYID=PRF(Hash(Ni_b|Nr_b),initiator cookie|responder cookie);

[0069] SKEYID_d=PRF(SKEYID,initiator cookie|responder cookie|SKEYID_a_i|SKEYID_a_r|SKEYID_e_i|SKEYID_e_r);

[0070] KEYMAT=PRF(SKEYID_d,protocol|SPI|Ni_b|Nr_b);

[0071] SKEYID is the first parameter; SKEYID_d is the second parameter; KEYMAT is a byte sequence; SKEYID_a_r is the preset authentication key material for the responder; SKEYID_a_i is the preset authentication key material for the initiator; PRF(key, msg) is the data digest operation performed on the message msg using the key key; Ni_b is the main body of the initiator's nonce payload, also known as a random number; Nr_b is the main body of the responder's nonce payload, also known as a random number; SKEYID_e_i is the initiator's encryption key material; SKEYID_e_r is the responder's encryption key material; SPI is the number used to identify the SA; protocol is the protocol; protocol and SPI are selected from the negotiated suggested payload. The session key for encryption and the session key for integrity verification are then selected from KEYMAT in sequence according to the length required by the algorithm. The encryption session key is selected first, followed by the integrity session key.

[0072] When the output length of the PRF function is less than the key material length required by KEYMAT, it is necessary to use feedback and connection methods to expand it until the key length requirement is met. That is:

[0073] KEYMAT=K1|K2|K3|...;

[0074] in:

[0075] K1=PRF(SKEYID_d, protocol|SPI|Ni_b|Nr_b);

[0076] K2=PRF(SKEYID_d,K1|protocol|SPI|Ni_b|Nr_b);

[0077] K3=PRF(SKEYID_d,K2|protocol|SPI|Ni_b|Nr_b);

[0078] ….

[0079] A single SA negotiation generates two security associations: one inbound and one outbound. The different SPIs for each SA (one chosen by the initiator and the other by the responder) ensure a different KEYMAT for each direction. The SPI chosen by the destination of the SA is used to derive the KEYMAT for that SA.

[0080] It should be noted that the first phase of the IKE protocol implements the authentication function of the communicating parties and the negotiation of the protection key in the second phase, that is, the confidentiality protection function. Although this application has cut the first phase of the IKE protocol, it does not weaken the security of the protocol.

[0081] In terms of authentication function: the present invention protects the interaction of three messages by generating an encryption key through a preset encryption key material. While negotiating the working key, it also uses the authentication key corresponding to the preset authentication key material to implement the entity authentication method specified in Section "5.2.2 Three-way transfer authentication" of GBT15843.2, thereby realizing a secure identity authentication function.

[0082] In terms of confidentiality protection: The confidentiality of the second phase of the IKE negotiation relies on the confidentiality of the two protection keys negotiated in the first phase and the security of the algorithm and protocol design. The protection keys are actually derived from two nonce payloads encrypted with the SM2 algorithm, so confidentiality ultimately depends on the security of the SM2 algorithm, the security of the SM2 private key, the randomness of the nonce, and the security of the first-phase protocol design. However, this application eliminates the first-phase negotiation, and the confidentiality protection of the second-phase negotiation process relies on the confidentiality of the preset key material. Therefore, the confidentiality of the negotiation process of this application relies on the security of the preset key material, just as the IKE relies on the security of the SM2 private key. As long as the security of the preset key material is not lower than the security of the SM2 private key of the IKE, the security will not be weakened. The security protection of the preset key material is an implementation-level consideration and will not be explained in detail here. In addition, this application also takes security into consideration when designing cookies, IVs, hash payloads, and session key generation methods to ensure that the security is not lower than that of the IKE protocol.

[0083] To summarize, the initiator of this application first generates the authentication key and encryption key of the communicating parties, calculates the first hash value corresponding to the message digest in the first hash payload based on the initiator's authentication key, and uses the initiator's encryption key to encrypt the first hash payload, the first security association payload, the first random number payload, and the identification payload to obtain the first encrypted information; wherein, the first hash value is encapsulated in the first hash payload; the first encrypted information is sent to the responder so that the responder verifies the received payload based on the first hash value. After successful verification, the responder authentication key is used to calculate the second hash value corresponding to the message digest in the second hash payload, and the responder encryption key is used to encrypt the second hash payload, the second security association payload, and the second random number payload. and the identification payload, sending the corresponding second encrypted information to the initiator; wherein the second hash value is encapsulated in the second hash payload; the received payload is verified based on the second hash value, and after the verification is passed, the third hash value corresponding to the message digest in the third hash payload is calculated based on the initiator's authentication key, the third hash payload is encrypted by the initiator's encryption key, and the third encrypted information is generated, and the third encrypted information is sent to the responder, so that the responder can verify the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload; after the verification of the responder is passed, the session key generation material of the communicating parties is determined, and the session key is generated based on the session key generation material. It can be seen that the present application removes the first phase negotiation in the IKE protocol and directly enters the session key negotiation, thereby reducing the number of messages and computing overhead. The session key negotiation is protected by encryption keys and authentication keys, and the encryption keys and authentication keys generated by the preset encryption key material and authentication key material are used to realize the confidentiality protection, integrity protection and authentication functions of the negotiation messages. As a result, this application does not require the use of computationally intensive algorithms, making it more suitable for use in scenarios where cryptographic chips have low processing power or where power consumption is limited. Furthermore, fewer messages need to be sent during key negotiation, making it more suitable for use in scenarios where communication bandwidth is limited, negotiation latency is high, and the chip running the protocol has low processing power and power consumption is limited.

[0084] Based on the previous embodiment, it can be seen that before generating the authentication key and encryption key for both communicating parties based on the preset authentication key material and encryption key material, this application will use the key management system to generate encryption key material and authentication key material; determine the authentication key material as the authentication key; perform a hash operation on the initiator ID, responder ID, message ID, and random number to obtain a cookie corresponding to each communicating party; and generate an encryption key using the initiator cookie, responder cookie, the message ID, and the encryption key material. Next, the specific encryption key and authentication key generation process will be described in detail.

[0085] In this embodiment, the authentication payload, the result of the authentication key calculation, is encrypted and protected, so the authentication key directly uses the preset authentication key material without the need for derivation calculation. Only the encryption key needs to be derived and calculated from the preset encryption key material.

[0086] Except for the message header, all subsequent payloads of Messages 1, 2, and 3 are encrypted and transmitted in SM4 CBC mode. The encryption key SKEYID_m_e for the encrypted message payload is derived from the sender's pre-set encryption key material. The specific derivation method is as follows:

[0087] SKEYID_m_0=PRF(SKEYID_e, initiator cookie|responder cookie|MsgID|0);

[0088] SKEYID_m_1=PRF(SKEYID_m_0, initiator cookie|responder cookie|MsgID|1);

[0089] SKEYID_m_2=PRF(SKEYID_m_1, initiator cookie|responder cookie|MsgID|2);

[0090] The SKEYID_e is the preset encryption key material SKEYID_e_i when the initiator encrypts the message, and is SKEYID_e_r when the responder encrypts the message.

[0091] Then take the first 128 bits of SKEYID_m_2 as the message encryption key SKEYID_m_e of the payload in the encrypted message, which is called the initiator message encryption key SKEYID_m_e_i on the initiator and the responder message encryption key SKEYID_m_e_r on the responder.

[0092] The initiator cookie and responder cookie in the three formulas all take the value of the message header to be encrypted. That is, the responder cookie in message 1 is always 0, and the responder cookie in message 3 is not 0. Therefore, the derived encryption keys corresponding to the three messages are different.

[0093] Special provisions are made here: the preset shared encryption key material and authentication key material are both generated by the key management system, are independent of each other and have no derivative relationship, and must be sufficiently random; the length of the preset encryption key material SKEYID_e must be at least 2 bytes greater than the SM4 key length (16 bytes).

[0094] In this way, the preset encryption key material and authentication key material are independent of each other and have no derivative relationship. One is used to protect the confidentiality of the payload and the other is used for message authentication. The protection key for the actual encrypted message payload is derived from the preset protection key material, and the length of the encryption key material input to the key derivation formula is stipulated to be greater than the length of the output encryption key. The derivation formula for generating the protection key contains unique information for each message, and each message is one-time and one-pad. The information used to generate the authentication payload contains information that is not transmitted in plain text, and the authentication payload is always encrypted, which enhances the security of the protocol.

[0095] See also Figure 4 As shown, an embodiment of the present invention discloses a communication session key negotiation device, which is applied to an initiator, including:

[0096] A first encryption module 11 is configured to generate an authentication key and an encryption key for both communicating parties based on preset authentication key material and encryption key material, calculate a first hash value corresponding to a message digest in a first hash payload based on the initiator's authentication key, and encrypt the first hash payload, the first security association payload, the first random number payload, and the identification payload using the initiator's encryption key to obtain first encrypted information; wherein the first hash value is encapsulated in the first hash payload;

[0097] a second encryption module 12 configured to send the first encrypted information to the responder, so that the responder verifies the received payload based on the first hash value; and upon successful verification, calculate a second hash value corresponding to the message digest in the second hash payload using the responder's authentication key, encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload using the responder's encryption key, and send the corresponding second encrypted information to the initiator; wherein the second hash value is encapsulated in the second hash payload;

[0098] a third encryption module 13 configured to verify the received payload based on the second hash value, and upon successful verification, calculate a third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key, encrypt the third hash payload using the initiator's encryption key to generate third encrypted information, and send the third encrypted information to the responder so that the responder can verify the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload;

[0099] The session key generation module 14 is configured to determine session key generation materials of both communicating parties after the responder passes verification, and generate a session key based on the session key generation materials.

[0100] The initiator of this application first generates the authentication key and encryption key of the communicating parties, calculates the first hash value corresponding to the message digest in the first hash payload based on the initiator's authentication key, and uses the initiator's encryption key to encrypt the first hash payload, the first security association payload, the first random number payload and the identification payload to obtain the first encrypted information; wherein, the first hash value is encapsulated in the first hash payload; the first encrypted information is sent to the responder so that the responder verifies the received payload based on the first hash value. After the verification is successful, the responder authentication key is used to calculate the second hash value corresponding to the message digest in the second hash payload, and the responder encryption key is used to encrypt the second hash payload, the second security association payload, the second random number payload and the identification payload. The identification payload is used to send the corresponding second encrypted information to the initiator; wherein the second hash value is encapsulated in the second hash payload; the received payload is verified based on the second hash value, and after the verification is passed, the third hash value corresponding to the message digest in the third hash payload is calculated based on the initiator's authentication key, the third hash payload is encrypted by the initiator's encryption key, and the third encrypted information is generated, and the third encrypted information is sent to the responder so that the responder can verify the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload; after the verification of the responder is passed, the session key generation material of the communicating parties is determined, and the session key is generated based on the session key generation material. It can be seen that the present application removes the first phase negotiation in the IKE protocol and directly enters the session key negotiation, thereby reducing the number of messages and computing overhead. The session key negotiation is protected by encryption keys and authentication keys, and the encryption keys and authentication keys generated by the preset encryption key material and authentication key material are used to realize the confidentiality protection, integrity protection and authentication functions of the negotiation messages. As a result, this application does not require the use of computationally intensive algorithms, making it more suitable for use in scenarios where cryptographic chips have low processing power or where power consumption is limited. Furthermore, fewer messages need to be sent during key negotiation, making it more suitable for use in scenarios where communication bandwidth is limited, negotiation latency is high, and the chip running the protocol has low processing power and power consumption is limited.

[0101] In some specific embodiments, the device can also be used to generate encryption key material and authentication key material using a key management system; determine the authentication key material as the authentication key; perform hash operations on the initiator ID, responder ID, message ID and random number to obtain cookies corresponding to each of the communicating parties; and generate the encryption key using the initiator cookie, responder cookie, the message ID and the encryption key material.

[0102] In some specific embodiments, the first encryption module 11 can be specifically used to establish a first mapping relationship between the IP address of the communication device and the communication device ID, and a second mapping relationship between the communication device ID and the authentication key material and the encryption key material; based on the first mapping relationship and the second mapping relationship, the communication device IP address is used to query the authentication key material and encryption key material of the communicating parties, and based on the authentication key material and the encryption key material, the authentication key and encryption key of the communicating parties are generated.

[0103] In some specific embodiments, the second encryption module 12 can be specifically used to calculate a target hash value corresponding to a message digest in a received payload, and verify the received payload based on a size relationship between the target hash value and the second hash value.

[0104] In some specific embodiments, the session key generation module 14 can be specifically used to determine a first parameter based on the hash value of the random number in the initiator's first random number payload and the random number in the responder's second random number payload, the initiator's cookie, and the responder's cookie; determine a second parameter based on the first parameter, the initiator's cookie, the responder's cookie, the initiator's authentication key material, the responder's authentication key material, the initiator's encryption key material, and the responder's encryption key material; determine a target byte sequence based on the second parameter, the random number in the first random number payload, the random number in the second random number payload, and the session protocol and security association payload identifier negotiated from the security association payload; and determine the target byte sequence as the session key generation material for the communicating parties.

[0105] In some specific embodiments, the session key generation module 14 may be configured to sequentially select a first session key for encryption and a second session key for integrity verification from the target byte sequence according to the length required by the algorithm.

[0106] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram should not be considered as any limitation to the scope of application of the present application.

[0107] Figure 5This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the communication session key agreement method disclosed in any of the aforementioned embodiments. Furthermore, the electronic device 20 in this embodiment may be a computer.

[0108] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0109] In addition, the memory 22 as a carrier for resource storage can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0110] The operating system 221 is used to manage and control the hardware devices on the electronic device 20 and the computer program 222, and can be Windows Server, NetWare, Unix, Linux, etc. In addition to including a computer program capable of implementing the communication session key negotiation method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program capable of implementing other specific tasks.

[0111] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program implements the aforementioned communication session key negotiation method. The specific steps of this method can be referred to the corresponding contents disclosed in the aforementioned embodiments and will not be repeated here.

[0112] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0113] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0114] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0115] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0116] The above is a detailed introduction to the technical solution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A communication session key negotiation method, characterized in that: Applied to the initiator, including: generating authentication keys and encryption keys for both communicating parties based on preset authentication key material and encryption key material, calculating a first hash value corresponding to a message digest in a first hash payload based on the initiator's authentication key, and encrypting the first hash payload, the first security association payload, the first random number payload, and the identification payload using the initiator's encryption key to obtain first encrypted information; wherein the first hash value is encapsulated in the first hash payload; Sending the first encrypted information to the responder so that the responder verifies the received payload based on the first hash value. Upon successful verification, calculating a second hash value corresponding to the message digest in the second hash payload using the responder authentication key, encrypting the second hash payload, the second security association payload, the second random number payload, and the identification payload using the responder encryption key, and sending the corresponding second encrypted information to the initiator; wherein the second hash value is encapsulated in the second hash payload; Verifying the received payload based on the second hash value, and after the verification passes, calculating a third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key, encrypting the third hash payload using the initiator's encryption key to generate third encrypted information, and sending the third encrypted information to the responder so that the responder can verify the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload; After the responder passes the verification, session key generation materials of both communicating parties are determined, and a session key is generated based on the session key generation materials.

2. The communication session key negotiation method according to claim 1, wherein: Before generating the authentication key and encryption key of the communicating parties based on the preset authentication key material and encryption key material, the method further includes: Generate encryption key material and authentication key material using a key management system; Determining the authentication key material as the authentication key; Hash the initiator ID, responder ID, message ID, and random number to obtain the corresponding cookies for each communicating party; The encryption key is generated by using the initiator cookie, the responder cookie, the message ID, and the encryption key material.

3. The communication session key negotiation method according to claim 1, wherein: The generating of the authentication key and encryption key of the communicating parties based on the preset authentication key material and encryption key material includes: Establishing a first mapping relationship between a communication device IP address and a communication device ID, and a second mapping relationship between the communication device ID and authentication key material and encryption key material; Based on the first mapping relationship and the second mapping relationship, the communication device IP address is used to query the authentication key material and encryption key material of the communication parties, and the authentication key and encryption key of the communication parties are generated based on the authentication key material and the encryption key material.

4. The communication session key negotiation method according to claim 1, wherein: The message digest in the first hash payload includes an initiator cookie, a message ID, the first random number payload, the first security association payload, and the identification payload including an initiator identification payload and a responder identification payload; the message digest in the second hash payload includes a responder cookie, the initiator cookie, the message ID, the first random number payload, the second security association payload, the second random number payload, and the identification payload including an initiator identification payload and a responder identification payload; and the message digest in the third hash payload includes the responder cookie, the initiator cookie, the message ID, the first random number payload, and the second random number payload.

5. The communication session key negotiation method according to claim 1, wherein: The verifying the received payload based on the second hash value includes: Calculate a target hash value corresponding to the message digest in the received payload, and complete verification of the received payload based on a magnitude relationship between the target hash value and the second hash value.

6. The communication session key negotiation method according to any one of claims 1 to 5, characterized in that: The determining of session key generation materials for both communicating parties includes: Determine a first parameter based on a hash value of the random number in the initiator's first random number payload and the random number in the responder's second random number payload, the initiator's cookie, and the responder's cookie; determining a second parameter based on the first parameter, the initiator cookie, the responder cookie, the initiator authentication key material, the responder authentication key material, the initiator encryption key material, and the responder encryption key material; Determine a target byte sequence based on the second parameter, the random number in the first random number payload, the random number in the second random number payload, and the session protocol and security association payload identifier negotiated from the security association payload; The target byte sequence is determined as a session key generation material for both communicating parties.

7. The communication session key negotiation method according to claim 6, characterized in that: The generating of the session key based on the session key generating material includes: A first session key for encryption and a second session key for integrity verification are sequentially selected from the target byte sequence according to the length required by the algorithm.

8. A communication session key negotiation device, characterized in that: Applied to the initiator, including: a first encryption module, configured to generate an authentication key and an encryption key for both communicating parties based on the preset authentication key material and the encryption key material, calculate a first hash value corresponding to the message digest in the first hash payload based on the initiator's authentication key, and encrypt the first hash payload, the first security association payload, the first random number payload, and the identification payload using the initiator's encryption key to obtain first encrypted information; wherein the first hash value is encapsulated in the first hash payload; a second encryption module, configured to send the first encrypted information to the responder, so that the responder verifies the received payload based on the first hash value; upon successful verification, calculate a second hash value corresponding to the message digest in the second hash payload using the responder's authentication key, encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload using the responder's encryption key, and send the corresponding second encrypted information to the initiator; wherein the second hash value is encapsulated in the second hash payload; a third encryption module, configured to verify the received payload based on the second hash value, calculate a third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key if the verification is successful, encrypt the third hash payload using the initiator's encryption key to generate third encrypted information, and send the third encrypted information to the responder so that the responder can verify the received third hash payload based on the third hash value; the third hash value is encapsulated in the third hash payload; The session key generation module is used to determine session key generation materials of both communicating parties after the responder is verified, and generate a session key based on the session key generation materials.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the communication session key negotiation method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that Used to store a computer program; wherein, when the computer program is executed by a processor, the communication session key negotiation method according to any one of claims 1 to 7 is implemented.

Images