A method, apparatus, medium and electronic device for key agreement

Abstract

Embodiments of the present application provide a key agreement method, device, medium and electronic equipment. The method comprises: receiving first key agreement information sent by a peer, wherein the first key agreement information comprises a first identity, a first random number, a first encryption public key and first temporary public key information; obtaining second key agreement information of a local end, wherein the second key agreement information comprises a second identity, a second random number, a second encryption public key, a second encryption private key, a second temporary private key and second temporary public key information; and generating at least one key according to the first key agreement information and the second key agreement information. Some embodiments of the present application provide a method for generating at least one key containing a session key according to random numbers, identities, and temporary public keys of both communication parties, which improves the security of the key agreement process.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of key processing, and in particular, the embodiments of the present application relate to a method and device for key agreement, a medium and an electronic device. BACKGROUND

[0002] The prior art uses the DH algorithm for key agreement, and in the process of using the algorithm for key agreement, as shown in Figure 1 , the process involves the transmission process of the following information:

[0003] Message 1 HDR contains a security parameter index (SPI), a version number and various flags. SAi1 payload indicates the encryption algorithm of the IKE SA supported by the initiator. KEi payload sends the Diffie-Hellman value of the initiator. Ni is the random number of the initiator.

[0004] Message 2 The responder selects an encryption suite from the options provided by the initiator and expresses the selection in the SAr1 payload, completes the Diffie-Hellman exchange with the KEr payload, and sends its random number in the Nr payload.

[0005] After the negotiation of the first two messages, each party can generate SKEYSEED (basic key parameter), from which all the keys of the IKE SA are derived. In addition to the message header, the subsequent messages are encrypted and integrity-protected as a whole. The keys used for encryption and integrity protection are derived from SKEYSEED, called SK_e (encryption) and SK_a (authentication, also known as integrity protection).

[0006] Message 3 The initiator uses the IDi payload to declare its identity, prove knowledge of the secret corresponding to IDi, and integrity-protect the contents of the first message using the AUTH payload. It can also send its certificate in the CERT payload and send its list of trust anchors in the CERTREQ payload. If any CERT payload is included, the first certificate provided must contain the public key used to verify the AUTH field.

[0007] Message 4 The responder uses the IDr payload to declare its identity, optionally sends one or more certificates (again using a certificate that contains the public key used to verify the first listed AUTH), verifies its identity and protects the integrity of the second message using the AUTH payload, and completes the negotiation of a child SA using additional fields described below in the CREATE_CHILD_SA exchange.

[0008] However Figure 1 The key agreement process of the prior art has security risks, so how to improve the security of the key agreement process has become a technical problem to be solved. Summary of the Invention

[0009] The purpose of this application is to provide a method, apparatus, medium, and electronic device for key negotiation, which improves the security of the key negotiation process compared with related technical solutions.

[0010] In a first aspect, embodiments of this application provide a key negotiation method, the method comprising: receiving first key negotiation information sent by a peer, wherein the first key negotiation information includes: a first identity identifier, a first random number, a first encrypted public key, and first temporary public key information; obtaining second key negotiation information of the local end, wherein the second key negotiation information includes: a second identity identifier, a second random number, a second encrypted public key, a second encrypted private key, a second temporary private key, and second temporary public key information; and generating at least one key based on the first key negotiation information and the second key negotiation information.

[0011] Some embodiments of this application provide a method for generating at least one key containing a session key based on the random numbers, identity information, and temporary public keys of the communicating parties, thereby improving the security of the key negotiation process.

[0012] In some embodiments, generating at least one key based on the first key negotiation information and the second key negotiation information includes: obtaining a basic key parameter SKEYID based on the first key negotiation information, the second key negotiation information and the SM2 algorithm; and obtaining at least one derived key based on the basic key parameter SKEYID, wherein the at least one derived key includes a session key.

[0013] Some embodiments of this application calculate basic key parameters based on the SM2 algorithm and obtain at least one derived key parameter based on the basic key parameters, thereby improving the confidentiality of the obtained password.

[0014] In some embodiments, the first key negotiation information is used to carry a first ISAKMP header and the peer's first cookie, and the second key negotiation information is used to carry a second ISAKMP header and the local second cookie. The step of obtaining at least one derived key based on the basic key parameter SKEYID includes: concatenating the first cookie, the second cookie, and a first value to obtain a first message; and performing a digest operation on the first message using the basic key parameter to obtain the session key.

[0015] Some embodiments of this application obtain the session key based on the cookie in the ISAKMP header carried in the header, thereby improving the confidentiality of the obtained key.

[0016] In some embodiments, obtaining at least one derived key based on the basic key parameter SKEYID includes: concatenating the session key, the first cookie, the second cookie, and the second value to obtain a second message; and performing a digest operation on the second message using the basic key parameter to obtain a first derived key, wherein the first derived key is used to verify message integrity and data source identity.

[0017] Some embodiments of this application also obtain key information based on the first cookie, the second cookie, and basic key parameters to ensure the integrity of the verification message and the identity of the data source during the negotiation process, thereby improving the security of the entire negotiation process before the establishment of a session.

[0018] In some embodiments, obtaining at least one derived key based on the basic key parameter SKEYID includes: concatenating the first derived key, the first cookie, the second cookie, and the third value to obtain a third message; and performing a digest operation on the third message using the basic key parameter to obtain a second derived key, wherein the second derived key is used to protect message confidentiality.

[0019] Some embodiments of this application also use the first cookie, the second cookie, the first derived key, and the basic key parameters to ensure message confidentiality during the negotiation process and improve the security of the entire negotiation process before the session is established.

[0020] In some embodiments, the second encrypted public key, the second encrypted private key, the second temporary private key, and the second temporary public key information are obtained using the SM2 encryption algorithm.

[0021] Some embodiments of this application obtain the basic data for generating keys using the SM2 algorithm.

[0022] In some embodiments, the first key negotiation information further includes a first signing certificate and a first encryption certificate, wherein, before generating at least one key based on the first key negotiation information and the second key negotiation information, the method further includes: confirming that the first signing certificate and the first encryption certificate have passed security verification.

[0023] Some embodiments of this application employ dual-certificate verification using national cryptographic standards to ensure the security of the key negotiation process.

[0024] In some embodiments, the first signing certificate and the first encryption certificate are obtained from a CA authentication provider.

[0025] It should be noted that CA stands for Certification Authority. A CA is an authority responsible for issuing, authenticating, and managing issued certificates.

[0026] In some embodiments, the first key negotiation information is used to carry multiple available encryption algorithms and verification algorithms, and the second key negotiation information is used to carry a target algorithm selected from the multiple encryption algorithms and the verification algorithms respectively; or, the second key negotiation information is used to carry multiple available encryption algorithms and verification algorithms, and the first key negotiation information is used to carry a target algorithm selected from the multiple encryption algorithms and the verification algorithms respectively.

[0027] Some embodiments of this application determine the encryption algorithm and verification algorithm through negotiation between the parties, thereby improving the versatility of the technical solution.

[0028] In some embodiments, the peer is the initiator and the local end is the responder corresponding to the initiator, or the local end is the initiator and the peer is the responder corresponding to the initiator.

[0029] Secondly, some embodiments of this application provide a method for negotiating IPsec information, the method comprising: establishing an IPsec-based tunnel by negotiating at least one key obtained according to any embodiment of the first aspect.

[0030] Thirdly, some embodiments of this application provide a method for a session, the method comprising: completing a session process between the local end and the peer end based on a session key obtained as in any embodiment of the first aspect.

[0031] Fourthly, some embodiments of this application provide a key negotiation apparatus, the apparatus comprising: a receiving module configured to receive first key negotiation information sent by a peer, wherein the first key negotiation information includes: a first identity identifier, a first random number, a first encrypted public key, and first temporary public key information; a negotiation information acquisition module configured to acquire second key negotiation information of the local end, wherein the second key negotiation information includes: a second identity identifier, a second random number, a second encrypted public key, a second encrypted private key, a second temporary private key, and second temporary public key information; and a key generation module configured to generate at least one key based on the first key negotiation information and the second key negotiation information.

[0032] Fifthly, some embodiments of this application provide a computer storage medium having a computer program stored thereon, which, when executed by a processor, can implement the method described in any embodiment of the first aspect.

[0033] In a sixth aspect, some embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement the method as described in any embodiment of the first aspect. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 A flowchart illustrating the key negotiation method provided for related technologies;

[0036] Figure 2 One of the flowcharts for the key negotiation method provided in the embodiments of this application;

[0037] Figure 3 A second flowchart illustrating the key negotiation method provided in this application embodiment;

[0038] Figure 4 The third flowchart of the key negotiation method provided in the embodiments of this application;

[0039] Figure 5 The fourth flowchart of the key negotiation method provided in the embodiments of this application;

[0040] Figure 6 A block diagram of the key negotiation apparatus provided in the embodiments of this application;

[0041] Figure 7 This is a schematic diagram illustrating the composition of an electronic device provided in an embodiment of this application. Detailed Implementation

[0042] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0043] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0044] The following section first explains the meaning of some English abbreviations in this application, as well as the structure of the relevant loads.

[0045] HDR (header): An ISAKMP (Internet Security Association and Key Management Protocol) header.

[0046] HDR*: Indicates that the payload following the ISAKMP header is encrypted.

[0047] SA (Security Association): A security association payload with one or more proposed payloads.

[0048] IDi: The initiator's identifier payload.

[0049] IDr: The identifier payload of the responder.

[0050] HASHi: Hash payload of the initiator.

[0051] HASHr: Hash load of the responder.

[0052] CERT_sig_r: Signature certificate payload.

[0053] CERT_enc_r: Encrypted certificate payload.

[0054] Ni: The initiator's nonce payload.

[0055] Nr: The nonce load of the responder.

[0056] Payload Type Body, i.e. the payload without ISAKMP header.

[0057] pub_i: Initiator public key.

[0058] pub_r: Responder public key.

[0059] prv_i: Initiator private key.

[0060] prv_r: Responder private key.

[0061] pub_temp_i: Initiator temporary public key.

[0062] pub_temp_r: Responder temporary public key.

[0063] prv_temp_i: Initiator temporary private key.

[0064] prv_temp_r: Responder temporary private key.

[0065] klen: Bit length of the key data to be output.

[0066] KEY: Key data with bit length klen.

[0067] TSi: Traffic selector initiator, each traffic selector consists of an address range, a port range, and an IP protocol ID.

[0068] TSr: Traffic selector responder

[0069] CKY-I: Initiator cookie in ISAKMP header.

[0070] CKY-R: Responder cookie in ISAKMP header.

[0071] x | y: Concatenation of x and y.

[0072] [x]: x is optional.

[0073] Asymmetric_Encrypt(msg, pub_key): Using asymmetric algorithm Asymmetric, pub_key as the key to encrypt input information msg_b, its output is the general payload header and ciphertext of msg concatenated. For example, RSA_Encrypt(Ski, pub_key) means using RSA algorithm, using public key pub_key to encrypt Ski_b, its output is the general payload header and ciphertext of Ski concatenated.

[0074] Asymmetric_Sign(msg,priv_key): use asymmetric algorithm Asymmetric to sign msg with priv_key as the key.

[0075] Symmetric_Encrypt(msg,key): use symmetric algorithm Symmetric to encrypt input information msg_b with key as the key, and its output is the concatenation of the generic payload header of msg and the ciphertext.

[0076] SM1_Encrypt(Ni, key) means using SM1 algorithm to encrypt Ni_b with key as the key, and its output is the concatenation of the generic payload header of Ni and the ciphertext.

[0077] Hash(msg): use cryptographic hash algorithm to perform data digest operation on msg.

[0078] PRF(key, msg): use key to perform data digest operation on message msg.

[0079] The format of the above related messages of the present application is described as follows.

[0080] First, the message header HDR.

[0081] The key exchange protocol message is composed of a fixed-length message header and an indefinite number of payloads. The message header contains the information necessary for the protocol to maintain the state and process the payloads.

[0082] Table 1 ISAKMP header format

[0083]

[0084] Initiator cookie: this field is a unique 8-byte bit string randomly generated by the initiator.

[0085] Responder cookie: this field is a unique 8-byte bit string randomly generated by the responder.

[0086] Cookie generation method:

[0087] It is a fast hash (for example, MD5) on the IP source and destination addresses, UDP source and destination ports, and a locally generated secret random number. ISAKMP requires the cookie to be unique for each SA authority to help prevent replay attacks, so data and time must be added to the information being hashed. The generated cookie is placed in the ISAKMP header initiator and responder cookie fields. These fields are 8 bytes long, so the generated cookie must also be 8 bytes long.

[0088] Refer specifically to RFC 2408 2.5.3 for generation requirements.

[0089] Next Payload: This field is one octet and describes the type of the first payload in the message. The payload types are defined in the following table 2:

[0090] Table 2. Payload Type Definitions

[0091]

[0092]

[0093] Version Number: This field is one octet, where the first 3 bits represent the major version number and the next 4 bits represent the minor version number. This specification defines the major version number to be 1 and the minor version number to be 1.

[0094] Exchange Type: This field is one octet and describes the type of exchange that makes up the message. The exchange types are defined in table 3:

[0095] Table 3. Exchange Type Definitions

[0096] Exchange Type Assigned Value None Base Identity protection Authentication only Informational Future use DOI specific use Private use

[0097] Flags: This field, 1 byte in length, specifies the options set for the key exchange protocol. Currently, the first 3 bits of this field are used; the other bits are set to 0 before transmission. The specific definition is as follows:

[0098] Encryption Bit: This is the least significant bit in the flags field. When this bit is set to 1, all payloads following this header are encrypted using the cryptographic algorithm specified in ISAKMP SA. When this bit is set to 0, the payload is not encrypted.

[0099] Submission bit: This is the second bit of the flag field.

[0100] Distinguishing bit only: This is the third bit of the flag field, and its value is 0 in this specification.

[0101] Message ID: This field is 4 bytes long.

[0102] Length: This field is 4 bytes long, indicating the total length of the message, including the header and payload.

[0103] Second, universal load head

[0104] Each load begins with a universal load header. The universal load header defines the load boundaries, allowing different loads to be connected. The definition of the universal load header is shown in Table 4:

[0105] Table 4

[0106] Next payload Reserved Payload length

[0107] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0108] Reserved: This field is 1 byte long and has a value of 0.

[0109] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0110] Third, Security Alliance payload

[0111] The Security Association payload is used to negotiate the Security Association (SA) and specifies the DOI (Domain of Interpretation) upon which the negotiation is based. The format of the Security Association depends on the DOI it uses, and the type value of this payload is 1. The format of the Security Association payload is shown in Table 5.

[0112] Table 5 Security Alliance Payload Format

[0113]

[0114] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0115] Reserved: This field is 1 byte long and has a value of 0.

[0116] Payload Length: This field is 2 bytes long and indicates the length of the entire security association payload in bytes. The calculation scope includes the SA payload, all proposed payloads, and all transformation payloads related to the proposed security association.

[0117] Interpretation Field DOI: This field is 4 bytes long and has an unsigned integer value. It specifies the DOI on which the negotiation is based. The value of this field is 1.

[0118] Scenario: This field, 4 bytes in length, indicates the circumstances under which the negotiation occurred, used to determine the required security services. The definition is as follows:

[0119] SIT_IDENTITY_ONLY: Its value is 1. This indicates that the SA will be identified by source identification information in an associated identification payload.

[0120] SIT_SECRECY: Its value is 2. It indicates that SA is negotiating in a secret environment that requires tagged authentication.

[0121] SIT_INTEGRITY: Its value is 4. This indicates that SA is negotiating in a tagged integrity environment.

[0122] This specification uses the SIT_IDENTITY_ONLY case by default.

[0123] Fourth, recommended load.

[0124] The suggested payload is used by the initiator of the key exchange to inform the responder of its preferred security protocol and the relevant security mechanisms it hopes the SA will adopt in the negotiation. The type value of this payload is 2. The format of the suggested payload is shown in Table 6.

[0125] Table 6 Recommended Load Format

[0126]

[0127] Next payload: This field is 1 byte long. If there is a suggested payload following, its value is 2; otherwise, it should be 0.

[0128] Reserved: This field is 1 byte long and has a value of 0.

[0129] Load Length: This field is 2 bytes long and indicates the length of the entire recommended load in bytes. The calculation scope includes the general load header, the recommended load, and all transformation loads related to this recommendation. This length is only used to indicate the length of the recommended load.

[0130] Recommendation Number: This field is 1 byte long and indicates the recommendation number of this recommendation payload. Multiple recommendations with the same recommendation number indicate a logical AND relationship, while different numbers indicate a logical OR relationship. Monotonically increasing recommendation numbers indicate the order of priority for the recommendations; smaller recommendation numbers have higher priority.

[0131] Protocol ID: This field is 1 byte long and identifies the protocol identifier. The definition of the protocol identifier is shown in Table 7:

[0132] Table 7 Definition of Protocol Identifiers

[0133] Protocol identifier Description Value RESERVED Unassigned PROTO_ISAKMP Protocol identifier for ISAKMP PROTO_IPSec_AH Protocol identifier for AH PROTO_IPSec_ESP Protocol identifier for ESP PROTO_IPCOMP Protocol identifier for IP compression

[0134] SPI Length: This field is 1 byte long, indicating the length of the SPI in bytes.

[0135] Transformation Count: This field is 1 byte long and indicates the recommended number of transformation payloads.

[0136] Variable-length SPI: Its content is a random number generated by the proposer of the suggestion.

[0137] Fifth, change the load.

[0138] The transformation payload is used by the initiator of key exchange to inform the responder that different security mechanisms are provided for a specified protocol. The type value of this payload is 3. The format of the transformation payload is shown in Table 8.

[0139] Table 8 Transformed Load Format

[0140]

[0141] Next payload: This field is 1 byte long. If there is a transformation payload following, its value is 3; otherwise, it should be 0.

[0142] Reserved: This field is 1 byte long and has a value of 0.

[0143] Load Length: This field is 2 bytes long and indicates the length of this transformed load in bytes. The calculation scope includes the general load header, transformed load, and all SA attribute loads.

[0144] Transformation Number: This field is 1 byte long and indicates the transformation number of this transformation load. The monotonically increasing transformation number indicates the priority order of transformation selection, with smaller transformation numbers indicating higher priority.

[0145] Transformation ID: This field is 1 byte long and indicates the transformation identifier of the proposed protocol.

[0146] Reserved 2: This field is 2 bytes long and has a value of 0.

[0147] SA attribute: The length of this field is variable and indicates the SA attribute of this transformation.

[0148] Sixth, SA attribute load

[0149] SA attribute loads can only be used after load transformation and do not have a general load header. The data structure used to represent SA attributes has a type value of 14. The format of the SA attribute load is shown in Table 9.

[0150] Table 9 SA Attribute Load Format

[0151]

[0152] Attribute Type: This field is 2 bytes long and indicates the attribute type. If the most significant bit (bit 0) of this field is 0, the attribute value is variable-length, and the payload has 3 fields: attribute type, attribute length, and attribute value. If the most significant bit of the attribute type is 1, the attribute value is fixed-length, and the payload has only 2 fields: attribute type and attribute value. If the attribute type is variable-length, and the attribute value can be represented in two bytes, then the variable-length attribute can be represented using a fixed-length attribute.

[0153] Attribute value: If this field is fixed-length, its length is 2 bytes. If it is variable-length, its length is specified by the attribute length field.

[0154] Attribute length: When the attribute value is variable length, this field indicates the length of the attribute value.

[0155] Seventh, Identification payload (specific definition and configurable types of ID payload)

[0156] The identification payload is used by the communicating parties to exchange identity information. This information is used to verify the identities of both parties, and the type value of this payload is 5. The format of the identification payload is shown in Table 10:

[0157] Table 10 Identifier Load Format

[0158]

[0159] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0160] Reserved: This field is 1 byte long and has a value of 0.

[0161] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0162] Identifier Type: This field is 1 byte long and indicates the type of identity information in the identifier data field. The definition of the identifier type is shown in Table 11:

[0163] Table 11 Definition of Identifier Types

[0164] ID Type Description Value RESERVED Unassigned ID_IPv4_ADDR A single 4-octet IPv4 address ID_FQDN Fully qualified domain name string ID_USER_FQDN Fully qualified user name string ID_IPv4_ADDR_SUBNET IPv4 address with 4-octet subnet mask ID_IPv6_ADDR A single 16-octet IPv6 address ID_IPv6_ADDR_SUBNET An IPv6 address with 16-octet subnet mask ID_IPv4_ADDR_RANGE An IPv4 address range ID_IPv6_ADDR_RANGE An IPv6 address range ID_DER_ASN1_DN An ASN.1 X.500 Distinguished Name string ID_DER_ASN1_GN An ASN.1 X.500 Group Name string ID_KEY_ID Byte stream used to convey vendor specific information

[0165] Protocol ID: This field is 1 byte long and indicates the upper-layer protocol number of an IP protocol.

[0166] Port: This field is 2 bytes long and indicates the port of an upper-layer protocol.

[0167] Identifier data: This field is variable length and indicates the identifier information corresponding to the ID type field.

[0168] Eighth, certificate payload

[0169] The certificate payload is used by the communicating parties to exchange certificates and certificate-related information. The type value of this payload is 6.

[0170] The format of the certificate payload is shown in Table 12:

[0171] Table 12 Certificate Payload Format

[0172]

[0173] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0174] Reserved: This field is 1 byte long and has a value of 0.

[0175] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0176] Certificate Encoding: This field is 1 byte long and indicates the certificate encoding type of the certificate data field.

[0177] Certificate data: This field is a variable-length field that indicates the certificate.

[0178] Ninth, Hash Load

[0179] The hash payload contains data generated by the cryptographic hash algorithm selected during the SA negotiation process, and its type value is 8. The format of the hash payload is shown in Table 13:

[0180] Table 13 Hash Load Format

[0181]

[0182] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0183] Reserved: This field is 1 byte long and has a value of 0.

[0184] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0185] Hash data: This field has a variable length and its content is data generated by a cryptographic hash algorithm.

[0186] Tenth, signature payload

[0187] The signature payload contains data generated by the digital signature algorithm during the SA negotiation process, and its type value is 9. The format of the signature payload is shown in Table 14:

[0188] Table 14 Signature Payload Format

[0189]

[0190] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0191] Reserved: This field is 1 byte long and has a value of 0.

[0192] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0193] Signature data: This field has a variable length and its content is the data generated by the signature algorithm.

[0194] Eleventh, Nonce Load

[0195] The Nonce payload contains random data used to protect exchanged data, and its type value is 10. The format of the Nonce payload is shown in Table 15.

[0196] Table 15 Nonce Load Format

[0197]

[0198] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0199] Reserved: This field is 1 byte long and has a value of 0.

[0200] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0201] Nonce data: This field has a variable length and contains random numbers.

[0202] Twelfth, notify the load

[0203] The notification payload is used to transmit notification data. The type value of this payload is 11, and the format of the notification payload is shown in Table 16.

[0204] Table 16 Notification Load Format

[0205]

[0206] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0207] Reserved: This field is 1 byte long and has a value of 0.

[0208] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0209] Interpreted Domain (DOI): This field is 4 bytes long and has a value of 1.

[0210] Protocol ID: This field is 1 byte long and identifies the protocol identifier. The definition of the protocol identifier is shown in Table 3.

[0211] SPI Length: This field is 1 byte long, indicating the SPI length in bytes. Notification Message Type: This field is 2 bytes long, indicating the notification message type. Error types for notification messages are shown in Table 17, and status types are shown in Table 18.

[0212] Table 17 Status Types of Notification Messages

[0213]

[0214]

[0215] Table 18 Status Types of Notification Messages

[0216] Notification Type Value Connected Reserved (future use) DOI specific encoding Private (future use) Reserved (future use)

[0217] SPI: Its content is the SPI value in the receiver's suggested payload.

[0218] Notification data: This field is variable-length and is used to transmit notification data corresponding to the notification message type.

[0219] Thirteenth, delete the payload

[0220] The delete payload is used to notify the other party that a certain SA has been cancelled. The type value of this payload is 12. The format of the delete payload is shown in Table 19:

[0221] Table 19 Deleted Load Format

[0222]

[0223] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0224] Reserved: This field is 1 byte long and has a value of 0.

[0225] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0226] Interpreted Domain (DOI): This field is 4 bytes long and has a value of 1.

[0227] Protocol ID: This field is 1 byte long and indicates the protocol identifier of the SA to be deleted. The definition of the protocol identifier is shown in Table 3.

[0228] SPI Length: This field is 1 byte long and indicates the length of the SPI in bytes. SPI Number: This field is 2 bytes long and indicates the number of SPIs included in this payload. Security Parameter Index (SPI): This field is variable length and indicates the SPIs for which the SA has been removed. The length of this field is determined by the values ​​of the SPI Length and SPI Number fields.

[0229] Thirteenth, Vendor ID payload

[0230] The vendor ID payload is used to transmit vendor-defined constants; the type value for this payload is 13. The format of the vendor ID payload is shown in Table 20.

[0231] Table 20 Manufacturer ID Payload Format

[0232]

[0233] Next payload: This field, 1 byte in length, identifies the type of the next payload after this one. If the current payload is the last one, this field will be set to 0. Payload types are defined in Table 1.

[0234] Reserved: This field is 1 byte long and has a value of 0.

[0235] Payload Length: This field is 2 bytes long and indicates the total payload length, including the general payload header, in bytes.

[0236] Vendor ID (VID): This field is variable-length and contains a hash value of the vendor ID string.

[0237] Fourteenth, Authentication Payload

[0238] The authentication payload (represented by AUTH) contains the data used for authentication. The authentication payload is defined in Table 21 below:

[0239] Table 21

[0240]

[0241] Authentication method (1 byte): Specifies the authentication method; its value is defined as:

[0242] RSA digital signature

[0243] SM2 digital signature

[0244] DS Digital Signature

[0245] Shared key

[0246] Authentication data (variable length): Authentication data includes all data except for the ISAKMP header.

[0247] Fifteenth, flow rate selector load

[0248] Peers are allowed to identify the information flows that IPSEC security services need to process. The payload consists of an IKE generic payload header and a single traffic selector, as defined in Table 22 below:

[0249] Table 22

[0250]

[0251] TS number: The number of flow selectors

[0252] TS (Variable Length): Flow selector, one or more flow selectors

[0253] Fifteenth, flow selectors, as shown in Table 23 below.

[0254] Table 23

[0255]

[0256] TS type (1 byte): Specifies the type of the flow selector, see Table 16 for details.

[0257] IP Protocol ID (I-byte): Specifies the ID value of the associated IP protocol. An ID value of 0 indicates that the traffic selector is protocol-independent.

[0258] Selector Length: Specifies the length of the traffic selector field, including the header. Starting Port (2 bytes): Specifies the minimum port number allowed by the traffic selector. This field must be set to 0 for protocols that do not define a port number or allow all ports.

[0259] End Port (2 bytes): Specifies the maximum port number allowed by the traffic selector. For protocols that do not define a port number or allow all ports, this field must be set to 65535.

[0260] Starting address: The smallest address contained in the traffic selector (length is determined by the Ts type).

[0261] End address: The maximum address contained in the traffic selector

[0262] Please refer to Figure 2 , Figure 2 A key negotiation method according to some embodiments of this application includes: S101, receiving first key negotiation information sent by a peer, wherein the first key negotiation information includes: a first identity identifier, a first random number, a first encrypted public key, and first temporary public key information; S102, obtaining second key negotiation information from the local end, wherein the second key negotiation information includes: a second identity identifier, a second random number, a second encrypted public key, a second encrypted private key, a second temporary private key, and second temporary public key information; S103, generating at least one key based on the first key negotiation information and the second key negotiation information.

[0263] Some embodiments of this application provide a method for generating at least one key containing a session key based on the random numbers, identity information, and temporary public keys of the communicating parties, thereby improving the security of the key negotiation process.

[0264] The implementation process of S103 is illustrated below.

[0265] In some embodiments of this application, the process of generating at least one key based on the first key negotiation information and the second key negotiation information in step S103 includes, for example:

[0266] The first step is to obtain the basic key parameter SKEYID based on the first key negotiation information, the second key negotiation information, and the SM2 algorithm.

[0267] The second step is to obtain at least one derived key based on the basic key parameter SKEYID, wherein the at least one derived key includes a session key.

[0268] For example, if the first key negotiation information carries a first ISAKMP header and the peer's first cookie, the second key negotiation information carries a second ISAKMP header and the local second cookie, and at least one derived key is a session key, then the second step exemplarily includes: concatenating the first cookie, the second cookie, and a first value to obtain a first message; and performing a digest operation on the first message using the basic key parameters to obtain the session key. Some embodiments of this application obtain the session key based on the cookie in the ISAKMP header carried in the header, thereby improving the confidentiality of the obtained key.

[0269] For example, if the first key negotiation information carries a first ISAKMP header and the peer's first cookie, the second key negotiation information carries a second ISAKMP header, the second ISAKMP header carries the local second cookie, and at least one derived key is a session key (the acquisition process is described in the example above) and a first derived key, then the second step to obtain the first derived key exemplarily includes: concatenating the session key, the first cookie, the second cookie, and a second value to obtain a second message; performing a digest operation on the second message using the basic key parameters to obtain the first derived key, wherein the first derived key is used to verify message integrity and data source identity. Some embodiments of this application also obtain key information based on the first cookie, the second cookie, and the basic key parameters to ensure message integrity and data source identity verification during the negotiation process, thereby improving the security of the entire negotiation process before establishing a session.

[0270] For example, the first key negotiation information is used to carry a first ISAKMP header and the peer's first cookie; the second key negotiation information is used to carry a second ISAKMP header and the second ISAKMP header is used to carry the local's second cookie; and at least one derived key is a session key (the acquisition process is described in the example above), a first derived key (the acquisition process is described in the example above), and a second derived key. Therefore, the second step to obtain the second derived key typically includes: concatenating the first derived key, the first cookie, the second cookie, and a third value to obtain a third message; and performing a digest operation on the third message using the basic key parameters to obtain the second derived key, wherein the second derived key is used to protect message confidentiality.

[0271] Some embodiments of this application also utilize the first cookie, the second cookie, the first derived key, and basic key parameters to ensure message confidentiality during the negotiation process and enhance the security of the entire negotiation process before establishing a session. It should be noted that ISAKMP is the Internet Security Association and a key management protocol. Key negotiation information is encapsulated using the ISAKMP protocol. ISAKMP (i.e., the aforementioned first and second key negotiation information) includes an ISAKMP header and key negotiation information, and the cookie is contained within the ISAKMP format packet.

[0272] In other words, some embodiments of this application calculate basic key parameters based on the SM2 algorithm and obtain at least one derived key parameter based on the basic key parameters, thereby improving the confidentiality of the obtained cipher. Some embodiments of this application obtain the basic data used to generate the key through the SM2 algorithm.

[0273] To further enhance the security of the key negotiation process, in some embodiments of this application, the first key negotiation information further includes a first signature certificate and a first encryption certificate. Before generating at least one key based on the first key negotiation information and the second key negotiation information, the method further includes: confirming that the first signature certificate and the first encryption certificate have passed security verification. Some embodiments of this application employ dual-certificate verification using national cryptographic standards to ensure the security of the key negotiation process.

[0274] For example, in some embodiments of this application, the first signature certificate and the first encryption certificate are obtained from a CA authentication terminal.

[0275] To improve the versatility of the technical solution, in some embodiments of this application, the first key negotiation information is used to carry multiple usable encryption algorithms and verification algorithms, and the second key negotiation information is used to carry a target algorithm selected from the multiple encryption algorithms and the verification algorithms respectively; or, the second key negotiation information is used to carry multiple usable encryption algorithms and verification algorithms, and the first key negotiation information is used to carry a target algorithm selected from the multiple encryption algorithms and the verification algorithms respectively. Some embodiments of this application determine the encryption algorithm and verification algorithm through negotiation between the two parties, thereby improving the versatility of the technical solution.

[0276] It should be noted that the peer is the initiator and the local end is the responder corresponding to the initiator, or the local end is the initiator and the peer is the responder corresponding to the initiator.

[0277] The following is combined Figure 3 Taking the sender and responder as examples and combining them with a message transmission process example, the key negotiation method of some embodiments of this application is illustrated.

[0278] The following key negotiation method, applied to VPN systems, enables rapid negotiation of IPsec tunnels and enhances data security. The method includes the following steps:

[0279] Message 1: The initiator sends a Secure Association Payload SAi1 encapsulated with the proposed payload, the initiator's signing certificate CERT_sig_i, encryption certificate CERT_enc_i, initiator identity identifier (IDi), initiator-generated temporary public key (pub_temp_i), and initiator random number (Ni) to the responder.

[0280] Message 2: The responder sends a Security Association payload SAr1, along with the responder's signing certificate CERT_sig_r, the responder's encryption certificate CERT_enc_r, the responder's identity identifier (IDr), the responder's temporary public key (pub_temp_r), and the responder's random number (Nr). This payload indicates that it accepts the SA proposal sent by the initiator.

[0281] After message 1 and message 2 have interacted:

[0282] The initiator performs the following actions: generating a KEY using the initiator's encrypted public key (pub_i), the initiator's encrypted private key (pri_i), the initiator's identity identifier (IDi), the responder's encrypted public key (pub_r), the responder's identity identifier (IDr), the initiator's temporary public key (pub_temp_i), the initiator's temporary private key (prv_temp_i), the responder's temporary public key (pub_temp_r), and the klen parameter.

[0283] The responder performs the following actions: using the responder's encrypted public key (pub_r), the responder's encrypted private key (pri_r), the responder's identity identifier (IDr), the initiator's encrypted public key (pub_i), the initiator's identity identifier (IDi), the responder's temporary public key (pub_temp_r), the responder's temporary private key (prv_temp_r), the initiator's temporary public key (pub_temp_i), and the klen parameter to generate the key KEY.

[0284] For example, the key calculation method can be found in the key exchange protocol section of Part 3 of GM / T 0003.3SM2 Elliptic Curve Public Key Cryptography Algorithm.

[0285] For example, the formula for calculating the KEY obtained by the responder is KEY = Asymmetric_Negotiation(pub_i,pub_r,IDi,pub_temp_r,IDr,prv_r,prv_temp_r,klen).

[0286] After message 1 and message 2 are exchanged, the two parties involved in the communication generate a basic key parameter SKEYID based on their respective KEYs, in order to generate subsequent keys SKEYID_d (i.e., session key), SKEYID_a (i.e., first derived key), and SKEYID_e (i.e., second derived key). The calculation methods are as follows:

[0287] SKEYID=PRF(Hash(Ni_b|Nr_b),KEY|CKY-I|CKY-R)

[0288] SKEYID_d=PRF(SKEYID,CKY-I|CKY-R|0)

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

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

[0291] The values ​​0 (as an example of the first value), 1 (as an example of the second value), and 2 (as an example of the third value) in the above calculation formula are single-byte values.

[0292] SKEYID_e is the working key used by the ISAKMP SA to protect the confidentiality of its messages. SKEYID_a is the working key used by the ISAKMP SA to verify the integrity of its messages and the identity of the data source. SKEYID_d is used to generate key material for sub-SAs.

[0293] The length of all SKEYIDs is determined by the output length of the PRF function. If the output length of the PRF function is too short to be used as a key, SKEYID_e should be extended. For example, an HMAC hash PRF may produce a 128-bit output, but if the cryptographic algorithm requires a key longer than 128 bits, SKEYID_e needs to be extended using feedback and concatenation methods until the key length requirement is met. The feedback and concatenation methods are as follows:

[0294] K = K1|K2|K3…

[0295] K1 = PRF(SKEYID_e, 0)

[0296] K2 = PRF(SKEYID_e, K1)

[0297] K3 = PRF(SKEYID_e, K2)

[0298] …

[0299] Finally, starting from the beginning of K, extract the number of bits required for the key of the cryptographic algorithm.

[0300] Message 3 initiator integrity uses the AUTH payload to protect the payload content, as well as the flow selector TSi, TSR payload.

[0301] AUTH=Asymmetric_Sign(Ni_b|IDi_b|CERT_enc_i_b|TSi|TSr,pri_i)

[0302] Message 4 Responder Integrity uses AUTH load to protect the integrity of the load, as well as the flow selector TSi, TSR load.

[0303] AUTH=Asymmetric_Sign(Nr_b|IDr_b|CERT_enc_r_b|TSr|TSi,pri_r)

[0304] The following is combined Figure 4 The example illustrates how to create a new sub-SA using CREATE_CHILD_SA exchange to obtain an updated key.

[0305] Some embodiments of this application can create a sub-SA by sending a CREATE_CHILD_SA request. The CREATE_CHILD_SA request for creating a new sub-SA is designed with two messages as follows: Figure 4 As shown.

[0306] The initiator sends an SA proposal in the SA payload, a random number in the Ni payload, and optionally a public key value of a temporary key pair generated using the SM2 algorithm in the payload, as well as a flow selector for the proposed sub-SA proposal in the TSi and TSR payloads.

[0307] If the request contains KEi and the selected cryptographic suite contains that group, the responder replies (using the same message ID) with the accepted proposal in the SA payload and the public key value of the temporary key pair generated based on the SM2 algorithm in the payload.

[0308] for Figure 4 The content of each message can be found in the description above; to avoid repetition, it will not be repeated here. Figure 4 I won't go into too much detail.

[0309] The following is combined Figure 5 The present application provides an example of a key negotiation method in some embodiments, with gateway A as the initiator and gateway B as the responder. The method includes the following steps.

[0310] 1) Generate a temporary public key.

[0311] Gateway A generates a key pair (including Gateway A's encrypted public key, encrypted private key, temporary public key, and temporary private key) based on the SM2 algorithm for subsequent negotiation and key calculation processes. 2) Generate message 1 and send message 1 to the responder.

[0312] First, gateway A selects the encryption and verification algorithms to be used, encapsulates them into one or more suggested payloads, and then encapsulates the suggested payloads into a security association.

[0313] Secondly, gateway A encapsulates the security association payload, initiator signature certificate, encryption certificate, identity information, temporary public key, and other information into message 1 and sends it to gateway B.

[0314] 3) Gateway B receives the first message from Gateway A and verifies the legitimacy of the signature and encryption certificate sent by Gateway A.

[0315] 4) Gateway B generates its own key pair based on the SM2 algorithm, which is used for subsequent negotiation and key calculation processes.

[0316] 5) Gateway B selects the algorithm information proposed in message 1 and encapsulates the security association payload. It then encapsulates the security association payload, the responder's signature certificate, encryption certificate, identity information, temporary public key, and other information into message 2 and sends it to gateway A.

[0317] 6) Gateway B generates K based on the responder's encrypted public key (pub_r), the responder's encrypted private key (pri_r), the responder's identity identifier (IDr), the initiator's encrypted public key (pub_i), the initiator's identity identifier (IDi), the responder's temporary public key (pub_temp_r), the responder's temporary private key (prv_temp_r), the initiator's temporary public key (pub_temp_i), and the klen parameter, and calculates and generates parameters such as SKEYID, SKEYID_d, SKEYID_a, and SKEYID_e.

[0318] 7) Gateway A receives message 2 from Gateway B and verifies the validity of Gateway B's signature certificate and encryption certificate.

[0319] 8) Gateway A uses the initiator's encrypted public key (pub_i), the initiator's encrypted private key (pri_i), the initiator's identity identifier (IDi), the responder's encrypted public key (pub_r), the responder's identity identifier (IDr), the initiator's temporary public key (pub_temp_i), the initiator's temporary private key (prv_temp_i), the responder's temporary public key (pub_temp_r), and the klen parameter to generate K, and calculates and generates parameters such as SKEYID, SKEYID_d, SKEYID_a, and SKEYID_e.

[0320] 9) Gateway A calculates and generates the AUTH payload to authenticate the previous negotiation process and the TSi and TSR traffic selectors, and sends it to Gateway B.

[0321] 10) Gateway B verifies the AUTH payload and generates its own AUYH payload and TSi, TSR traffic selectors, which are then sent to Gateway A.

[0322] 11) Gateway A verifies the AUTH payload.

[0323] 12) When the key lifespan expires, the key is renegotiated. Gateway A sends a random number Ni to Gateway B, a temporary key pub_temp_i generated using the SM2 algorithm, and TSi,TSr traffic selectors.

[0324] 13) Gateway B sends a random number Nr to Gateway A, a temporary key pub_temp_r generated using the SM2 algorithm, and TSi,TSr traffic selectors. Both ends recalculate the keys using steps 6 and 8.

[0325] In other words, the key negotiation method in some embodiments of this application includes: when sending the first message, the initiator first generates a temporary SM2 key pair and sends its own security association payload, signature certificate, encryption certificate, identity identifier, and temporary public key information in the first message. When sending the second message, the responder first generates a temporary SM2 key pair and sends its own security association payload, signature certificate, encryption certificate, identity identifier, and temporary public key information in the second message. The initiator and the responder each calculate the SKEYID, SKEYID_d, SKEYID_a, and SKEYID_e parameters based on the information in the first two messages.

[0326] Some embodiments of this application provide a method for negotiating IPsec information, the method comprising: establishing an IPsec-based tunnel by negotiating at least one key obtained as described in any of the above embodiments.

[0327] Some embodiments of this application provide a method for a session, the method comprising: completing a session process between the local end and the peer end based on a session key obtained as in any of the above embodiments.

[0328] Please refer to Figure 6 , Figure 6 The present application provides an apparatus for key negotiation, which should be understood to be similar to the one described above. Figure 2Corresponding to the method embodiments, it can execute the various steps involved in the above method embodiments. The specific functions of the device can be found in the description above. To avoid repetition, detailed descriptions are appropriately omitted here. The device includes at least one software function module that can be stored in the memory or embedded in the device's operating system in the form of software or firmware. The key negotiation device includes: a receiving module 101, a negotiation information acquisition module 102, and a key generation module.

[0329] The receiving module 101 is configured to receive first key negotiation information sent by the peer, wherein the first key negotiation information includes: a first identity identifier, a first random number, a first encryption public key, and a first temporary public key.

[0330] The negotiation information acquisition module 102 is configured to acquire the second key negotiation information of the local end, wherein the second key negotiation information includes: a second identity identifier, a second random number, a second encryption public key, a second encryption private key, a second temporary private key, and a second temporary public key.

[0331] The key generation module 103 is configured to generate at least one key based on the first key negotiation information and the second key negotiation information.

[0332] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0333] Some embodiments of this application provide a computer storage medium having a computer program stored thereon, which, when executed by a processor, can implement the method described in any of the embodiments included in the above-described key negotiation method.

[0334] like Figure 7 As shown, some embodiments of this application provide an electronic device 500, including a memory 510, a processor 520, and a computer program stored on the memory 510 and executable on the processor 520, wherein the processor 520 can implement the method described in any of the embodiments included in the above methods when it reads the program from the memory 510 via a bus 530 and executes the program.

[0335] Processor 520 can process digital signals and can include various computing architectures. For example, it can be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 520 can be a microprocessor.

[0336] The memory 510 can be used to store instructions executed by the processor 520 or data related to the execution of instructions. These instructions and / or data may include code used to implement some or all of the functions of one or more modules described in the embodiments of this application. The processor 520 of the embodiments of this disclosure can be used to execute the instructions in the memory 510 to implement… Figure 2 Figure 2 The method shown. Memory 510 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memory well known to those skilled in the art.

[0337] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0338] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0339] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0340] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0341] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0342] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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.

Claims

1. A method for key negotiation, characterized in that, The method includes: Receive first key negotiation information sent by the peer, wherein the first key negotiation information includes: a first identity identifier, a first random number, a first encryption public key and a first temporary public key information, and the first key negotiation information is used to carry a first ISAKMP header and the peer's first cookie; Obtain the second key negotiation information of the local end, wherein the second key negotiation information includes: a second identity identifier, a second random number, a second encrypted public key, a second encrypted private key, a second temporary private key, and a second temporary public key information, and the second key negotiation information is used to carry a second ISAKMP header and the second cookie of the local end; Generate at least one key based on the first key negotiation information and the second key negotiation information, including: The basic key parameter SKEYID is obtained based on the first key negotiation information, the second key negotiation information, and the SM2 algorithm; The first cookie, the second cookie, and the first value are concatenated to obtain the first message; The first message is digested using the basic key parameters to obtain the session key; The session key, the first cookie, the second cookie, and the second value are concatenated to obtain the second message; The first derived key is obtained by performing a digest operation on the second message using the basic key parameters, wherein the first derived key is used to verify message integrity and the identity of the data source; The first derived key, the first cookie, the second cookie, and the third value are concatenated to obtain the third message; The second derived key is obtained by performing a digest operation on the third message using the basic key parameters, wherein the second derived key is used to protect the confidentiality of the message.

2. The method as described in claim 1, characterized in that, The second encrypted public key, the second encrypted private key, the second temporary private key, and the second temporary public key information are obtained through the SM2 encryption algorithm.

3. The method as described in claim 1, characterized in that, The first key negotiation information further includes a first signature certificate and a first encryption certificate, wherein, Before generating at least one key based on the first key negotiation information and the second key negotiation information, the method further includes: Confirm that the first signing certificate and the first encryption certificate have passed security verification.

4. The method as described in claim 3, characterized in that, The first signature certificate and the first encryption certificate are obtained from the CA authentication terminal.

5. The method as described in claim 3, characterized in that, The first key negotiation information is used to carry multiple available encryption algorithms and verification algorithms, and the second key negotiation information is used to carry a target algorithm selected from the multiple encryption algorithms and the verification algorithm respectively; or, The second key negotiation information is used to carry multiple encryption algorithms and verification algorithms that can be used, and the first key negotiation information is used to carry a target algorithm selected from the multiple encryption algorithms and the verification algorithm respectively.

6. The method as described in claim 1, characterized in that, The peer is the initiator and the local end is the responder corresponding to the initiator, or the local end is the initiator and the peer is the responder corresponding to the initiator.

7. A method for negotiating IPsec information, characterized in that, The method includes: A tunnel based on the IPsec protocol is established by negotiating at least one key obtained according to any one of claims 1-6.

8. A method for conversation, characterized in that, The method includes: The session process between the local end and the peer end is completed using the session key obtained according to any one of claims 1-6.

9. A key negotiation apparatus, characterized in that, The device includes: The receiving module is configured to receive first key negotiation information sent by the peer, wherein the first key negotiation information includes: a first identity identifier, a first random number, a first encryption public key, and a first temporary public key information, and the first key negotiation information is used to carry a first ISAKMP header and the peer's first cookie; The negotiation information acquisition module is configured to acquire the second key negotiation information of the local end, wherein the second key negotiation information includes: a second identity identifier, a second random number, a second encryption public key, a second encryption private key, a second temporary private key, and a second temporary public key information, and the second key negotiation information is used to carry a second ISAKMP header and the second cookie of the local end; The key generation module is configured to generate at least one key based on the first key negotiation information and the second key negotiation information, including: The basic key parameter SKEYID is obtained based on the first key negotiation information, the second key negotiation information, and the SM2 algorithm; The first cookie, the second cookie, and the first value are concatenated to obtain the first message; The first message is digested using the basic key parameters to obtain the session key; The session key, the first cookie, the second cookie, and the second value are concatenated to obtain the second message; The first derived key is obtained by performing a digest operation on the second message using the basic key parameters, wherein the first derived key is used to verify message integrity and the identity of the data source; The first derived key, the first cookie, the second cookie, and the third value are concatenated to obtain the third message; The second derived key is obtained by performing a digest operation on the third message using the basic key parameters, wherein the second derived key is used to protect the confidentiality of the message.

10. A computer storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it can implement the method described in any one of claims 1-7.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, When the processor executes the program, it can implement the method described in any one of claims 1-7.

Images