Network key exchange protocols use certificate authentication methods and communication devices.

Abstract

This application discloses a method for certificate authentication using the IKE network key exchange protocol. The method includes: a first device parsing a certificate to obtain signature information from the certificate; the first device filling the AUTH payload field of an IKE authentication AUTH message with the signature information from the certificate, wherein the signature information indicated by the AUTH payload field matches the signature information in the certificate; and the first device sending the IKE AUTH message to a second device. In the IKE certificate authentication method provided by this application, the first device can automatically parse the signature information from the certificate and fill relevant fields of the IKE AUTH message with the signature information, simplifying user configuration and improving product usability.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a method and communication device for using certificate authentication in a network key exchange protocol. Background Technology

[0002] When using Internet Key Exchange Protocol version 2 (IKEv2) for certificate authentication, the signature information carried in the IKE message needs to be configured by the user.

[0003] On the one hand, incorrect user configuration will cause authentication to fail. For example, if the user needs to configure the public key algorithm as an elliptic curve digital signature algorithm (ECDSA), but configures it as the Rivest–Shamir–Adleman algorithm (RSA), authentication will fail due to the configuration error. Similarly, if the ECDSA algorithm is configured incorrectly as "EDCSA", authentication will also fail.

[0004] On the other hand, the configuration commands for devices from different manufacturers are different. When configuring authentication for devices from different manufacturers, users need to learn the configuration commands for that manufacturer's devices. For example, when the public key algorithm to be configured is RSA, the configuration commands differ between manufacturers, for example:

[0005] The configuration command for vendor A's equipment is:

[0006] authentication{local{rsa-sig|pre-share|ecdsa-sig}|remote{eap[query-identity]|rsa-sig|pre-share|ecdsa-sig};

[0007] The configuration commands for vendor B's equipment are:

[0008] authentication-method(dsa-signatures|pre-shared-keys|rsa-signatures);

[0009] The configuration commands for vendor C devices are:

[0010] authby=pubkey|rsasig|psk|secret|xauthrsasig|xauthpsk|never;

[0011] The configuration commands for Huawei's Eudemon devices are as follows:

[0012] authentication-method{pre-share|rsa-signature|digital-envelope};

[0013] The configuration commands for vendor D's devices are:

[0014] authentication-method{pre-share|rsa-sig}.

[0015] Therefore, the existing IKE certification has high requirements for users. Summary of the Invention

[0016] This application provides a method and communication device for certificate authentication using the Internet Key Exchange Protocol (IKE). The first device can automatically parse the certificate, obtain the signature information in the certificate, and fill the relevant fields of the IKE authentication (AUTH) message according to the signature information, without requiring the user to configure specific signature information.

[0017] Firstly, a certificate authentication method for IKE is provided. This method includes: a first device parsing a certificate to obtain signature information from the certificate; the first device filling the AUTH payload field of an IKE authentication AUTH message with the signature information, wherein the signature information indicated by the AUTH payload field matches the signature information in the certificate; and the first device sending the IKE AUTH message to a second device. Here, the first device is the initiator of authentication, the second device is the responder of authentication, and the IKE AUTH message filled by the first device is an IKE_AUTH request message. The AUTH payload field indicates the types of signature information supported by the first device in authentication, and the filled value of the AUTH payload field has a mapping relationship with the signature information in the certificate.

[0018] In the above technical solution, the first device can automatically parse the certificate file, obtain the signature information in the certificate, and automatically fill the AUTH payload field in the AUTH message according to the signature information, without requiring the user to configure the specific signature information in the AUTH payload field, thus avoiding user configuration errors.

[0019] In one possible implementation, the signature information in the certificate includes a public key algorithm.

[0020] In another possible implementation, the signature information in the certificate also includes at least one of the following: signature padding method, hash algorithm, and expansion algorithm.

[0021] In another possible implementation, the signature information in the certificate includes an object identifier, which is an encoding of the signature information in the certificate.

[0022] In the above technical solution, after the first device parses the certificate, it can obtain various forms of signature information from the certificate, which improves the flexibility of the first device in obtaining signature information.

[0023] In another possible implementation, before the first device parses the certificate and obtains the signature information in the certificate, the method further includes: the first device obtaining first configuration information indicating the type of method used by IKE for certificate authentication.

[0024] In another possible implementation, the IKE uses a certificate authentication method of either generic certificate signature authentication or generic asymmetric key algorithm authentication; and, in the case where the IKE uses a certificate authentication method of generic asymmetric key algorithm authentication, the first configuration information further indicates the source of the signature information for the generic asymmetric key algorithm authentication.

[0025] In the above technical solution, users only need to set the first configuration information and do not need to configure the signature information in the specific IKEAUTH message, which simplifies user configuration and avoids configuration errors.

[0026] In another possible implementation, before the first device fills the AUTH payload field in the IKE AUTH message with the signature information in the certificate, the method further includes: the first device determining that both the first device and the second device support digital signatures; if both the first device and the second device support the digital signature, filling the AUTH payload field with a digital signature, and the filling value of the algorithm identifier field in the AUTH payload field is the Distinguished Identifier (DER) encoding of the object identifier.

[0027] In the above technical solution, the first device can automatically fill the AUTH payload field in the IKE AUTH message based on the signature information in the certificate and the signature filling method supported by the first and second devices, without requiring user configuration, thereby improving the accuracy of the IKE AUTH message and avoiding user configuration errors.

[0028] In another implementation, the first device determining that both the first and second devices support digital signatures includes: the first device acquiring second configuration information indicating that it supports digital signatures; and the first device acquiring an IKE security association (SA) message sent by the second device, which indicates that it supports digital signatures. Here, the second device is the responder in the authentication process, and the IKE SA message sent by the second device is an initial negotiation (IKE_SA_INIT) response message.

[0029] Secondly, a method for IKE authentication using certificates is provided. This method includes: a first device parsing a certificate to obtain signature information from the certificate; the first device filling the AUTH payload field of an IKE authentication AUTH message with the signature information from the certificate, wherein the signature information indicated by the AUTH payload field matches the signature information in the certificate; and the first device sending the IKE AUTH message to a second device. Here, the first device is the responder to authentication, the second device is the initiator of authentication, and the IKE AUTH message filled by the first device is an IKE_AUTH response message. The AUTH payload field indicates the types of signature information supported by the first device in authentication, and the filled value of the AUTH payload field has a mapping relationship with the signature information in the certificate.

[0030] In the above technical solution, the first device can automatically parse the certificate file, obtain the signature information in the certificate, and automatically fill the AUTH payload field in the AUTH message according to the signature information, without requiring the user to configure the specific signature information in the AUTH payload field, thus avoiding user configuration errors.

[0031] In one possible implementation, the signature information in the certificate includes a public key algorithm.

[0032] In another possible implementation, the signature information in the certificate also includes at least one of the following: signature padding method, hash algorithm, and expansion algorithm.

[0033] In another possible implementation, the signature information in the certificate includes an object identifier, which is an encoding of the signature information in the certificate.

[0034] In the above technical solution, after the first device parses the certificate, it can obtain various forms of signature information from the certificate, which improves the flexibility of the first device in obtaining signature information.

[0035] In another possible implementation, before the first device parses the certificate and obtains the signature information in the certificate, the method further includes: the first device obtaining first configuration information indicating the type of method used by IKE for certificate authentication.

[0036] In another possible implementation, the IKE uses a certificate authentication method of either generic certificate signature authentication or generic asymmetric key algorithm authentication; and, in the case where the IKE uses a certificate authentication method of generic asymmetric key algorithm authentication, the first configuration information further indicates the source of the signature information for the generic asymmetric key algorithm authentication.

[0037] In the above technical solution, users only need to set the first configuration information and do not need to configure the signature information in the specific IKEAUTH message, which simplifies user configuration and avoids configuration errors.

[0038] In another possible implementation, before the first device fills the AUTH payload field in the IKE AUTH message with the signature information in the certificate, the method further includes: the first device determining that both the first device and the second device support digital signatures; if both the first device and the second device support the digital signature, filling the AUTH payload field with a digital signature, and the filling value of the algorithm identifier field in the AUTH payload field is the Distinguished Identifier (DER) encoding of the object identifier.

[0039] In the above technical solution, the first device can automatically fill the AUTH payload field in the IKE AUTH message based on the signature information in the certificate and the signature filling method supported by the first and second devices, without requiring user configuration, thereby improving the accuracy of the IKE AUTH message and avoiding user configuration errors.

[0040] In another implementation, the first device determining that both the first and second devices support digital signatures includes: the first device acquiring second configuration information indicating that it supports digital signatures; and the first device acquiring an IKE SA message sent by the second device, which indicates that it supports digital signatures. Here, the second device is the initiator of the authentication, and the IKE SA message sent by the second device is an IKE_SA_INIT request message.

[0041] Thirdly, a communication device is provided, comprising a memory storing a program; and a processor communicating with the memory, the processor executing the program to cause the device to perform the following operations: parsing a certificate to obtain signature information from the certificate; filling an AUTH payload field in an IKE AUTH message according to the signature information in the certificate, wherein the signature information indicated by the AUTH payload field matches the signature information in the certificate; and sending the IKE AUTH message to a second device. In this embodiment, the communication device is the initiator of authentication, the second device is the responder of authentication, and the IKE AUTH message sent by the communication device is an IKE_AUTH request message. The AUTH payload field indicates the type of signature information supported by the first device in authentication, and the filled value of the AUTH payload field has a mapping relationship with the signature information in the certificate.

[0042] In one possible implementation, the signature information in the certificate includes a public key algorithm.

[0043] In another possible implementation, the signature information in the certificate also includes at least one of the following: signature padding method, hash algorithm, and expansion algorithm.

[0044] In another possible implementation, the signature information in the certificate includes an object identifier, which is an encoding of the signature information in the certificate.

[0045] In the above technical solution, after parsing the certificate, the communication device can obtain various forms of signature information from the certificate, which improves the flexibility of the communication device in obtaining signature information.

[0046] In another possible implementation, the program also includes instructions to perform the following operations: before the communication device parses the certificate and obtains the signature information in the certificate, obtain first configuration information indicating the type of method used by IKE for certificate authentication.

[0047] In another possible implementation, the IKE uses a certificate authentication method of either generic certificate signature authentication or generic asymmetric key algorithm authentication; and, in the case where the IKE uses a certificate authentication method of generic asymmetric key algorithm authentication, the first configuration information further indicates the source of the signature information for the generic asymmetric key algorithm authentication.

[0048] In the above technical solution, users only need to set the first configuration information and do not need to configure the signature information in the specific IKEAUTH message, which simplifies user configuration and avoids configuration errors.

[0049] In another possible implementation, the program further includes instructions to perform the following operations: before filling the AUTH payload field in the IKE AUTH message with the signature information in the certificate, determine that both the communication device and the second device support digital signatures; if both the communication device and the second device support the digital signature, fill the AUTH payload field with a digital signature, and the filled value of the algorithm identifier field in the AUTH payload field is DER encoded as an object identifier.

[0050] In the above technical solution, the communication device can automatically fill the AUTH payload field in the IKE AUTH message according to the signature information in the certificate and the signature filling method supported by the communication device and the second device, without requiring user configuration, thereby improving the accuracy of the IKE AUTH message and avoiding user configuration errors.

[0051] In another implementation, the communication device determining that both the communication device and the second device support digital signatures includes: the communication device acquiring second configuration information indicating that the communication device supports digital signatures; and the communication device acquiring an IKE SA message sent by the second device, the IKE SA message indicating that the second device supports digital signatures. Here, the second device is the responder in the authentication process, and the IKE SA message sent by the second device is an IKE_SA_INIT response message.

[0052] Fourthly, a communication device is provided, comprising a memory storing a program; and a processor communicating with the memory, the processor executing the program to cause the device to perform the following operations: parsing a certificate to obtain signature information from the certificate; filling an AUTH payload field in an IKE AUTH message according to the signature information in the certificate, wherein the signature information indicated by the AUTH payload field is the same as the signature information in the certificate; and sending the IKE AUTH message to a second device. In this embodiment, the communication device is the responder to authentication, the second device is the initiator of authentication, and the IKE AUTH message sent by the communication device is an IKE_AUTH response message. The AUTH payload field indicates the type of signature information supported by the first device in authentication, and the filled value of the AUTH payload field has a mapping relationship with the signature information in the certificate.

[0053] In one possible implementation, the signature information in the certificate includes a public key algorithm.

[0054] In another possible implementation, the signature information in the certificate also includes at least one of the following: signature padding method, hash algorithm, and expansion algorithm.

[0055] In another possible implementation, the signature information in the certificate includes an object identifier, which is an encoding of the signature information in the certificate.

[0056] In the above technical solution, after the first device parses the certificate, it can obtain various forms of signature information from the certificate, which improves the flexibility of the first device in obtaining signature information.

[0057] In another possible implementation, the program also includes instructions to perform the following operations: before the communication device parses the certificate and obtains the signature information in the certificate, obtain first configuration information indicating the type of method used by IKE for certificate authentication.

[0058] In another possible implementation, the IKE uses a certificate authentication method of either generic certificate signature authentication or generic asymmetric key algorithm authentication; and, in the case where the IKE uses a certificate authentication method of generic asymmetric key algorithm authentication, the first configuration information further indicates the source of the signature information for the generic asymmetric key algorithm authentication.

[0059] In the above technical solution, users only need to set the first configuration information and do not need to configure the signature information in the specific IKEAUTH message, which simplifies user configuration and avoids configuration errors.

[0060] In another possible implementation, the program further includes instructions to perform the following operations: before the communication device fills the AUTH payload field in the IKE AUTH message according to the signature information in the certificate, the communication device determines that both the communication device and the second device support digital signatures; if both the communication device and the second device support the digital signature, the AUTH payload field is filled with a digital signature, and the filled value of the algorithm identifier field in the AUTH payload field is the Distinguished Identifier (DER) encoding of the object identifier.

[0061] In the above technical solution, the communication device can automatically fill the AUTH payload field in the IKE AUTH message according to the signature information in the certificate and the signature filling method supported by the communication device and the second device, without requiring user configuration, thereby improving the accuracy of the IKE AUTH message and avoiding user configuration errors.

[0062] In another implementation, determining that both the communication device and the second device support digital signatures includes: the communication device acquiring second configuration information indicating that it supports digital signatures; and the communication device acquiring an IKE SA message sent by the second device, which indicates that the second device supports digital signatures. Here, the second device is the responder to the authentication, and the IKE SA message sent by the second device is an IKE_SA_INIT request message.

[0063] Fifthly, a chip is provided, the chip including a processor and a data interface, wherein the processor reads instructions stored in a memory through the data interface to execute the method in the first aspect or any possible implementation of the first aspect.

[0064] In a sixth aspect, a chip is provided, the chip including a processor and a data interface, wherein the processor reads instructions stored in a memory through the data interface to execute the method in the second aspect or any possible implementation of the second aspect.

[0065] In a seventh aspect, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in the first aspect or any possible implementation thereof.

[0066] Eighthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the second aspect or any possible implementation thereof.

[0067] Ninth aspect, a computer-readable storage medium is provided that stores computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0068] In a tenth aspect, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the second aspect or any possible implementation thereof. Attached Figure Description

[0069] Figure 1 This is a schematic diagram of a network scenario according to an embodiment of this application.

[0070] Figure 2 This is a diagram illustrating the message interaction process of IKEv2 authentication.

[0071] Figure 3 This is a flowchart illustrating a method for certificate authentication using the IKE network key exchange protocol according to an embodiment of this application.

[0072] Figure 4 This is a schematic diagram of a user participating in IKE authentication configuration according to an embodiment of this application.

[0073] Figure 5 This is a schematic diagram of the process of filling the AUTH load field according to an embodiment of this application.

[0074] Figure 6 This is a flowchart illustrating another embodiment of the IKE certificate authentication method.

[0075] Figure 7 This is a schematic diagram of the structure of a communication device provided according to an embodiment of this application.

[0076] Figure 8 This is a schematic diagram of the structure of a communication device provided according to an embodiment of this application.

[0077] Figure 9 This is a schematic diagram of the structure of a communication device provided according to an embodiment of this application. Detailed Implementation

[0078] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of this application, but not all embodiments.

[0079] This application will present various aspects, embodiments, or features relating to systems that may include multiple devices, components, modules, etc. It should be understood and appreciated that individual systems may include additional devices, components, modules, etc., and / or may not include all the devices, components, modules, etc. discussed in conjunction with the accompanying drawings. Furthermore, combinations of these approaches are also possible.

[0080] Furthermore, in the embodiments of this application, the words "exemplary," "for example," etc., are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the term "exemplary" is intended to present the concept in a concrete manner.

[0081] The network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0082] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0083] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0084] In network connections, Internet Protocol Security (IPSec) provides a secure communication channel, ensuring connection security through encrypted channels. Internet Key Exchange Protocol (IKE) assists IPSec in security management. IKE can authenticate devices during IPSec processing, while simultaneously negotiating security policies and exchanging session keys. The authentication method of this application embodiment can be applied to various network scenarios. Devices that support Internet Key Exchange Protocol version 2 (IKEv2) authentication and have the ability to calculate signatures and verify certificates can use the IKE certificate authentication method of this application embodiment for identity verification.

[0085] Figure 1 This is a schematic diagram of a network scenario according to an embodiment of this application. For example... Figure 1As shown, base station 110 connects to a secure network via switching device 120, router 130, and security gateway 140. IPSec channel 150 ensures connection security through encryption. For two devices communicating directly on this IPSec channel, as long as both devices support the IKEv2 protocol and have the ability to calculate signatures and verify certificates, they can use the method provided in this application embodiment for authentication.

[0086] For example, base station 110, switching device 120, and router 130 all support the IKEv2 protocol and have the ability to calculate signatures and verify certificates. In this case, when base station 110 communicates with switching device 120, security management can be performed using the IKE certificate authentication method of this application embodiment; when switching device 120 communicates with router 130, security management can also be performed using the IKE certificate authentication method of this application embodiment.

[0087] Figure 2 This is a diagram illustrating the message interaction process of IKEv2 authentication. Figure 2 As shown, the IKEv2 certification process consists of two stages:

[0088] Phase 1

[0089] The initiator and responder negotiate and exchange the parameters required for authentication through a pair of IKE security association (SA) messages, in which the initiator sends an initial negotiation (IKE_SA_INIT) request message and the responder sends an IKE_SA_INIT response message.

[0090] Phase Two

[0091] The initiator and responder authenticate each other using a pair of IKE authentication (AUTH) messages. The initiator's IKE AUTH message is called the IKE_AUTH request message, and the responder's IKE_AUTH message is called the IKE AUTH response message.

[0092] The IKE authentication message exchange process mainly includes: the initiator sends an IKE_SA_INIT request message to the responder, and the responder replies with an IKE_SA_INIT response message. The initiator and responder negotiate and exchange the parameters required for authentication through these two messages. Subsequently, the initiator sends an IKE_AUTH request message to the responder, and the responder replies with an IKE_AUTH response message, completing the authentication process.

[0093] In existing authentication methods, the signature information in the IKE AUTH message needs to be configured by the user. When configuring IKE authentication, the user must first review the signature information in the device certificate and accurately record it. Secondly, the user needs to configure the authentication method according to the recorded signature information, ensuring a one-to-one correspondence between the configured authentication method and the signature algorithm in the certificate. For example, if the public key algorithm indicated by the signature information in the certificate is RSA (Rivest–Shamir–Adleman algorithm), then the user-configured authentication method must match the RSA algorithm indicated by the certificate; that is, the user-configured algorithm must also be RSA. Additionally, some request for comments (RFC) documents, such as RFC 7427, have extended the authentication methods by adding a general authentication method: digital signature. Therefore, the user also needs to confirm whether the other party supports digital signatures.

[0094] Under the existing authentication methods, users are involved in a relatively complex configuration process. Users must understand how to query signature information in certificate files, comprehend the meaning of algorithm types, and be proficient in using the configuration options for different signature information types corresponding to the IKE authentication method. These operations place high demands on users. Furthermore, to prevent user configuration errors, additional foolproof designs are required for edge devices such as base stations and terminals.

[0095] The current authentication method is quite complex to configure. If a new certificate type, configuration interface, or IKE protocol implementation appears, it will require addition and modification, which is not conducive to expansion and will further increase the difficulty of use.

[0096] This application provides a method for IKE certificate authentication. The device can automatically parse the signature information from the certificate and fill the appropriate information into the corresponding fields of the IKE message, simplifying user configuration and further reducing human error. Moreover, since the device can automatically obtain the signature information from the certificate and fill it into the corresponding fields of the IKE message, users do not need to learn the configuration commands for devices from different manufacturers, improving product usability. Furthermore, for devices with high automation requirements, such as network edge devices, this authentication method can also reduce additional mistaken-proofing design and configuration constraints.

[0097] The following combination Figures 3 to 6 This application provides a detailed description of the certificate authentication method used in its embodiments.

[0098] Figure 3 This is a flowchart illustrating a method for IKE certificate authentication according to an embodiment of this application. It should be understood that... Figure 3The steps or operations of IKE's certificate authentication method are illustrated, but these steps or operations are merely examples, and other operations can be performed in the embodiments of this application. Figure 3 Variations of various operations within it.

[0099] The following combination Figure 3 Taking device A as the initiator and device B as the responder as an example, this application details a certificate authentication method according to an embodiment.

[0100] S210, Device A obtains the certificate configured by the user. Device A can store at least one certificate file. When Device A authenticates with different responding devices, different certificates may be required. For example, when Device A acts as the authentication initiator and Device B acts as the authentication responder, Device A needs certificate file A. In step S210, the user can instruct Device A to use certificate file A for this certificate authentication through command line (CMD), man-machine language (MML) commands, application programming interface (API), menu selection, etc.

[0101] In some embodiments, device A stores only one certificate file. As the initiator of authentication, device A will use this certificate file to authenticate with device B by default. In this case, the user does not need to configure the certificate file corresponding to this certificate authentication separately.

[0102] In other embodiments, device A stores at least one certificate file, and the first computer, as the initiator of authentication, uses certificate A from the at least one certificate file to authenticate with device B by default. In this case, the user may not need to configure the certificate file corresponding to this certificate authentication separately.

[0103] As described above, the user may not configure the certificate corresponding to this certificate authentication. Therefore, in some embodiments, device A may not need to obtain the certificate configured by the user. In this case, device A may default to using only one certificate within device A for this authentication, or device A may default to using certificate A from at least one certificate file for this authentication. In other words, in some cases, step S210 may not be executed. In this case, device A may determine that the certificate used for this authentication is only one certificate within device A, or device A may determine that the certificate used for this authentication is the default certificate A.

[0104] S220, Device A obtains the authentication options configured by the user. In this step, the user can configure the authentication options of Device A through command line, MML commands, API, menu selection, etc.

[0105] In one specific implementation, the user-configured authentication options may include first configuration information. This first configuration information indicates an authentication method. The authentication method indicated by the first configuration information may be a general certificate signature authentication or a general asymmetric key algorithm authentication. Furthermore, if the authentication method indicated by the first configuration information is a general asymmetric key algorithm authentication, the first configuration information may also indicate the source of the signature information for the general asymmetric key algorithm. The source of the signature information for the general asymmetric key algorithm may be a certificate, or other files besides certificate files, or other protocols.

[0106] For example, in the design of the options for the first configuration information, the generic certificate signing authentication option interface can be named: IKE_CERT_SIG or CERT_SIG.

[0107] For example, in the option design of the first configuration information, the general asymmetric key algorithm authentication option interface can be named: IKE_ASYM_ALG. Furthermore, the source of the signature information for asymmetric key algorithm authentication can be additionally specified in the option. In a specific implementation, if the source of the signature information for asymmetric key algorithm authentication is not additionally specified, then the default source of the signature information can be the certificate.

[0108] In one specific implementation, if the authentication options obtained by device A do not include the first configuration information, then device A can default to the general certificate signature authentication method.

[0109] In one specific implementation, the user-configured authentication options may include second configuration information indicating whether device A supports digital signatures, such as those specified in RFC 7427.

[0110] For example, in the design of the second configuration information options, the interface for configuring whether device A supports digital signature can be named: DIG_SIG.

[0111] In some embodiments, if the second configuration information is not included in the authentication options obtained by device A, then device A can be assumed to support digital signatures by default.

[0112] In other embodiments, if the authentication options obtained by device A do not include the second configuration information, then device A may be assumed to not support digital signatures.

[0113] Figure 4This is a schematic diagram of a user participating in IKE authentication configuration according to an embodiment of this application.

[0114] like Figure 4 As shown, the user configured the first configuration information through the CERT_SIG interface, indicating that device A's authentication method is general certificate signing authentication. Device A supports digital signatures by default; in this case, the user does not need to configure the second configuration information.

[0115] In other embodiments, the user configures first configuration information through the IKE_ASYM_ALG interface, indicating that the authentication method of device A is a general asymmetric key algorithm authentication, and indicating that the signature information comes from a certificate; the user configures second configuration information through the DIG_SIG interface, indicating that device A supports digital signature method.

[0116] In other embodiments, device A uses a common certificate signing authentication by default, and device A supports digital signatures by default. In this case, the user does not need to configure the first configuration information and the second configuration information.

[0117] It should be understood that, based on the configuration method of the above authentication options, Figure 4 The user configurations shown and the embodiments of the above user configurations are only some embodiments, and other possible configuration combinations will not be described in detail here.

[0118] It should also be understood that users can perform similar configuration operations on device B as described in steps S210 and S220, which will not be repeated here.

[0119] In other embodiments, where device A uses the common certificate signature authentication method, device A can carry a certificate file in the certificate (CERT) payload field of the third message of the IKE_AUTH request message. Device B can determine that it also uses the common certificate signature authentication method based on the certificate file in the CERT payload field.

[0120] As described above, the authentication options obtained by device A may not include the first configuration information and / or the second configuration information. Therefore, in some embodiments, device A may not obtain the user-configured authentication options. In this case, the first computer may default to using general certificate signing authentication and support digital signatures. In other words, in some cases, step S220 may not be executed. In this case, device A may determine that the authentication method is general certificate signing authentication and supports digital signatures.

[0121] As described above, in the embodiments of this application, steps S210 and S220 are optional steps. In other embodiments, some or all of steps S210 and S220 may exist. For example, steps S210 to S220 may exist before step S230, or only step S210 may exist, or only step S220 may exist.

[0122] In the above embodiments, users only need to configure simple authentication options and do not need to configure specific signature information. As mentioned above, during the authentication process, users can configure the authentication method through concise menus or option commands. For example, users can select the authentication method as general certificate signature authentication through menu selection; users can select whether device A supports digital signatures through menu selection. In existing certificate authentication technologies, users need to configure the signature information required by device A for authentication one by one through complex computer instructions. In the embodiments of this application, users do not need to configure each type of signature information through complex commands, nor do they need to learn the different command formats and configuration methods of devices from different manufacturers.

[0123] Steps S230 and S240 are the message interaction process between device A and device B in the first stage of IKEv2 authentication. It is understood that the filling method of each field in the IKE_SA_INIT request message in step S230 and the IKE_SA_INIT response message in step S240 is the same as that in the prior art, and will not be described in detail.

[0124] S230, Device A sends an IKE_SA_INIT request message to Device B.

[0125] In some embodiments, in addition to carrying authentication parameters in the IKE SA request message, device A may also carry information confirming whether device B supports digital signatures.

[0126] For example, if the second configuration information obtained by device A indicates that device A supports digital signatures, then device A will carry SIGNATURE_HASH_ALGORITHMS information in the IKE_SA_INIT request message to try to confirm whether device B supports digital signatures.

[0127] For example, if device A supports digital signatures by default, then device A can include SIGNATURE_HASH_ALGORITHMS information in the IKE_SA_INIT request message to try to confirm whether device B supports digital signatures.

[0128] For example, if device A does not support digital signatures by default or the second configuration information obtained indicates that device A does not support digital signature authentication, then device A may not carry the SIGNATURE_HASH_ALGORITHMS information in the IKE SA request message.

[0129] S240, Device A receives the IKE_SA_INIT response message sent by Device B.

[0130] In some embodiments, in addition to carrying authentication parameters in the IKE_SA_INIT response message, device B may also carry information indicating whether device B supports digital signatures.

[0131] For example, if device B supports digital signatures by default, then device B will include a notification with SIGNATURE_HASH_ALGORITHMS information in the second message of the IKE_SA_INIT response message to inform device A that device B supports digital signatures.

[0132] For example, if device B does not support digital signatures by default, then device B will not include the SIGNATURE_HASH_ALGORITHMS information in the second message of the IKE_SA_INIT response message, thus informing device A that device B does not support digital signatures.

[0133] In one specific implementation, device A can determine whether device B supports digital signatures based on whether the second message of the IKE_SA_INIT response message contains SIGNATURE_HASH_ALGORITHMS information.

[0134] Steps S250 and S260 are the message exchange process between device A and device B in the second phase of IKEv2 authentication.

[0135] S250, Device A sends an IKE_AUTH request message to Device B.

[0136] Before sending the IKE_AUTH request message, device A needs to populate the AUTH payload field in the IKE_AUTH request message.

[0137] As described above, in some embodiments, device A can obtain user-configured authentication options. In this case, device A can determine how to populate the AUTH payload field based on the obtained authentication options.

[0138] For example, if the authentication options obtained by device A include first configuration information, and the authentication method indicated by the first configuration information is general certificate signature authentication, then device A can automatically parse the signature information from the certificate and fill the AUTH payload field according to the signature information.

[0139] For example, if the authentication options obtained by device A include first configuration information, and the authentication method indicated by the first configuration information is a general asymmetric key algorithm authentication and the source of the signature information is a certificate, then device A can automatically parse the signature information from the certificate and fill the AUTH payload field according to the signature information.

[0140] In other embodiments, if the authentication options configured by the user do not include the first configuration information or the user does not configure authentication options, then device A can automatically parse the signature information from the certificate and fill the AUTH payload field according to the signature information.

[0141] The following combination Figure 5 This document details the process for populating the AUTH load field.

[0142] Figure 5 This is a schematic diagram of the process of filling the AUTH load field according to an embodiment of this application.

[0143] S310, Device A parses the certificate to obtain the signature information within it. Specifically, Device A can directly use software to parse the signature information contained in the certificate file, without requiring the user to query the signature information within the certificate. Device A can parse the signature information from multiple fields containing signature information in the certificate file.

[0144] For example, RFC 5280 defines the following format for signature information such as key algorithms in certificate files:

[0145]

[0146] Here, Certificate represents the certificate file; SEQUENCE indicates that the contents of the certificate are organized in sequence to form the target certificate; tbsCertificate(to be signed certificate) represents the certificate content to be signed in the certificate; signatureAlgorithm represents the signing algorithm of the certificate; and signatureValue represents the signature value of the certificate, which is obtained by signing the contents of tbsCertificate using the signing algorithm shown in signatureAlgorithm.

[0147] The signature algorithm represented by the signatureAlgorithm field specifically includes the algorithm and other definable parameters.

[0148] For example, if the signature information in the certificate is RSA With SHA-1, then the content of signatureAlgorithm in the above field of the certificate should be:

[0149]

[0150]

[0151] Device A parses the “IDENTIFIER” field in the above signatureAlgorithm field to obtain the extended algorithm as sha1WithRSAEncryption; parses the “HASHES” field in the above signatureAlgorithm field to obtain the hash algorithm as sha1; parses the “PUBLIC-KEYS” field in the above signatureAlgorithm field to obtain the public key algorithm as RSA; parses the “sha1WithRSAEncryption OBJECT IDENTIFIER” field in the above signatureAlgorithm field to obtain the object identifier as “iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-1(1)5”.

[0152] In addition, device A can also parse the Signature field and subjectPublicKeyInfo field in the TBSCertificate field of the certificate to obtain the above signature information, and the embodiments of this application do not limit this.

[0153] S320, Device A fills the AUTH payload field in the IKE_AUTH request message with the signature information in the certificate, and the signature information indicated by the AUTH payload field matches the signature information in the certificate.

[0154] Specifically, the AUTH payload field population can be divided into two cases: non-digital signature method and digital signature method. In the non-digital signature method, since the value of the AUTH method field indicates the signature information in the AUTH payload, the value of the AUTH method field must match the signature information in the certificate. In the digital signature method, the value of the AlgorithmIdentifierASN.1object field in the AUTH payload indicates the signature information in the AUTH payload; therefore, the value of the AlgorithmIdentifierASN.1object field must match the signature information in the certificate.

[0155] The following sections, in conjunction with Tables 1 and 2, describe how to fill the AUTH payload field under both non-digital signature and digital signature methods.

[0156] Table 1 shows the mapping relationship between the padding value of the AUTH payload field and the signature information in the certificate under non-digital signature methods. In a specific implementation, device A can determine the padding value of the AUTH method field based on the public key algorithm included in the signature information of the certificate, as well as at least one of the signature padding method, hash algorithm, and expansion algorithm.

[0157] Table 1

[0158]

[0159]

[0160] In Table 1, "-" indicates that a hash algorithm is not needed when the public key algorithm is EdDSA. "NA" in Table 1 indicates that the AUTH method is unavailable (NA).

[0161] In some embodiments, device A can determine the padding value for AUTH method based on a public key algorithm. For example, when the public key algorithm is RSA, device A can determine that the padding value for AUTH method is 1.

[0162] In some embodiments, device A can determine the padding value for AUTH method based on the public key algorithm and the extended algorithm. For example, when the public key algorithm is ECDSA and the extended algorithm is ecdsa-with-sha256, device A can determine that the padding value for AUTH method is 9.

[0163] In some embodiments, device A can determine the padding value of AUTHmethod based on the public key algorithm, hash algorithm, and signature padding method. For example, when the public key algorithm is ECDSA, the hash algorithm is SHA384, and the signature padding method is ECDSA, device A can determine that the padding value of AUTHmethod is 10.

[0164] In some embodiments, device A can determine the padding value for the Auth method based on the public key algorithm, signature padding method, hash algorithm, and extended algorithm. For example, when the public key algorithm is ECDSA, the signature padding method is ECDSA, the hash algorithm is SHA512, and the extended algorithm is ecdsa-with-sha512, device A can determine that the padding value for the Auth method is 11.

[0165] In one specific implementation, when device A determines that at least one of device A and device B does not support digital signatures, device A fills the AUTH payload field in a non-digital signature manner.

[0166] For example, device A obtains the second configuration information from the authentication options configured by the user, determines that device A supports digital signatures, and receives a notification from device B that the IKE_SA_INIT response message does not contain SIGNATURE_HASH_ALGORITHMS information. In this case, device A determines that at least one of the two devices does not support digital signatures, and device A fills the AUTH payload field in a non-digital signature manner.

[0167] For example, if device A does not support digital signatures by default, then device A determines that at least one of devices A and B does not support digital signatures, and device A fills the AUTH payload field in a non-digital signature manner.

[0168] Table 2 shows the mapping relationship between the padding values ​​of the AUTH payload field and the signature information in the certificate under digital signature methods. In a specific implementation, device A can determine the padding value of the AlgorithmIdentifier ASN.1object field in the AUTH payload field based on the object identifier included in the certificate's signature information. The object identifier included in the certificate's signature information is an encoding corresponding to the public key algorithm, signature padding method, hash algorithm, and extension algorithm in the certificate's signature information. The object identifier is a widely used method in public key algorithm standards; it can indicate the signature information contained in the certificate. Each signature information in a certificate has a corresponding object identifier. For example, RFC 5280 or RFC 5912 specifies the mapping relationship between signature information and object identifiers in certificates.

[0169] For example, in the digital signature method, the AUTH method field in the AUTH payload field is always filled with 14. The AlgorithmIdentifier ASN.1object field is filled with the object identifier in the certificate and the content of the attached parameters encoded using distinguished encoding rules (DER).

[0170] Table 2

[0171]

[0172] In Table 2, "-" indicates that a hash algorithm is not required when the public key algorithm is EdDSA.

[0173] For example, in one embodiment of step S310 above, when the signature information in the certificate is RSA With sha-1, parsing the "sha1WithRSAEncryption OBJECTIDENTIFIER" field of the signatureAlgorithm field in the certificate file yields the object identifier represented in abstract syntax notation one (ASN.1) as "iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-1(1)5". The dotted decimal encoding of this object identifier is "1.2.840.113549.1.1.5". Decoding this object identifier reveals that the signature information in the certificate is RSA With sha-1, and the additional parameter required by RFC 3279 is an empty parameter.

[0174] As shown in Table 2, when the signature information in the certificate is RSA With SHA-1, the padding value for the AlgorithmIdentifierASN.1object field is: 300d 0609 2a86 4886 f70d 0101 0505 00. Each byte of this padding value is a hexadecimal number, and the meaning of each byte is as follows:

[0175] The first byte "30" is a tag, indicating that the following content is a sequence, which consists of the object identifier and the ASN.1 encoding of the attached parameters in order;

[0176] The second byte "0d" indicates the length, meaning the following content is 13 bytes long;

[0177] The third byte, "06", is a tag, representing the object identifier;

[0178] The fourth byte, "09", indicates the length, meaning the following content is 9 bytes long. Combined with the third byte, this indicates that the object identifier encoded in the RSA With sha-1 signature information is 9 bytes long.

[0179] The 5th to 13th bytes, “2a86 4886 f70d 0101 05”, are the DER encoding of the object identifier of the signature information RSA With SHA-1;

[0180] The 14th byte "05" is a tag, representing a null value (NULL), indicating that the signature information RSA With sha-1 has no accompanying parameters;

[0181] The 15th byte "00" represents the length, indicating that the following content has a length of 0 bytes, meaning the parameter content is empty and there are no parameters.

[0182] It should be understood that, in Table 2, for each type of signature information object identifier, the padding value for the AlgorithmIdentifier ASN.1object field can be generated according to the DER encoding rules described above. To more concisely illustrate the mapping relationship between the padding value of the AlgorithmIdentifier ASN.1object field and the signature information in the certificate, some padding values ​​of the AlgorithmIdentifier ASN.1object field are omitted using the “…” symbol.

[0183] In one specific implementation, when device A determines that both device A and device B support digital signatures, device A fills the AUTH payload field according to the digital signature method.

[0184] For example, device A obtains the second configuration information from the authentication options configured by the user, determines that device A supports digital signatures, and receives a notification from device B that the second message of the IKE_SA_INIT response message contains SIGNATURE_HASH_ALGORITHMS information. In this case, device A determines that both devices support digital signatures, and device A populates the AUTH payload field according to the digital signature method.

[0185] For example, device A supports digital signatures by default, and device A receives a notification from device B that the second message of the IKE_SA_INIT response message contains SIGNATURE_HASH_ALGORITHMS information. In this case, device A determines that both devices support digital signatures, and device A populates the AUTH payload field according to the digital signature method.

[0186] It should be understood that, in the embodiments of this application, regardless of whether it is a non-digital signature method or a digital signature method, except for the AUTH method field and the AlgorithmIdentifier ASN.1object field in the AUTH payload field, the filling method of other fields in the IKE AUTH message is the same as the existing filling method, and will not be described again here.

[0187] As described above, in some implementations of the certificate authentication method in this application, device A can obtain the authentication options configured by the user and determine how to parse the signature information from the certificate. Furthermore, device A can obtain the user's configuration information to determine the AUTH payload padding method. In this case, device A can automatically parse the signature information from the certificate and automatically fill in the corresponding fields in the AUTH payload according to the mapping relationship between the signature information in the certificate and the padding values ​​of the AUTH payload. However, in existing authentication methods, the user needs to query the signature information in the certificate, configure the AUTH payload padding based on the signature information in the certificate, and ensure that the signature information corresponding to the user-configured AUTH payload padding values ​​matches the signature information in the certificate, which places high demands on the user.

[0188] S260, Device A receives the IKE_AUTH response message sent by Device B.

[0189] In this step, similar to device A, device B also needs to construct an IKE AUTH message. In this embodiment, device B is the authenticating responder, therefore device B needs to construct an IKE_AUTH response message, and the IKE_AUTH response message sent by device B has a similar structure to the IKE_AUTH request message sent by device A. Therefore, similar to device A, device B can also fill the AUTH payload in the IKE_AUTH response message according to the method in step S250 above, which will not be elaborated further here.

[0190] It should be understood that, apart from the AUTH method field and the AlgorithmIdentifier ASN.1object field mentioned above, the other fields in the IKE AUTH response message are filled in the same way as the existing fields.

[0191] After receiving the IKE_AUTH response message, device A checks whether the signature information carried in the response message is consistent with the signature information of the certificate file in the response message. If they are inconsistent, the authentication is considered to have failed; if they are consistent, the authentication process can continue.

[0192] The above describes the certificate authentication process using device A as the initiator and device B as the responder. It should be understood that device B can also be the initiator, and device A can also be the responder. In this case, device A and device B can still complete the certificate authentication process through a similar procedure as described above, which will not be repeated here.

[0193] Figure 6 This is a flowchart illustrating another embodiment of the IKE certificate authentication method 400 of this application.

[0194] S410, the first device parses the certificate and obtains the signature information from the certificate. The first device can then proceed as described above. Figure 5 The method described in step S310 of method 300 to obtain the signature information in the certificate will not be repeated here.

[0195] S420, the first device fills the AUTH payload field in the IKE AUTH message according to the signature information in the certificate. Method 400 can be used to implement method 200. When the first device is the initiator of authentication, the first device is equivalent to device A in method 200. Accordingly, the IKE AUTH message filled by the first device is equivalent to the IKE_AUTH request message in method 200. Therefore, the first device can fill the AUTH payload field in the IKE_AUTH request message according to the method described in step S250 of method 200 above.

[0196] When the first device is the authenticated responder, the first device is equivalent to device B in method 200. Accordingly, the IKE AUTH message populated by the first device is equivalent to the IKE_AUTH response message in method 200. Therefore, the first device can populate the AUTH payload field in the IKE_AUTH response message according to the method described in step S260 of method 200 above.

[0197] S430, the first device sends an IKE AUTH message.

[0198] When the first device is the initiator of authentication, the first device is equivalent to device A in method 200. In this case, the first device sends a populated IKE_AUTH request message.

[0199] When the first device is the authenticated responder, the first device is equivalent to device B in method 200. At this time, the first device sends a padded IKE_AUTH response message.

[0200] The certificate authentication method in this application simplifies the user configuration process and avoids user configuration errors. Furthermore, since no specific signature information needs to be configured, devices from different manufacturers can use the same or similar configuration interfaces. Users do not need to learn complex configuration commands from different manufacturers, improving product usability and reducing user requirements.

[0201] Furthermore, in this embodiment, after the first device uses a general certificate signature authentication based on the user's configuration information, or uses an asymmetric key algorithm authentication and determines that the source of the signature information is a certificate, the first device can automatically obtain the signature information from the certificate file. The first device can also automatically fill the AUTH payload field in the IKEAUTH message based on the signature information obtained from the certificate, eliminating the need for the user to configure the value of the AUTH payload field, avoiding user configuration errors, and improving the accuracy of the IKE AUTH message.

[0202] Figure 7 This is a schematic diagram of a communication device provided according to an embodiment of this application. The communication device is used to implement method 200 or method 400 as described above. For example, the communication device can be device A or device B in method 200, or it can be the first device in method 400, or it can be a component (e.g., a chip or circuit) that can be used in device A, device B, or the first device in the above methods. Figure 7 As shown, the communication device 700 may include an acquisition unit 710, a filling unit 720, and a transmission unit 730.

[0203] Unit 710 is used to parse the certificate and obtain the signature information in the certificate.

[0204] The filling unit 720 is used to fill the AUTH payload field in the IKE AUTH message with the signature information in the certificate, the signature information indicated in the AUTH payload field being the same as the signature information in the certificate.

[0205] The sending unit 730 is used to send the IKE AUTH message to the second device.

[0206] In one possible implementation, the acquisition unit 710 and the filling unit 720 can be implemented by a processor, and the sending unit 730 can be implemented by a transmitter. The specific functions and beneficial effects of the acquisition unit 710, the filling unit 720, and the sending unit 730 can be found in the description of the methods described above; for the sake of brevity, they will not be repeated here.

[0207] Figure 8This is a schematic diagram of a communication device provided according to an embodiment of this application. The communication device is used to implement the methods 200 or 400 described above. For example, the communication device can be device B in method 200, performing the operations performed by device B in method 200; it can be the second device in method 400; or it can be a component (e.g., a chip or circuit) that can be used in the second device in the above methods, performing the operations performed by the second device. Figure 8 As shown, the communication device 800 may include a receiving unit 810 and a transmitting unit 820.

[0208] The receiving unit 810 is used to receive the IKE AUTH message sent by the first device.

[0209] The sending unit 820 is used to send an IKE SA message to the first device, the IKE SA message indicating that the communication device supports digital signatures.

[0210] In one possible implementation, the receiving unit 810 can be implemented by a receiver, and the transmitting unit 820 can be implemented by a transmitter. The specific functions and beneficial effects of the receiving unit 810 and the transmitting unit 820 can be found in the description of the methods above, and will not be repeated here for the sake of brevity.

[0211] Figure 9 This is a schematic diagram of the structure of a communication device provided according to an embodiment of this application. For example... Figure 9 As shown, the communication device 900 includes a processor 910, a memory 920, and a transceiver 930. The processor 910 can be used to process certificate authentication protocols and authentication data, control the communication device, execute software programs, and process data from the software programs. The memory 920 is mainly used to store software programs and data. The transceiver 930 is used to receive information sent by other devices (e.g., a second device) or to send information to other devices.

[0212] For ease of explanation, Figure 9 Only one memory and processor are shown in the illustration. In actual communication equipment products, there may be one or more processors and one or more memories. Memory may also be called storage medium or storage device, etc. Memory may be set up independently of the processor or integrated with the processor; this application does not limit this.

[0213] A transceiver can also be called a transceiver unit, transceiver, or transceiver device. A processing unit can also be called a processor, processing board, processing module, or processing device. The components in transceiver 930 that implement the receiving function can be considered as the receiving unit, and the components in transceiver 930 that implement the transmitting function can be considered as the transmitting unit; that is, transceiver 930 includes both a receiving unit and a transmitting unit. The receiving unit can sometimes be called a receiver, receiver circuit, or receiving device. The transmitting unit can sometimes be called a transmitter, transmitter, or transmitting circuit.

[0214] The processor 910, memory 920, and transceiver 930 communicate with each other via internal interconnection paths to transmit control and / or data signals.

[0215] The methods disclosed in the embodiments of this application described above can be applied to, or implemented by, the processor 910. The processor 910 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 910 or by instructions in software form.

[0216] The processors described in the embodiments of this application can be general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. They can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory, electrically erasable programmable memory, registers, or other mature computer-readable storage media in the art. This computer-readable storage medium is located in memory; the processor reads instructions from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0217] In some embodiments, memory 920 may store information for performing tasks such as... Figure 3 and / or Figure 5The instructions for the method executed by device A and / or the first device in the illustrated method are shown. The processor 910 can execute the instructions stored in the memory 920 in conjunction with other hardware (e.g., transceiver 930) to complete the steps executed by the first device in the corresponding method. For the specific working process and beneficial effects, please refer to the description in the above embodiments.

[0218] In some embodiments, memory 920 may store information for performing tasks such as... Figure 3 and / or Figure 5 The instructions for the method executed by device B and / or the second device in the illustrated method are shown. Processor 910 can execute the instructions stored in memory 920 in conjunction with other hardware (e.g., transceiver 930) to complete the steps executed by the second device in the corresponding method. For specific working processes and beneficial effects, please refer to the description in the above embodiments.

[0219] In some embodiments, memory 920 may store information for performing tasks such as... Figure 3 The instructions for the methods executed by devices A and B in the illustrated method are shown. Processor 910 can execute the instructions stored in memory 920 in conjunction with other hardware (e.g., transceiver 930) to complete the steps executed by device A or device B in the corresponding method. For specific working processes and beneficial effects, please refer to the description in the embodiments shown above.

[0220] This application also provides a chip, which includes a transceiver unit and a processing unit. The transceiver unit may be an input / output circuit or a communication interface; the processing unit may be a processor, microprocessor, or integrated circuit integrated on the chip. This chip can execute the methods of device A and / or the first device described in the above method embodiments.

[0221] This application also provides a chip, which includes a transceiver unit and a processing unit. The transceiver unit may be an input / output circuit or a communication interface; the processing unit is a processor, microprocessor, or integrated circuit integrated on the chip. This chip can execute the methods executed by device B and / or the second device in the above embodiments.

[0222] This application also provides a computer-readable storage medium storing instructions thereon, which, when executed, perform the methods of device A and / or the first device described in the above method embodiments.

[0223] As another embodiment of this invention, a computer-readable storage medium is provided, on which instructions are stored, which, when executed, perform the methods of device B and / or the second device in the above method embodiments.

[0224] This application also provides a computer program product containing instructions that, when executed, perform the method of device A and / or the first device described in the above method embodiments.

[0225] As another form of this embodiment, a computer program product containing instructions is provided, which, when executed, perform the method of device B and / or the second device in the above method embodiment.

[0226] Those skilled in the art will 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, or a combination of computer software and electronic hardware. 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.

[0227] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0228] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0229] The methods in the embodiments of this application, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution or part of the technical solution of this application 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 storage medium includes at least: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, and other media capable of storing program code.

[0230] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for certificate authentication using the IKE network key exchange protocol, characterized in that, include: The first device parses the certificate and obtains the signature information from it. The first device fills the AUTH payload field in the IKE authentication AUTH message with the signature information in the certificate. The signature information indicated by the AUTH payload field matches the signature information in the certificate. The filled value of the AUTH payload field has a mapping relationship with the signature information in the certificate. The first device sends the IKE AUTH message to the second device.

2. The method according to claim 1, characterized in that, The signature information in the certificate includes: a public key algorithm.

3. The method according to claim 2, characterized in that, The signature information in the certificate also includes at least one of the following: signature padding method, hash algorithm, and extension algorithm.

4. The method according to claim 2, characterized in that, The signature information in the certificate includes an object identifier, which is an encoding of the signature information in the certificate.

5. The method according to any one of claims 1 to 4, characterized in that, Before the first device parses the certificate and obtains the signature information in the certificate, the method further includes: The first device obtains first configuration information, which indicates the type of certificate authentication method used by IKE.

6. The method according to claim 5, characterized in that: The type of certificate authentication method used by IKE is general certificate signature authentication; or, The type of certificate authentication method used by IKE is a general asymmetric key algorithm authentication. When the IKE uses a certificate authentication method of the type of general asymmetric key algorithm authentication, the first configuration information also indicates the source of the signature information of the general asymmetric key algorithm authentication.

7. The method according to any one of claims 1 to 4, characterized in that, Before the first device populates the AUTH payload field in the IKE AUTH message based on the signature information in the certificate, the method further includes: The first device determines that both the first device and the second device support digital signatures; When both the first device and the second device support the digital signature, the AUTH payload field is filled with a digital signature, and the filling value of the algorithm identifier field in the AUTH payload field is the Distinguished Identifier (DER) encoding of the object identifier.

8. The method according to claim 7, characterized in that, The first device determines that both the first device and the second device support digital signatures, including: The first device obtains second configuration information, which indicates that the first device supports digital signatures; The first device receives the IKE Security Association Parameter (SA) message sent by the second device, the IKE SA message indicating that the second device supports digital signatures.

9. A communication device, characterized in that, The communication device includes: Memory, which stores programs; A processor communicating with the memory executes the program, causing the device to perform the following operations: Parse the certificate to obtain the signature information within it; Based on the signature information in the certificate, the AUTH payload field of the IKE authentication AUTH message is populated. The signature information indicated by the AUTH payload field matches the signature information in the certificate, and the populated value of the AUTH payload field has a mapping relationship with the signature information in the certificate. Send the IKE AUTH message to the second device.

10. The communication device according to claim 9, characterized in that, The signature information in the certificate includes: a public key algorithm.

11. The communication device according to claim 10, characterized in that, The signature information in the certificate also includes at least one of the following: signature padding method, hash algorithm, and extension algorithm.

12. The communication device according to claim 10, characterized in that, The signature information in the certificate includes an object identifier, which is an encoding of the signature information in the certificate.

13. The communication device according to any one of claims 9 to 12, characterized in that, The program also includes instructions to perform the following operations: Before parsing the certificate and obtaining the signature information in the certificate, first configuration information is obtained, which indicates the type of certificate authentication method used by IKE.

14. The communication device according to claim 13, characterized in that: The type of certificate authentication method used by IKE is general certificate signature authentication; or, The type of certificate authentication method used by IKE is a general asymmetric key algorithm authentication. When the IKE uses a certificate authentication method of the type of general asymmetric key algorithm authentication, the first configuration information also indicates the source of the signature information of the general asymmetric key algorithm authentication.

15. The communication device according to any one of claims 9 to 12, characterized in that, The program also includes instructions to perform the following operations: Before filling the AUTH payload field in the IKE AUTH message with the signature information in the certificate, it is determined that both the communication device and the second device support digital signatures; When both the communication device and the second device support the digital signature, the AUTH payload field is filled with a digital signature, and the filling value of the algorithm identifier field in the AUTH payload field is the Distinguished Identifier (DER) encoding of the object identifier.

16. The communication device according to claim 15, characterized in that, The determination that both the communication device and the second device support digital signatures includes: Obtain second configuration information, which indicates that the communication device supports digital signatures; Obtain the IKE Security Association Parameter (SA) message sent by the second device, wherein the IKE SA message indicates that the second device supports digital signatures.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions for the method as described in any one of claims 1 to 8.

Images