A communication session key agreement method, apparatus, device and medium

Abstract

This application discloses a communication session key negotiation method, apparatus, device, and medium, relating to the field of communication security and applied to the initiator. The method includes: generating an authentication key and an encryption key based on pre-set authentication key material and encryption key material; calculating a first hash value based on the authentication key; encrypting a first hash payload, a first security association payload, a first random number payload, and an identifier payload using the encryption key; sending the first encrypted information to the responder so that the responder can verify the received payload; calculating a second hash value using the authentication key; encrypting a second hash payload, a second security association payload, a second random number payload, and an identifier payload using the encryption key; sending the second encrypted information to the initiator; verifying the received payload; calculating a third hash value based on the authentication key; generating third encrypted information using the encryption key so that the responder can verify the third hash payload; and generating materials to generate a session key.

Description

Technical Field

[0001] This invention relates to the field of communication security, and in particular to a communication session key negotiation method, apparatus, device, and medium. Background Technology

[0002] In encrypted communication devices, before transmitting symmetric cryptographic data, both communicating parties need to negotiate a session key required for encrypting and verifying the data. After a certain period of encrypted communication or after transmitting a certain amount of data, the session key also needs to be renegotiated and updated. Negotiating and updating the session key requires the communicating parties to use a key negotiation (key exchange) protocol. However, existing key negotiation protocols use computationally intensive algorithms during the key negotiation process. In scenarios where the processing power of cryptographic chips is limited or where there are constraints on computational power consumption, such as in IoT communication, current key negotiation protocols are difficult to apply. Existing key negotiation protocols require sending a large number of messages to complete the session key negotiation. In scenarios with limited communication bandwidth, high negotiation latency requirements, and limitations on the processing power and power consumption of the chip running the protocol, such as in IoT communication, current key negotiation protocols are difficult to apply. Therefore, solving the problems of existing key negotiation protocols using computationally intensive algorithms and requiring the sending of numerous messages to complete the session key negotiation is a current challenge. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a communication session key negotiation method, apparatus, device, and medium, which can solve the problem that existing key negotiation protocols use computationally intensive algorithms 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 session key negotiation. The specific solution is as follows:

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

[0005] The authentication key and encryption key of the two communicating parties are generated based on the preset authentication key material and encryption key material. The first hash value corresponding to the message digest in the first hash payload is calculated based on the initiator's authentication key. The first hash payload, the first security association payload, the first random number payload and the identifier payload are encrypted using the initiator's encryption key to obtain the first encrypted information. The first hash value is encapsulated in the first hash payload.

[0006] The first encrypted information is sent to the responder so that the responder can verify the received payload based on the first hash value. After successful verification, the responder uses the responder's authentication key to calculate the second hash value corresponding to the message digest in the second hash payload. The responder uses the responder's encryption key to encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload. The corresponding second encrypted information is then sent to the initiator. The second hash value is encapsulated in the second hash payload.

[0007] The received payload is verified based on the second hash value. After successful verification, 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 then encrypted using the initiator's encryption key to generate the third encrypted information. The third encrypted information is then 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 within the third hash payload.

[0008] After the responder's verification is successful, the session key generation material for both communicating parties is determined, and a session key is generated based on the session key generation material.

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

[0010] Use the key management system to generate encryption key materials and authentication key materials;

[0011] The authentication key material is determined as the authentication key;

[0012] Perform a hash operation on the initiator ID, responder ID, message ID, and random number to obtain the cookies corresponding to each of the communicating parties;

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

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

[0015] Establish a first mapping relationship between the communication device IP address 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;

[0016] Based on the first mapping relationship and the second mapping relationship, the authentication key material and encryption key material of both communicating parties are queried using the IP address of the communication device, and the authentication key material and encryption key material of both communicating 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 identifier payload including the initiator identifier payload and the responder identifier 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 identifier payload including the initiator identifier payload and the responder identifier 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 verification of the received payload based on the second hash value includes:

[0019] Calculate the target hash value corresponding to the message digest in the received payload, and verify the received payload based on the size relationship between the target hash value and the second hash value.

[0020] Optionally, the process of determining the session key generation material for both communicating parties includes:

[0021] The first parameter is determined based on the hash values ​​of the random numbers in the first random number payload of the initiator and the second random number payload of the responder, as well as the initiator's cookie and the responder's cookie;

[0022] 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.

[0023] 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 number negotiated from the security association payload;

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

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

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

[0027] Secondly, this application discloses a communication session key negotiation device, applied to the initiator, comprising:

[0028] The first encryption module is used to generate authentication keys and encryption keys for both communicating parties based on preset authentication key materials and encryption key materials, calculate the 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 identifier payload using the initiator's encryption key to obtain the first encrypted information; wherein, the first hash value is encapsulated in the first hash payload;

[0029] The second encryption module is used to send the first encrypted information to the responder, so that the responder can verify the received payload based on the first hash value. After successful verification, the responder uses the second hash value corresponding to the message digest in the second hash payload calculated using the responder's authentication key, and uses the responder's encryption key to encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload, and sends the corresponding second encrypted information to the initiator; wherein, the second hash value is encapsulated in the second hash payload;

[0030] The third encryption module is used to verify the received payload based on the second hash value. After successful verification, it calculates the third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key, encrypts the third hash payload with the initiator's encryption key, generates 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 third hash value is encapsulated in the third hash payload.

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

[0032] Thirdly, this application discloses an electronic device, including:

[0033] Memory, used to store computer programs;

[0034] A processor is configured to execute the computer program to implement the communication session key negotiation method as described above.

[0035] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the communication session key negotiation method as described above.

[0036] The initiator first generates authentication and encryption keys for both communicating parties based on pre-set authentication and encryption key materials. Based on the initiator's authentication key, a first hash value corresponding to the message digest in the first hash payload is calculated. The first hash payload, first security association payload, first random number payload, and identifier payload are then encrypted using the initiator's encryption key to obtain first encrypted information. The first hash value is encapsulated within the first hash payload. This first encrypted information is then sent to the responder, who verifies the received payload based on the first hash value. Upon successful verification, the responder calculates a second hash value corresponding to the message digest in the second hash payload using their authentication key. The second hash payload, second security association payload, and first random number payload are then encrypted using the responder's encryption key. The system sends a second encrypted message to the initiator, consisting of a random number payload and an identifier payload. The second hash value is encapsulated within the second hash payload. The received payload is verified based on the second hash value. Upon successful verification, 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 then encrypted using the initiator's encryption key to generate third encrypted information, which is sent to the responder. The responder then verifies the received third hash payload based on the third hash value. The third hash value is encapsulated within the third hash payload. After successful verification by the responder, the session key generation materials for both communicating parties are determined, and a session key is generated based on these materials. This application eliminates the first-phase negotiation in the IKE (Internet Key Exchange) protocol, directly proceeding to session key negotiation, thereby reducing the number of messages and computational overhead. Session key negotiation is protected using encryption and authentication keys. The encryption and authentication keys generated from pre-set encryption and authentication key materials respectively achieve confidentiality, integrity, and authentication functions for the negotiated messages. In this way, this application does not require the introduction of computationally intensive algorithms, making it more suitable for scenarios where cryptographic chips have limited processing power or where power consumption is limited. Furthermore, it requires fewer messages to be sent during key negotiation, making it better suited for scenarios with limited communication bandwidth, high negotiation latency requirements, low chip processing power for the protocol, and power consumption constraints. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

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

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

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

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

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

[0043] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0044] Existing key negotiation protocols all employ computationally intensive algorithms during the key negotiation process. In scenarios where cryptographic chips have limited processing power or power consumption constraints, such as IoT communications, current key negotiation protocols are difficult to apply. They require sending a large number of messages to complete the session key negotiation, which is also problematic in scenarios with limited communication bandwidth, high latency requirements, low processing power of the chip running the protocol, and power consumption constraints, such as IoT communications. To address these technical problems, this application discloses a communication session key negotiation method, apparatus, device, and medium that solves the problem of existing key negotiation protocols using computationally intensive algorithms and requiring the sending of numerous messages to complete the session key negotiation.

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

[0046] Step S11: Generate authentication keys and encryption keys for both communicating parties based on preset authentication key materials and encryption key materials; calculate the first hash value corresponding to the message digest in the first hash payload based on the initiator's authentication key; encrypt the first hash payload, the first security association payload, the first random number payload, and the identifier payload using the initiator's encryption key to obtain the 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 negotiation protocol of the present invention is to remove the first-stage negotiation based on the national cryptographic IKE protocol, retaining only the second-stage negotiation. The protection key for the second-stage negotiation is generated based on pre-set key materials, and corresponding adjustments have been made to some of the payloads and session key generation methods for the second-stage negotiation. This lightweight key negotiation protocol does not have a working key negotiation stage, but only a session key negotiation stage. The communicating parties use the encryption key and authentication key generated by the pre-set encryption key materials and authentication key materials to protect the confidentiality and integrity of the negotiation messages and complete the identity authentication of the negotiating parties. The communicating parties negotiate to establish an IPSec SA (Internet Protocol Security Association). The IPSec SA is a shared policy and key used to protect the data communication between them. Before generating the authentication key and encryption key for the communicating parties, this application uses a key management system to generate encryption key materials and authentication key materials; determines the authentication key material as the authentication key; performs a hash operation on the initiator ID (Identity document), responder ID, message ID, and random number to obtain the cookies corresponding to each of the communicating parties; and generates the encryption key through the initiator cookie, responder cookie, the message ID, and encryption key materials.

[0048] The scheme using pre-defined key materials in this application requires that the pre-defined key materials can be retrieved from plaintext information, or that both parties implicitly agree on their terms. For ease of implementation, the message format and payload format of this lightweight key negotiation protocol are fully compatible with the Chinese national cryptographic standard IKE. The plaintext portion of the message does not contain the information needed to retrieve the pre-defined key materials. The negotiating parties can establish a mapping relationship between device IP (Internet Protocol) addresses and device IDs, as well as a mapping relationship between device IDs and pre-defined key materials. In this way, the pre-defined key materials used for encryption can be retrieved from the source IP address of the message. From the very first negotiation message, all payloads can be encrypted, thus directly entering the session key negotiation phase.

[0049] During the session key negotiation phase, the payload encryption uses the CBC (Cipher-blockchaining) working mode of a symmetric cryptographic algorithm. The key is generated using pre-set encryption key materials from 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) from the session key negotiation phase, and a random number.

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

[0051] This formula applies to both the initiator and the responder generating their own cookies. MsgID is the MsgID from message 1 of this negotiation instance; both the initiator and the responder use the same MsgID. Random number A is a 24-byte random number, generated separately by each party when generating their respective cookies. Bytes 1-8 are sequentially extracted from the 32-byte (256-bit) result of the Hash Algorithm SM3 as the cookie. The cookie must uniquely identify a SA generated by this party. If a newly generated cookie is identical to the cookie corresponding to a currently valid SA of this party or a SA under negotiation, the random number A needs to be modified to generate a conflict-free cookie.

[0052] IV = (Initiator ID | Response 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 ciphertext of the previous message.

[0054] It's important to note that cookies are generally short, temporarily generated pieces of information, typically used for caching or identification, and possess a degree of unpredictability. In CBC mode, an Initiation Vector (IV) is required; each encryption operation necessitates the generation of a unique bit sequence as the initialization vector, such as... Figure 2 As shown.

[0055] The subsequent key exchange process during the session key negotiation phase is as follows: Figure 3As shown, message 1 sends a hash payload, a security association payload (which encapsulates one or more proposal payloads, and each proposal payload encapsulates one or more transformation payloads), a nonce payload, and an identifier payload to the responder. 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] Wherein, SKEYID_a_i is the pre-set authentication key material of the initiator. PRF(key, msg) is the data digest operation performed on message msg using the key key; MsgID is the message ID; Ni_b is the body of the initiator's nonce payload, i.e., a random number; SA is the security association payload with one or more proposed payloads. IDi is the initiator's identifier payload; IDr is the responder's identifier payload. 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 identifier payload to obtain the first encrypted information. That is, to use the encryption key to encrypt the transmitted information. Among them, the first hash value is encapsulated in the first hash payload and encrypted as a whole, without encrypting the hash value separately. In this way, the first phase negotiation in the IKE protocol is eliminated, and the session key negotiation is directly entered, thereby reducing the number of messages and computational overhead. Session key negotiation employs encryption and authentication keys for protection. These keys, derived from pre-set encryption and authentication key materials, respectively, ensure the 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 transmitted encrypted; only the message header is plaintext. Therefore, the plaintext message header is crucial for both parties to quickly locate the current negotiation instance. A negotiation instance contains IPSec SAs in both directions. Consequently, the cookie generation method includes the device IDs of both parties, the MsgID (message ID) for this negotiation, and a random number. Thus, the cookie generation method and its function differ from the IKE protocol.

[0058] Step S12: Send the first encrypted information to the responder so that the responder can verify the received payload based on the first hash value. After successful verification, use the responder's authentication key to calculate the second hash value corresponding to the message digest in the second hash payload, use the responder's 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. Upon receiving the first encrypted information, the responder verifies the received payload based on the first hash value. Specifically, the responder calculates the hash value corresponding to the message digest in the received payload and then verifies the received payload based on the relationship between its hash value and the first hash value. If the calculated hash value is equal to the first hash value, it indicates that the information received by the responder is complete and tamper-proof. The responder can then 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 identifier payload to the initiator. The method for calculating 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] Wherein, SKEYID_a_r is the pre-set authentication key material of the responder. PRF(key, msg) is the data digest operation performed on message msg using the key key; MsgID is the message ID; Ni_b is the body of the initiator's nonce payload, i.e., a random number; Nr_b is the body of the responder's nonce payload, i.e., a random number; SA is the security association payload with one or more proposed payloads. IDi is the initiator's identifier payload; IDr is the responder's identifier payload. Specifically, the responder verifies the received payload based on the first hash value. After successful verification, the responder calculates the second hash value corresponding to the message digest in the second hash payload using the responder's authentication key, encrypts the second hash payload, the second security association payload, the second random number payload, and the identifier 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. Then, the above-mentioned second encrypted information is sent to the initiator.

[0062] Step S13: Verify the received payload based on the second hash value. After successful verification, calculate the 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 with the initiator's encryption key to generate the third encrypted information. 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.

[0063] In this embodiment, after the responder sends the second encrypted information 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 relationship between the target hash value and the second hash value. If the two hash values ​​are the same, the verification is successful, and the initiator can then proceed to the next step of information transmission, i.e., message 3: The initiator sends a hash payload to the responder to authenticate the previous exchange. The method for calculating the message digest in the hash payload is as follows:

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

[0065] Wherein, SKEYID_a_i is the pre-set authentication key material of the initiator. PRF(key, msg) is the data digest operation performed on the message msg using the key key; MsgID is the message ID; Ni_b is the body of the initiator's nonce payload, i.e., a random number; Nr_b is the body of the responder's nonce payload, i.e., a random number. In this process, the third hash value is encapsulated in the third hash payload. 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. 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 verification method is the same as the verification method described above, and will not be repeated here. If the verification is successful, the information exchanged during the session key negotiation phase can be used for subsequent session key generation operations.

[0066] Step S14: After the responder's verification is successful, determine the session key generation material for both communicating parties, and generate a session key based on the session key generation material.

[0067] In this embodiment, after the responder's verification is successful, a first parameter is determined based on the hash values ​​of the random numbers in the initiator's first random number payload and the random numbers in the responder's second random number payload, the initiator's cookie, and the responder's cookie. A second parameter is determined 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. A target byte sequence is determined based on the second parameter, the random numbers in the first and second random number payloads, and the session protocol and security association payload identifiers negotiated from the security association payload. The target byte sequence is then used as the session key generation material for both communicating parties. According to the algorithm's required length, a first session key for encryption and a second session key for integrity verification are sequentially selected from the target byte sequence. Specifically, the session key material is defined as:

[0068] SKEYID=PRF(Hash(Ni_b|Nr_b), Initiator cookie| Response 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] In this dataset, SKEYID is the first parameter; SKEYID_d is the second parameter; KEYMAT is a byte sequence; SKEYID_a_r is the pre-set authentication key material for the responder; SKEYID_a_i is the pre-set 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 body of the initiator's nonce payload, i.e., a random number; Nr_b is the body of the responder's nonce payload, i.e., 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 payloads. Then, the session key used for encryption and the session key used for integrity verification are selected sequentially from KEYMAT according to the length required by the algorithm. The session key used for encryption is selected first, followed by the session key used for integrity verification.

[0072] When the output length of the PRF function is less than the key material length required by KEYMAT, it needs to be expanded using feedback and concatenation methods 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 results in two security associations, one inbound and one outbound. The distinct 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 Chinese national cryptographic IKE protocol implements the authentication function between the communicating parties and the negotiation of the protection key in the second phase, which is the confidentiality protection function. Although this application has shortened the first phase of the Chinese national cryptographic IKE protocol, it has not weakened the protocol's security.

[0081] Regarding the authentication function: This invention protects the interaction of three messages by generating an encryption key from pre-set encryption key material. While negotiating the working key, it also uses the authentication key corresponding to the pre-set authentication key material to implement the entity authentication method specified in Section 5.2.2 of GBT15843.2, thus realizing a secure identity authentication function.

[0082] Regarding confidentiality protection: The confidentiality of the second-phase negotiation in the Chinese national cryptographic standard IKE relies on the confidentiality of the two protection keys negotiated in the first phase, as well as the security of the algorithm and protocol design. The protection keys are actually derived from two nonce payloads encrypted using the SM2 algorithm; therefore, 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. This application eliminates the first-phase negotiation, and the confidentiality protection of the second-phase negotiation process relies on the confidentiality of the pre-built key material. Therefore, the confidentiality of the negotiation process in this application depends on the security of the pre-built key material, just as the Chinese national cryptographic standard IKE relies on the security of the SM2 private key. As long as the security of the pre-built key material is not lower than the security of the SM2 private key in the Chinese national cryptographic standard IKE, security will not be weakened. The security protection of the pre-built key material is an implementation-level consideration and will not be elaborated here. Furthermore, this application also considers security in the design of cookies, IVs, hash payloads, and session key generation methods to ensure that security is not lower than that of the Chinese national cryptographic standard IKE protocol.

[0083] In summary, the initiator of this application first generates authentication and encryption keys for both communicating parties. Based on the initiator's authentication key, it calculates a first hash value corresponding to the message digest in the first hash payload. Then, it uses the initiator's encryption key to encrypt the first hash payload, the first security association payload, the first random number payload, and the identifier payload to obtain the first encrypted information. The first hash value is encapsulated within the first hash payload. The first encrypted information is then sent to the responder, allowing the responder to verify the received payload based on the first hash value. Upon successful verification, the responder uses its authentication key to calculate a second hash value corresponding to the message digest in the second hash payload. Finally, the responder uses its encryption key to encrypt the second hash payload, the second security association payload, and the second random number payload. The method includes: sending the corresponding second encrypted information to the initiator, whereby the second hash value is encapsulated within the second hash payload; verifying the received payload based on the second hash value; calculating the 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 with 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 within the third hash payload; and determining the session key generation material for both communicating parties after the responder's verification, generating a session key based on the session key generation material. It is evident that this application eliminates the first-phase negotiation in the IKE protocol, directly entering session key negotiation, thereby reducing the number of messages and computational overhead. Session key negotiation is protected by encryption and authentication keys, which are generated using pre-set encryption and authentication key materials to achieve confidentiality protection, integrity protection, and authentication functions for the negotiated messages. In this way, this application does not require the introduction of computationally intensive algorithms, making it more suitable for scenarios where cryptographic chips have limited processing power or where power consumption is limited. Furthermore, it requires fewer messages to be sent during key negotiation, making it better suited for scenarios with limited communication bandwidth, high negotiation latency requirements, low chip processing power for the protocol, and power consumption constraints.

[0084] As described in the previous embodiment, 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 utilizes a key management system to generate encryption key material and authentication key material; the authentication key material is then determined as the authentication key; a hash operation is performed on the initiator ID, responder ID, message ID, and a random number to obtain the cookies corresponding to each of the communicating parties; and the encryption key is generated using the initiator cookie, responder cookie, the message ID, and the encryption key material. The specific generation process of the encryption key and authentication key will be described in detail below.

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

[0086] Messages 1, 2, and 3, except for their plaintext headers, have their entire payload encrypted using 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, as detailed below:

[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 obtained by taking the preset encryption key material SKEYID_e_i when the initiator encrypts the message, and by taking SKEYID_e_r when the responder encrypts the message.

[0091] Then, the first 128 bits of SKEYID_m_2 are taken as the message encryption key SKEYID_m_e in the payload of the encrypted message. It 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] In all three equations, the initiator's cookie and the responder's cookie are taken from the values ​​in the message header to be encrypted. That is, in message 1, the responder's cookie is always 0, while in message 3, the responder's cookie is not 0. Therefore, the derived encryption keys corresponding to the three messages are different.

[0093] Here it is specifically stipulated that: the pre-set shared encryption key material and the authentication key material are both generated by the security management system, are independent of each other and have no derivative relationship, and must have sufficient randomness; the length of the pre-set encryption key material SKEYID_e must be at least 2 bytes greater than the length of the SM4 key (16 bytes).

[0094] In this way, the pre-set 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 pre-set protection key material, and it is stipulated that the length of the encryption key material input to the key derivation formula is 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 a one-time pad. The information for generating the authentication payload includes information that is not transmitted in plaintext, and the authentication payload is always encrypted, which enhances the security of the protocol.

[0095] See Figure 4 As shown in the figure, an embodiment of the present invention discloses a communication session key negotiation device, applied to the initiator, comprising:

[0096] The first encryption module 11 is used to generate authentication keys and encryption keys for both communicating parties based on preset authentication key materials and encryption key materials, calculate the 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 identifier payload using the initiator's encryption key to obtain the first encrypted information; wherein, the first hash value is encapsulated in the first hash payload;

[0097] The second encryption module 12 is used to send the first encrypted information to the responder, so that the responder can verify the received payload based on the first hash value. After successful verification, the responder uses the second hash value corresponding to the message digest in the second hash payload calculated using the responder's authentication key, and uses the responder's encryption key to encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload, and sends the corresponding second encrypted information to the initiator; wherein, the second hash value is encapsulated in the second hash payload;

[0098] The third encryption module 13 is used to verify the received payload based on the second hash value. After successful verification, it calculates the third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key, encrypts the third hash payload with the initiator's encryption key, generates 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 third hash value is encapsulated in the third hash payload.

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

[0100] The initiator first generates authentication and encryption keys for both communicating parties. Based on the initiator's authentication key, it calculates a first hash value corresponding to the message digest in the first hash payload. Then, using the initiator's encryption key, it encrypts the first hash payload, the first security association payload, the first random number payload, and the identifier payload to obtain the first encrypted information. The first hash value is encapsulated within the first hash payload. The first encrypted information is sent to the responder, who verifies the received payload based on the first hash value. Upon successful verification, the responder calculates a second hash value corresponding to the message digest in the second hash payload using its authentication key. Finally, the responder encrypts the second hash payload, the second security association payload, the second random number payload, and the identifier payload using its encryption key. The first-phase negotiation in the IKE protocol is eliminated, and the corresponding second encrypted information is sent to the initiator. The second hash value is encapsulated within the second hash payload. The received payload is verified based on the second hash value. Upon successful verification, 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 then encrypted using the initiator's encryption key to generate third encrypted information, which is sent to the responder. The responder then verifies the received third hash payload based on the third hash value. The third hash value is encapsulated within the third hash payload. After successful verification by the responder, the session key generation materials for both communicating parties are determined, and a session key is generated based on these materials. Therefore, this application eliminates the first-phase negotiation in the IKE protocol, directly proceeding to session key negotiation, thereby reducing the number of messages and computational overhead. Session key negotiation is protected using encryption and authentication keys. The encryption and authentication keys generated from pre-set encryption and authentication key materials respectively achieve confidentiality protection, integrity protection, and authentication functions for the negotiated messages. In this way, this application does not require the introduction of computationally intensive algorithms, making it more suitable for scenarios where cryptographic chips have limited processing power or where power consumption is limited. Furthermore, it requires fewer messages to be sent during key negotiation, making it better suited for scenarios with limited communication bandwidth, high negotiation latency requirements, low chip processing power for the protocol, and power consumption constraints.

[0101] In some specific embodiments, the apparatus 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 a hash operation on the initiator ID, responder ID, message ID, and random number to obtain the cookies corresponding to each of the communicating parties; and generate the encryption key using the initiator cookie, responder cookie, message ID, and encryption key material.

[0102] In some specific embodiments, the first encryption module 11 can be used to establish a first mapping relationship between the communication device IP address 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 the encryption key material of both parties, and the authentication key material and the encryption key material are generated based on the authentication key material and the encryption key material.

[0103] In some specific embodiments, the second encryption module 12 can be used to calculate the target hash value corresponding to the message digest in the received payload, and to verify the received payload based on the 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 values ​​of the random numbers in the initiator's first random number payload and the random numbers 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 numbers in the first random number payload, the random numbers in the second random number payload, and the number of session protocol and security association payload identifiers negotiated from the security association payload; and determine the target byte sequence as the session key generation material for both communicating parties.

[0105] In some specific embodiments, the session key generation module 14 can be used to 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, embodiments of this application also disclose an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0107] Figure 5This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, 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 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the communication session key negotiation method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic 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 external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and 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 operating system 221, 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 various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the communication session key negotiation method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0111] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed communication session key negotiation method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing 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 other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0113] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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 can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, 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" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0116] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A communication session key negotiation method, characterized in that, Applied to the initiator, including: The authentication key and encryption key of the two communicating parties are generated based on the preset authentication key material and encryption key material. The first hash value corresponding to the message digest in the first hash payload is calculated based on the initiator's authentication key. The first hash payload, the first security association payload, the first random number payload and the identifier payload are encrypted using the initiator's encryption key to obtain the first encrypted information. The first hash value is encapsulated in the first hash payload. The first encrypted information is sent to the responder so that the responder can verify the received payload based on the first hash value. After successful verification, the responder uses the responder's authentication key to calculate the second hash value corresponding to the message digest in the second hash payload. The responder uses the responder's encryption key to encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload. The corresponding second encrypted information is then sent to the initiator. The second hash value is encapsulated in the second hash payload. The received payload is verified based on the second hash value. After successful verification, 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 then encrypted using the initiator's encryption key to generate the third encrypted information. The third encrypted information is then 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 within the third hash payload. After the responder's verification is successful, the session key generation material for both communicating parties is determined, and a session key is generated based on the session key generation material.

2. The communication session key negotiation method according to claim 1, characterized in that, Before generating the authentication key and encryption key for both communicating parties based on the preset authentication key material and encryption key material, the process also includes: Use the key management system to generate encryption key materials and authentication key materials; The authentication key material is determined as the authentication key; Perform a hash operation on the initiator ID, responder ID, message ID, and random number to obtain the cookies corresponding to each of the communicating parties; The encryption key is generated 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, characterized in that, The generation of authentication and encryption keys for both communicating parties based on pre-set authentication and encryption key materials includes: Establish a first mapping relationship between the communication device IP address 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 authentication key material and encryption key material of both communicating parties are queried using the IP address of the communication device, and the authentication key material and encryption key material of both communicating 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, characterized in that, The message digest of the first hash payload includes the initiator cookie, the message ID, the first random number payload, the first security association payload, and the identifier payload including the initiator identifier payload and the responder identifier payload; the message digest of 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 identifier payload including the initiator identifier payload and the responder identifier payload; the message digest of 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, characterized in that, The verification of the received payload based on the second hash value includes: Calculate the target hash value corresponding to the message digest in the received payload, and verify the received payload based on the size 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 material for generating the session key for both communicating parties includes: The first parameter is determined based on the hash values ​​of the random numbers in the first random number payload of the initiator and the second random number payload of the responder, as well as the initiator's cookie and the responder's 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 number negotiated from the security association payload; The target byte sequence is determined as the session key generation material for both communicating parties.

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

8. A communication session key negotiation device, characterized in that, Applied to the initiator, including: The first encryption module is used to generate authentication keys and encryption keys for both communicating parties based on the pre-set authentication key material and encryption key material, calculate the 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 identifier payload using the initiator's encryption key to obtain the first encrypted information; wherein, the first hash value is encapsulated in the first hash payload; The second encryption module is used to send the first encrypted information to the responder, so that the responder can verify the received payload based on the first hash value. After successful verification, the responder uses the second hash value corresponding to the message digest in the second hash payload calculated using the responder's authentication key, and uses the responder's encryption key to encrypt the second hash payload, the second security association payload, the second random number payload, and the identification payload, and sends the corresponding second encrypted information to the initiator; wherein, the second hash value is encapsulated in the second hash payload; The third encryption module is used to verify the received payload based on the second hash value. After successful verification, it calculates the third hash value corresponding to the message digest in the third hash payload based on the initiator's authentication key, encrypts the third hash payload with the initiator's encryption key, generates 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 third hash value is encapsulated in the third hash payload. The session key generation module is used to determine the session key generation materials of both communicating parties after the responder has passed the verification, and to 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 for executing the computer program to implement the communication session key negotiation method as described in 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, it implements the communication session key negotiation method as described in any one of claims 1 to 7.

Images