Certificate issuing method, certificate adjusting method, certificate verifying method and device

Abstract

The invention provides a certificate issuing method, a certificate adjusting method and a certificate verifying method and device. In an embodiment, a first public key is obtained, the first public key being a public key generated based on a first algorithm; a certificate is generated, the certificate comprises a public key information field and an extension field, the public key information field is used for indicating the first public key, the extension field comprises a target field and an identification field, the target field is used for indicating target information, and the target information is information generated based on a second algorithm; the identification field is used for indicating the form of the target information, the form of the target information comprises a truth value and a hash value, and the first algorithm and the second algorithm are different types of algorithms; and sending the certificate to the second equipment. As a result, the certificate has backward compatibility.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a certificate issuance method, certificate adjustment method, certificate verification method and apparatus. Background Technology

[0002] Currently, certificates based on the X.509 standard bind an entity to a public key via digital signature. This means the X.509 standard only supports including one public key in the certificate, which is placed in the public key information field. However, with technological advancements, the corresponding physical devices of the dependent parties have also evolved, resulting in different capabilities for different dependent parties, such as the cryptographic algorithms they support.

[0003] However, cryptographic algorithms require extensive expert analysis and practical verification to gradually establish a level of security trust. Therefore, academia and most regulatory agencies suggest that in the early stages of standardization, there will be a situation where upgraded and non-upgraded devices coexist. In this case, a scheme that uses two public keys in combination is needed.

[0004] Therefore, there is an urgent need for a hybrid scheme that includes two public keys in a certificate, ensuring backward compatibility while using only one certificate. Summary of the Invention

[0005] This application provides a certificate issuance method, a certificate adjustment method, a certificate verification method, and an apparatus, enabling certificates to have multiple transmission formats and a single verification format, thereby ensuring backward compatibility. Thus, only one certificate needs to be issued, enabling both upgraded and non-upgraded devices to verify the certificate.

[0006] In a first aspect, embodiments of this application provide a certificate issuance method, applied to a first device, comprising:

[0007] Obtain the first public key, which is a public key generated based on the first algorithm;

[0008] Generate a certificate. The certificate includes a public key information field and an extended field. The public key information field is used to indicate the first public key. The extended field includes a target field and an identifier field. The target field is used to indicate the target information, which is information generated based on the second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms.

[0009] Send the certificate to the second device.

[0010] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0011] In one possible implementation, the method further includes:

[0012] Obtain the second public key, which is generated based on the second algorithm;

[0013] The target information is used to indicate the second public key or the hash value of the second public key.

[0014] In this way, it can be ensured that there is only one verification form for the certificate, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, thereby ensuring backward compatibility of the certificate, enabling both upgraded and non-upgraded devices to verify the validity of the certificate.

[0015] In one possible implementation, the target information is used to indicate a fourth signature, which is a signature generated by a second algorithm.

[0016] In this way, it can be ensured that there is only one verification form for the certificate, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, thereby ensuring backward compatibility of the certificate, enabling both upgraded and non-upgraded devices to verify the validity of the certificate.

[0017] In one possible implementation, the extended field includes at least one target field, and different target fields indicate different second algorithms corresponding to the target information.

[0018] In this way, the certificate can contain target information generated by multiple second algorithms, thereby ensuring backward compatibility of the certificate. For devices that support different second algorithms, with only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0019] In one possible implementation, the extended fields include at least one identifier field.

[0020] In this way, the form of the target information in the certificate can be changed, thus enabling backward compatibility. Furthermore, identifying multiple target fields with a single identifier field saves communication overhead.

[0021] In one possible implementation, where the extended fields include multiple target fields and multiple identifier fields, the identifier fields correspond one-to-one with the target fields.

[0022] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm used to calculate the hash value of the target information.

[0023] In one possible implementation, the extended fields also include an algorithm identifier field, which is used to indicate the identifier corresponding to the second algorithm.

[0024] In one possible implementation, the certificate also includes a signature field, which indicates a third signature, generated based on a third sub-algorithm and the hash value of the target information.

[0025] The first algorithm includes a third sub-algorithm.

[0026] Secondly, embodiments of this application provide a certificate adjustment method, applied to a second device, comprising:

[0027] Obtain a certificate, which includes a public key information field and an extended field. The public key information field is used to indicate the first public key, which is a public key generated based on the first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate the target information, which is information generated based on the second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms.

[0028] Based on the capability information of the third device, the form of the target information is adjusted. The capability information is used to indicate the algorithms supported by the third device.

[0029] Send the revised certificate to the third device.

[0030] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0031] In one possible implementation, the format of the target information is adjusted based on the capability information of the third device, including:

[0032] If the capability information of the third device indicates that the third device supports the second algorithm, adjust the target information to a true value.

[0033] If the capability information of the third device indicates that the third device does not support the second algorithm, the form of the target information is adjusted to a hash value.

[0034] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0035] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm used to calculate the hash value of the target information.

[0036] In one possible implementation, the second algorithm includes a first sub-algorithm. Before adjusting the certificate, the target information is a second public key, which is a public key generated by the second device based on the first sub-algorithm. The identification field is second information, which is used to indicate that the target information in the target field is a true value.

[0037] If the capability information of the third device indicates that the third device does not support the second algorithm, the target information is adjusted to a hash value, including:

[0038] Based on the identifier in the hash algorithm identifier field, the hash algorithm is called to calculate the hash value of the second public key;

[0039] Adjust the second public key in the certificate to the hash value of the second public key, and modify the second information to the first information. The first information is used to indicate that the target information in the target field is in the form of a hash value.

[0040] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0041] In one possible implementation, the second algorithm includes a second sub-algorithm, the target information is a fourth signature before the certificate is adjusted, the second public key is a public key generated by the second device based on the second sub-algorithm, the identification field is the second information, and the first information is used to indicate that the form of the target information in the target field is a true value.

[0042] If the capability information of the third device indicates that the third device does not support the second algorithm, the target information is adjusted to a hash value, including:

[0043] Based on the identifier in the hash algorithm identifier field, the hash algorithm is called to calculate the hash value of the fourth signature;

[0044] Adjust the fourth signature in the certificate to the hash value of the fourth signature, and modify the second information to the first information. The first information is used to indicate that the target information in the target field is in the form of a hash value.

[0045] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0046] Thirdly, embodiments of this application provide a certificate verification method applied to a third device, comprising:

[0047] Obtain a certificate, which includes a public key information field and an extended field. The public key information field indicates a first public key, which is a public key generated based on a first algorithm. The extended field includes a target field and an identifier field. The target field indicates target information, which is information generated based on a second algorithm. The identifier field indicates the form of the target information, which includes a truth value and a hash value. The form of the target information is associated with the capability information of a third device. The capability information indicates the algorithms supported by the third device. The first algorithm and the second algorithm are different types of algorithms.

[0048] The validity of the certificate is verified based on the hash value of the first public key and the target information.

[0049] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0050] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm. The third device supports the second algorithm, the target information in the certificate is in the form of a true value, and the certificate is verified based on the hash value of the first public key and the target information, including:

[0051] Based on the identifier of the hash algorithm, the hash algorithm is invoked to calculate the hash value of the target information;

[0052] Adjust the target information in the certificate to the hash value of the target information;

[0053] The certificate is verified based on the hash value of the first public key and the target information.

[0054] This ensures that there is only one verification form for the certificate, thus guaranteeing backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0055] In one possible implementation, the certificate also includes a signature field that indicates a third signature, which is a signature generated based on a third sub-algorithm according to the hash value of the target information, and the first algorithm includes the third sub-algorithm.

[0056] Verify the validity of the certificate based on the hash value of the first public key and the target information, including:

[0057] The third sub-algorithm is invoked to verify the validity of the certificate based on the hash value of the first public key, the third signature, and the target information.

[0058] This ensures that there is only one verification form for the certificate, thus guaranteeing backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0059] Fourthly, embodiments of this application provide a certificate issuing apparatus, applied to a first device, comprising:

[0060] The acquisition module is used to acquire the first public key, which is a public key generated based on the first algorithm.

[0061] The generation module is used to generate certificates. The certificate includes a public key information field and an extended field. The public key information field is used to indicate the first public key. The extended field includes a target field and an identifier field. The target field is used to indicate the target information, which is information generated based on the second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms.

[0062] The sending module is used to send certificates to the second device.

[0063] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0064] In one possible implementation, the acquisition module is also used to acquire a second public key, which is a public key generated based on a second algorithm;

[0065] The target information is used to indicate the second public key or the hash value of the second public key.

[0066] In this way, it can be ensured that there is only one verification form for the certificate, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, thereby ensuring backward compatibility of the certificate, enabling both upgraded and non-upgraded devices to verify the validity of the certificate.

[0067] In one possible implementation, the target information is used to indicate a fourth signature, which is a signature generated by a second algorithm.

[0068] In this way, it can be ensured that there is only one verification form for the certificate, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, thereby ensuring backward compatibility of the certificate, enabling both upgraded and non-upgraded devices to verify the validity of the certificate.

[0069] In one possible implementation, the extended field includes at least one target field, and different target fields indicate different second algorithms corresponding to the target information.

[0070] In this way, the certificate can contain target information generated by multiple second algorithms, thereby ensuring backward compatibility of the certificate. For devices that support different second algorithms, with only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0071] In one possible implementation, the extended fields include at least one identifier field.

[0072] In this way, the form of the target information in the certificate can be changed, thus enabling backward compatibility. Furthermore, identifying multiple target fields with a single identifier field saves communication overhead.

[0073] In one possible implementation, where the extended fields include multiple target fields and multiple identifier fields, the identifier fields correspond one-to-one with the target fields.

[0074] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm used to calculate the hash value of the target information.

[0075] In one possible implementation, the extended fields also include an algorithm identifier field, which is used to indicate the identifier corresponding to the second algorithm.

[0076] In one possible implementation, the certificate also includes a signature field, which indicates a third signature, generated based on a third sub-algorithm and the hash value of the target information.

[0077] The first algorithm includes a third sub-algorithm.

[0078] Fifthly, embodiments of this application provide a certificate verification device applied to a second device, comprising:

[0079] The acquisition module is used to acquire a certificate. The certificate includes a public key information field and an extended field. The public key information field is used to indicate the first public key, which is a public key generated based on the first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate the target information, which is information generated based on the second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms.

[0080] The adjustment module is used to adjust the form of the target information according to the capability information of the third device. The capability information is used to indicate the algorithms supported by the third device.

[0081] The sending module is used to send the modified certificate to a third device.

[0082] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0083] In one possible implementation, the module is adjusted for:

[0084] If the capability information of the third device indicates that the third device supports the second algorithm, adjust the target information to a true value.

[0085] If the capability information of the third device indicates that the third device does not support the second algorithm, the form of the target information is adjusted to a hash value.

[0086] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0087] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm used to calculate the hash value of the target information.

[0088] In one possible implementation, the second algorithm includes a first sub-algorithm. Before adjusting the certificate, the target information is a second public key, which is a public key generated by the second device based on the first sub-algorithm. The identification field is second information, which is used to indicate that the target information in the target field is a true value.

[0089] When the capability information of the third device indicates that the third device does not support the second algorithm, the adjustment module is used to:

[0090] Based on the identifier in the hash algorithm identifier field, the hash algorithm is called to calculate the hash value of the second public key;

[0091] Adjust the second public key in the certificate to the hash value of the second public key, and modify the second information to the first information. The first information is used to indicate that the target information in the target field is in the form of a hash value.

[0092] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0093] In one possible implementation, the second algorithm includes a second sub-algorithm, the target information is a fourth signature before the certificate is adjusted, the second public key is a public key generated by the second device based on the second sub-algorithm, the identification field is the second information, and the first information is used to indicate that the form of the target information in the target field is a true value.

[0094] If the capability information of the third device indicates that the third device does not support the second algorithm, the adjustment module is used to:

[0095] Based on the identifier in the hash algorithm identifier field, the hash algorithm is called to calculate the hash value of the fourth signature;

[0096] Adjust the fourth signature in the certificate to the hash value of the fourth signature, and modify the second information to the first information. The first information is used to indicate that the target information in the target field is in the form of a hash value.

[0097] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0098] Sixthly, embodiments of this application provide a certificate verification device applied to a third device, comprising:

[0099] The acquisition module is used to acquire a certificate, wherein the certificate includes a public key information field and an extended field. The public key information field is used to indicate a first public key, which is a public key generated based on a first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate target information, which is information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The form of the target information is associated with the capability information of a third device. The capability information is used to indicate the algorithms supported by the third device. The first algorithm and the second algorithm are different types of algorithms.

[0100] The verification module is used to verify the validity of the certificate based on the hash value of the first public key and the target information.

[0101] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0102] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm. The third device supports the second algorithm, the target information in the certificate is in the form of a true value, and the verification module is used for:

[0103] Based on the identifier of the hash algorithm, the hash algorithm is invoked to calculate the hash value of the target information;

[0104] Adjust the target information in the certificate to the hash value of the target information;

[0105] The certificate is verified based on the hash value of the first public key and the target information.

[0106] This ensures that there is only one verification form for the certificate, thus guaranteeing backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0107] In one possible implementation, the certificate also includes a signature field that indicates a third signature, which is a signature generated based on a third sub-algorithm according to the hash value of the target information, and the first algorithm includes the third sub-algorithm.

[0108] The verification module is used for:

[0109] The third sub-algorithm is invoked to verify the validity of the certificate based on the hash value of the first public key, the third signature, and the target information.

[0110] This ensures that there is only one verification form for the certificate, thus guaranteeing backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0111] In a seventh aspect, embodiments of this application provide a computing device, including: at least one memory for storing a program; and at least one processor for executing the program stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method provided in the first aspect, the method provided in the second aspect, or the method provided in the third aspect.

[0112] Eighthly, embodiments of this application provide a computing device, characterized in that the device executes computer program instructions to perform the methods provided in the first aspect, the second aspect, or the third aspect. For example, the device may be a chip or a processor.

[0113] In one example, the device may include a processor that may be coupled to a memory, read instructions from the memory, and execute, according to the instructions, the methods provided in the first aspect, the second aspect, or the third aspect. The memory may be integrated into the chip or the processor, or it may be independent of the chip or the processor.

[0114] Ninthly, embodiments of this application provide a computer storage medium storing instructions that, when executed on a computer, cause the computer to perform the method provided in the first aspect, the method provided in the second aspect, or the method provided in the third aspect.

[0115] In a tenth aspect, embodiments of this application provide a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method provided in the first aspect, the method provided in the second aspect, or the method provided in the third aspect.

[0116] Eleventhly, embodiments of this application provide a certificate verification system, including:

[0117] A first device for performing the method provided in the first aspect;

[0118] The second device communicates with the first device to perform the method provided in the second aspect;

[0119] A third device communicates with the first and second devices to perform the method provided in the third aspect.

[0120] In a twelfth aspect, embodiments of this application provide a chip, a memory, and a processor, wherein the memory stores executable code, and the processor executes the executable code to perform the method provided in the first aspect, the method provided in the second aspect, or the method provided in the third aspect. Attached Figure Description

[0121] Figure 1 This is a system architecture diagram of a PKI system provided in an embodiment of this application;

[0122] Figure 2 This is a flowchart illustrating a subscriber authentication method in a PKI system provided in an embodiment of this application;

[0123] Figure 3 This is a schematic diagram of a certificate format defined by the X.509 standard provided in an embodiment of this application;

[0124] Figure 4 This is a flowchart illustrating a certificate verification method provided in one embodiment of this application;

[0125] Figure 5 This is a schematic flowchart of an exemplary certificate generation method provided in an embodiment of this application;

[0126] Figure 6 This is a schematic diagram of a certificate format provided in one embodiment of this application;

[0127] Figure 7 This is a schematic diagram illustrating an exemplary certificate format provided in an embodiment of this application;

[0128] Figure 8 This is a schematic flowchart of an exemplary certificate verification method provided in an embodiment of this application;

[0129] Figure 9 This is a flowchart illustrating a certificate verification method in another embodiment provided in this application.

[0130] Figure 10 This is a flowchart illustrating another exemplary certificate generation method provided in an embodiment of this application;

[0131] Figure 11 This is a schematic diagram illustrating another exemplary certificate format provided in an embodiment of this application;

[0132] Figure 12 This is a flowchart illustrating another exemplary certificate verification method provided in an embodiment of this application;

[0133] Figure 13 This is a flowchart illustrating a certificate verification method in another embodiment provided in this application.

[0134] Figure 14 This is a schematic diagram of a certificate format in another embodiment provided in this application;

[0135] Figure 15 This is a flowchart illustrating yet another exemplary certificate generation method provided in this application embodiment;

[0136] Figure 16 This is a schematic diagram illustrating yet another exemplary certificate format provided in this application embodiment;

[0137] Figure 17a This is an exemplary schematic diagram of a certificate in another embodiment provided in this application;

[0138] Figure 17b This is an exemplary schematic diagram of a certificate in another embodiment provided in this application;

[0139] Figure 17c This is an exemplary schematic diagram of yet another certificate in yet another embodiment provided in this application;

[0140] Figure 18a This is an exemplary schematic diagram of yet another certificate in another embodiment provided in this application;

[0141] Figure 18b This is an exemplary schematic diagram of yet another certificate in another embodiment provided in this application;

[0142] Figure 19 This is a flowchart illustrating a certificate issuance method provided in an embodiment of this application;

[0143] Figure 20 This is a flowchart illustrating a method for a subscriber to perform certificate verification, as provided in an embodiment of this application.

[0144] Figure 21 This is a flowchart illustrating a method for a dependent party to perform certificate verification, as provided in an embodiment of this application.

[0145] Figure 22 This is a schematic diagram of the structure of a certificate issuing device provided in an embodiment of this application;

[0146] Figure 23 This is a schematic diagram of the structure of a certificate verification device provided in an embodiment of this application;

[0147] Figure 24 This is a schematic diagram of another certificate verification device provided in an embodiment of this application;

[0148] Figure 25 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0149] Figure 26 This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0150] Figure 27 This is a schematic diagram of another computing device cluster structure provided in an embodiment of this application. Detailed Implementation

[0151] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0152] Before providing a detailed description of the embodiments of this application, the terms used in the embodiments of this application will be explained first.

[0153] Post-quantum cryptography: a class of cryptographic algorithms that operate in a classical computing environment, whose underlying mathematical difficulties can resist attacks by quantum computers.

[0154] Traditional cryptographic algorithms: a class of cryptographic algorithms that operate in classical computing environments, whose underlying mathematical difficulties cannot resist attacks from quantum computers.

[0155] Public Key Infrastructure (PKI) is a standards-compliant key management platform that provides cryptographic services such as encryption and digital signatures, along with the necessary key and certificate management system, for all network applications. This system utilizes public key technology to implement functions such as authentication, data encryption, and data integrity verification in network communication. Figure 1 As shown, a PKI system includes a Certificate Authority (CA), subscribers, and relying parties. The CA is responsible for issuing and managing certificates. The CA is an independent and trusted third party that issues certificates to subscribers. The certificate declares the subscriber's identity and public key. Before issuing a certificate, the CA verifies the subscriber's identity information. Subscribers can apply for certificates from the CA and provide necessary information to prove their identity and capabilities. After obtaining a certificate issued by the CA, when interacting with relying parties, subscribers need to use the private key corresponding to the public key in the certificate to sign the messages provided by the relying party to prove their valid identity. The relying party verifies the authenticity and validity of the certificate and uses the public key in the certificate to verify the validity of the signature provided by the subscriber, thereby confirming that the subscriber is the certificate holder and ensuring the establishment of a secure communication channel.

[0156] Backward compatibility, also known as backward compatibility, refers to the ability of a system, software, or device to remain seamlessly compatible with older versions or previous iterations after an update or upgrade. This compatibility ensures that the new version is designed to be compatible with the old version, enabling them to continue to communicate and work together seamlessly. In this application embodiment, the new version refers to the dependent party in the PKI system whose devices have been upgraded, such as devices supporting post-quantum cryptography algorithms. The old version refers to the dependent party in the PKI system whose devices have not been upgraded, such as devices that only support traditional cryptography algorithms.

[0157] Next, the certificate application process and identity verification process will be explained in detail.

[0158] like Figure 2 As shown, the certificate application process in the PKI system is as follows.

[0159] First, the subscriber generates a key pair based on the digital signature algorithm: a public key (pksub) and a private key (sksub). The identifier for the digital signature algorithm is algidsub.

[0160] Next, the subscriber constructs a Certificate Signing Request (CSR). Specifically, the subscriber constructs the certificate request information based on the subscriber's name, public key pksub, and other optional attributes. The certificate request information includes the subscriber's name, public key pksub, and other optional attributes. The subscriber signs the certificate request information using their private key sksub, obtaining the signature δsub. Thus, a certificate signing request is constructed based on the certificate request information, the digital signature algorithm identifier algidsub, and the signature δsub.

[0161] Then, the subscriber sends a certificate signing request to the CA. Upon receiving the request, the CA parses it to obtain the certificate request information, the digital signature algorithm identifier `algidsub`, and the signature `δsub`. The CA verifies the signature `δsub` using the subscriber's public key `pksub` carried in the certificate request information. If the signature `δsub` is verified, the CA checks the correctness of each field in the certificate request information, such as whether the number of digits in each field is correct. If the correctness of each field is verified, the CA constructs a certificate according to the X.509 standard certificate format. The certificate includes multiple fields: version number, serial number, issuer, validity period, subscriber, subscriber's public key information, extended fields, the issuer's cryptographic algorithm identifier, and the issuer's signature. Specifically, the CA constructs and generates certificate information according to the X.509 standard certificate format. The certificate information includes information from the basic fields and extended fields. The basic fields include the version number, serial number, issuer, validity period, subscriber, and subscriber's public key information. The extended fields can contain multiple extensions, such as those defined in the standard and user-defined extensions. After generating the certificate information, the CA uses its private key skCA to sign the certificate information, resulting in the signature δCA. For example... Figure 3 As shown, in the certificate constructed by the CA, the subscriber's public key information consists of the public key pksub and the digital signature algorithm identifier algidsub, the CA's cryptographic algorithm identifier is algidCA, and the CA's signature is δCA. After the CA completes the certificate construction, it sends the certificate to the subscriber.

[0162] Finally, when the dependent party needs to verify the subscriber's identity, it sends a challenge message to the subscriber. This challenge message carries a timestamp and some other random information. Upon receiving the challenge message, the subscriber uses the private key `sksub` paired with the subscriber's public key as indicated in the certificate to sign the challenge message, obtaining a response message. The subscriber then sends the certificate and response message to the dependent party. Upon receiving the certificate and response message, the dependent party parses them to obtain the certificate information, the signature algorithm identifier `algidCA`, and the digital signature `δCA`. Using the certificate information as a message, it verifies the signature `δCA` using the CA's public key `pkCA`. If the verification passes, it verifies the response message. If the verification passes, the subscriber's identity is successfully authenticated. Thus, the dependent party and the subscriber can proceed with subsequent communication.

[0163] Currently, standardized certificate formats bind an entity to a public key via digital signatures. Specifically, the X.509 standard only supports one public key per certificate, placed in the subscriber's public key information field. However, with technological advancements, the corresponding physical devices of the dependent parties have also evolved, resulting in varying capabilities among different dependent parties, such as the cryptographic algorithms they support.

[0164] For example, general-purpose quantum computers can theoretically break traditional public-key cryptography, so academia and industry are actively researching cryptographic algorithms that can resist quantum computer attacks. These algorithms are collectively referred to as post-quantum cryptographic algorithms. Correspondingly, cryptographic algorithms that are not quantum-resistant are called traditional cryptographic algorithms. Currently, some countries and standards organizations have begun to promote the standardization process of post-quantum cryptographic algorithms. Academia and industry are also simultaneously conducting related research and experiments on the migration of post-quantum cryptographic algorithms.

[0165] However, cryptographic algorithms require extensive expert analysis and practical verification to gradually establish a level of security and trust. Therefore, academia and most regulatory agencies recommend using hybrid algorithms to provide higher security in the initial stages of standardization, that is, using both traditional and post-quantum cryptographic algorithms simultaneously. Typically, due to the complexity of business systems, the migration of cryptographic algorithms cannot be accomplished overnight, resulting in a situation where upgraded and non-upgraded devices coexist. Non-upgraded devices do not support post-quantum cryptographic algorithms and prefer to use traditional cryptographic algorithms for communication. Upgraded devices support both traditional and post-quantum cryptographic algorithms and prefer to use a hybrid approach for communication. Thus, when subscribers authenticate with dependents of varying capabilities, they need to provide certificates for different cryptographic algorithms based on the capabilities of the dependent party to complete the authentication process.

[0166] To achieve identity authentication in the aforementioned scenarios, there are multiple implementation methods. For example, based on the certificate format defined by the X.509 standard, a subscriber can apply for multiple independent certificates, each containing a public key and a CA's signature. For instance, one certificate might contain a public key for a traditional cryptographic algorithm, while another might contain a public key for a post-quantum cryptographic algorithm; both certificates are sent simultaneously during communication authentication. However, since different certificates have different expiration dates, subsequent renewal issues need to be handled separately, resulting in high maintenance costs.

[0167] For example, based on the certificate format defined by the X.509 standard, a subscriber applies for a certificate by concatenating two public keys generated using different algorithms into a single public key, which is then placed in the public key information field of the certificate. Two signatures generated using different algorithms are also concatenated into a single signature, which is placed in the signature field of the certificate. When the public key or signature is needed, the two public keys and two signatures are parsed from the certificate. If the two algorithms are a traditional cryptographic algorithm and a post-quantum cryptographic algorithm, then this implementation method cannot separate the concatenated public key into two public keys for devices that only have traditional cryptographic algorithms, meaning it cannot achieve compatibility with unupgraded devices.

[0168] For example, based on the certificate format defined by the X.509 standard, a subscriber applies for a certificate, placing a public key in the public key information field and adding an extension in the extension field. This extension contains another public key and is marked as an ignoreable extension. If the CA has two public-private key pairs, signing the certificate information separately yields two signatures, which need to be stored in the certificate. The certificate format itself has a signature field. Therefore, another extension is proposed specifically to store a signature. For backward compatibility, the public key used for traditional cryptographic algorithms (hereinafter referred to as the traditional public key) needs to be placed in the public key field, and the public key used for post-quantum cryptographic algorithms (hereinafter referred to as the post-quantum public key) needs to be placed in the extension field. Unupgraded devices (capable of traditional cryptographic algorithms) can ignore the extension field and use only the traditional public key for subsequent authentication. Alternatively, for backward compatibility, the signature calculated using traditional cryptographic algorithms (hereinafter referred to as the traditional signature) needs to be placed in the signature field, and the signature calculated using post-quantum cryptographic algorithms (hereinafter referred to as the post-quantum signature) needs to be placed in the extension field. Unupgraded devices can ignore the extended fields and use only traditional signatures for certificate verification. However, this implementation requires sending the entire certificate, including both public keys or both signatures, each time the certificate is transmitted. Post-quantum public keys and signatures are typically large. For example, using the Dilithium2 cryptographic algorithm, the public key is 1.3KB, larger than an entire traditional algorithm certificate. However, for unupgraded devices, transmitting post-quantum public keys and signatures is unnecessary, resulting in significant additional communication overhead. Placing the post-quantum public key in the public key field and the traditional public key in the extended field incurs only a small amount of additional communication overhead, but lacks backward compatibility. Similarly, placing the post-quantum signature in the signature field and the traditional signature in the extended field results in no backward compatibility for the certificate.

[0169] Based on this, embodiments of this application provide a certificate issuance method, a certificate adjustment method, a certificate verification method, and an apparatus. In this method, according to embodiments of this application, information, such as a first public key and target information, is generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility of the certificate, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of the target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, thus ensuring backward compatibility of the certificate. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0170] Next, with Figure 1 The schematic diagram shown illustrates the certificate verification method provided in this application embodiment in detail.

[0171] Figure 4 This is a flowchart illustrating a certificate verification method provided in an embodiment of this application. Figure 4 As shown, the certificate verification method provided in this application includes the following steps S401 to S411.

[0172] S401, the subscriber generates a first key pair using a first conventional cryptographic algorithm and a second key pair using a first post-quantum cryptographic algorithm.

[0173] The first key pair includes a first public key and a first private key. The second key pair includes a second public key and a second private key. For example, as shown... Figure 5 As shown, the subscriber (sub) generates a first key pair and a second key pair. The first key pair is (pkA, skA), and the second key pair is (pkB, skB).

[0174] S402, The subscriber constructs certificate request information, which includes the subscriber's name, first public key, second public key, and identifier of the hash algorithm.

[0175] A hash algorithm is used for subsequent hash value calculations. For example, such as... Figure 5 As shown in Table 1, the subscriber's name is sub, the first public key is pkA, the second public key is pkB, and the hash algorithm identifier is algidhash.

[0176] Table 1

[0177] Subscriber Name First public key Second public key Hash Algorithm other sub pkA pkB algidhash ——

[0178] The information included in the certificate request is for illustrative purposes only. Other relevant information may be added as needed for the actual application, and there are no specific limitations on this.

[0179] S403, the subscriber uses the first private key to sign the certificate request information to obtain the first signature, and uses the second private key to sign the certificate request information to obtain the second signature.

[0180] S404, The subscriber constructs a certificate signing request, wherein the certificate signing request includes certificate request information, an identifier of a first conventional cryptographic algorithm, an identifier of a first post-quantum cryptographic algorithm, a first signature, and a second signature.

[0181] For example, such as Figure 5 As shown, the first private key skA signs the certificate request information to obtain signature δA, and the second private key skB signs the certificate request information to obtain signature δB. The identifier for the first conventional cryptographic algorithm is algidA, the identifier for the first post-quantum cryptographic algorithm is algidB, the first signature is δA, the second signature is δB, and the certificate signing request is shown in Table 2. Table 2 is only for illustrating the detailed information in the certificate signing request; the specific format of the certificate signing request can be set according to actual needs, and this embodiment of the application does not impose specific limitations on it.

[0182] Table 2

[0183]

[0184] S405, the subscriber sends a certificate signing request to the CA.

[0185] S406, CA verifies the first signature according to the first conventional cryptographic algorithm and verifies the second signature according to the first post-quantum cryptographic algorithm.

[0186] After receiving a certificate signing request, the CA can parse the request to obtain the information within. Thus, the CA can invoke the first traditional cryptographic algorithm based on its identifier to verify the first signature. The CA can then invoke the first post-quantum cryptographic algorithm based on its identifier to verify the second signature. For example, as... Figure 5 As shown, based on algidA, cryptographic algorithm A is invoked to verify δA. Based on algidB, cryptographic algorithm B is invoked to verify δB. If the verification passes, S407 is executed.

[0187] S407, if the first and second signatures pass verification, the CA constructs the extended field.

[0188] To ensure backward compatibility of the certificate, enabling both un-upgraded and upgraded devices to verify subscribers, the CA places the first public key in the public key information field of the certificate and the second public key in the extended field of the certificate.

[0189] Specifically, in the certificate provided in this application embodiment, the extended fields include a target field and an identifier field. The information in the target field indicates the second public key, and the identifier field indicates the form of the second public key in the target field. The form of the second public key in the target field can be either the truth value of the second public key or the hash value of the second public key.

[0190] In S407, in the extended fields constructed by the CA, the target field is the hash value of the second public key, and the information of the identification field is the first information, which is used to indicate that the target field is a hash value.

[0191] In one possible implementation, the extended fields may also include an identifier field for the hash algorithm. For example, the CA hashes the second public key pkB using the hash algorithm algidhash to obtain the hash value hashB. Figure 5 As shown, in the extended fields, the target field is the hash value hashB of the second public key pkB, the hash algorithm identifier field is algidhash, and the identifier field is F. Here, F indicates that the information in the target field is the value after hashing the second public key pkB.

[0192] It should be noted that the representation of the identifier field can be set according to the actual situation, and this application does not impose specific limitations. For example, F can be used to indicate that the information in the target field is the value after processing the second public key, and T can be used to indicate that the information in the target field is the second public key. Alternatively, 0 can be used to indicate that the information in the target field is the value after processing the second public key, and 1 can be used to indicate that the information in the target field is the second public key.

[0193] S408, CA generates certificate.

[0194] After the CA completes the construction of the extended fields, it obtains the certificate information. The certificate information includes information from the basic fields and extended fields of the certificate. The basic fields include the version number, serial number, issuer, validity period, subscriber, and public key information. Next, the CA signs the certificate information using a third-party cryptographic algorithm and a third-party private key, obtaining a third signature. Specifically, the CA has a key pair: a third-party public key and a third-party private key. The CA can send the third-party public key to the dependent party. The specific timing of the CA sending the third-party public key to the dependent party is flexible. For example, the CA can send the third-party public key to the dependent party after generating it. This embodiment of the application does not specifically limit this.

[0195] Finally, the CA generates a certificate based on the certificate information, the identifier of the third cryptographic algorithm, and the third signature. For example... Figure 6 The certificate format generated by the CA is shown below. The certificate includes a version number, serial number, issuer, validity period, subscribers, public key information, extended fields, an identifier field for the CA's cryptographic algorithm, and a CA-side signature. The extended fields include a target field and an identifier field, among others.

[0196] For example, based on Figure 5 In the example shown, the certificate generated by the CA is as follows: Figure 7 As shown, the certificate includes certificate information, a third signature δCA1, and an identifier for a third cryptographic algorithm, algidCA1.

[0197] It is understood that, in addition to the information mentioned above, the extended fields may also include other information, which can be set according to actual needs. This application does not impose specific limitations on this.

[0198] S409, the CA sends a certificate to the subscriber.

[0199] S410, the subscriber sends a certificate to the dependent.

[0200] Once a subscriber receives the certificate, it can send the certificate to the dependent party, enabling the dependent party to authenticate the subscriber's identity based on the certificate.

[0201] Since the capabilities of the physical devices corresponding to different dependent parties are different, in order to ensure backward compatibility, the subscriber determines whether to modify the information in the target field and the identifier field of the certificate based on the capabilities of the dependent party before sending the certificate in the appropriate form to the dependent party.

[0202] In one possible implementation, the subscriber is pre-configured with the capabilities of the dependencies. For example, the subscriber includes a list of capability information for the dependencies, which indicates the algorithmic capabilities supported by different dependencies.

[0203] In another possible implementation, the subscriber can confirm the capabilities of the dependent with the dependent in real time. For example, the dependent can send capability information to the subscriber in real time, whereby the capability information indicates the capabilities possessed by the dependent. For instance, the capability information could be a set of identifiers of algorithms supported by the dependent itself, thus representing the dependent's capabilities through the algorithms it supports.

[0204] In one scenario, the target field in the certificate is a hash value, and the identifier field contains the first piece of information, resulting in a relatively small number of bytes. Therefore, to ensure backward compatibility and reduce communication overhead, if the dependent party does not support the first post-quantum cryptography algorithm, the subscriber directly sends the certificate to the dependent party. If the dependent party supports both the first traditional cryptography algorithm and the first post-quantum cryptography algorithm, to transmit two public keys, the subscriber modifies the first piece of information in the identifier field of the certificate to the second piece of information and modifies the hash value of the target field to the second public key. Then, the subscriber sends the modified certificate to the dependent party.

[0205] For example, such as Figure 8 As shown, if the dependent party supports the first traditional cryptographic algorithm algidA and the first post-quantum cryptographic algorithm algidB, then after receiving the certificate issued by the CA, the subscriber modifies the hash value hashB of the target field in the certificate to the second public key pkB, and modifies the first information F of the identifier field to the second information T. The subscriber then sends the modified certificate to the dependent party. Figure 8 The certificate shown only displays the modified information; the other parts remain unchanged.

[0206] In another scenario, the target field in the certificate is the second public key. Therefore, to ensure backward compatibility and reduce communication overhead, if the dependent party does not support the first post-quantum cryptography algorithm, the subscriber calculates the hash value of the second public key and modifies the second public key in the target field of the certificate to its hash value, while modifying the information in the identification field to the first information. The subscriber then sends the modified certificate to the dependent party. If the dependent party supports both the first traditional cryptography algorithm and the first post-quantum cryptography algorithm, the subscriber directly sends the certificate to the dependent party without modification.

[0207] S411, the dependent party verifies the certificate based on the information in the target field and the identification field of the certificate.

[0208] Different dependent parties receive different certificates. The differences lie in the target field and the identifier field. Specifically, if the identifier field is the first piece of information, it means the target field in the certificate is a hash value. In this case, the dependent party uses the identifier of the third cryptographic algorithm in the certificate to invoke the third cryptographic algorithm and uses the third public key to verify the certificate information and the third signature. If the signature verification passes, the certificate verification is successful, and the dependent party subsequently uses the first public key in the certificate to verify the subscriber's identity; if the signature verification fails, the certificate verification fails.

[0209] If the identifier field contains the second information, it indicates that the target field in the certificate contains the second public key. In this case, the dependent party, based on the hash algorithm identifier in the certificate, calls the hash algorithm to perform a hash calculation on the second public key, obtaining a hash value. Next, the dependent party modifies the target field information in the certificate to the hash value and modifies the second information in the identifier field to the first information. Then, based on the identifier of the third cryptographic algorithm in the modified certificate, the dependent party calls the third cryptographic algorithm and uses the third public key to verify the certificate information and third signature in the modified certificate. If the signature verification passes, the certificate verification is successful, and the dependent party subsequently uses the first and second public keys in the certificate to verify the subscriber's identity; if the signature verification fails, the certificate verification fails.

[0210] For example, such as Figure 8 As shown, after receiving the certificate, the dependent party calls the hash algorithm algidhash to hash the second public key pkB, obtaining the hash value hashB. It then modifies the second public key pkB in the target field of the certificate to hashB, and modifies the second information "T" in the identifier field to the first information "F". Finally, the dependent party calls the third cryptographic algorithm algidCA1, using the third public key pkCA1, to verify the certificate information and the third signature δCA in the modified certificate. If the signature verification passes, the certificate verification is successful.

[0211] Here, the third public key refers to the CA's public key. The third public key is sent to the dependent party in advance by the CA. For example, after generating the third public key and the third private key, the CA sends the third public key to the dependent party.

[0212] According to the embodiments of this application, subscribers generate two key pairs using two different algorithms, enabling a single certificate to carry information related to the public keys corresponding to the two different algorithms. To ensure backward compatibility, the certificate's extended fields define a target field and an identifier field. The identifier field determines whether the target field information is true, allowing the certificate to store a signature corresponding to one public key in the CA's signature field, and also supporting the storage of a signature corresponding to another public key. Subscribers can adjust the format of the target field information based on the capabilities of the entity device corresponding to the dependent party, thus transmitting certificates in different formats. During certificate verification, appropriate modifications are required to ensure the target information is in the form of a hash value. This ensures that the certificate has only one verification format but multiple transmission formats. Different transmission formats correspond to dependent parties with different capabilities. Therefore, for upgraded devices, the certificate transmission format is a target field with a true value, i.e., a second public key, providing double security guarantees during signature verification. For un-upgraded devices, the certificate is transmitted with the target field being a hash value. Even if the un-upgraded device does not support the first post-quantum cryptography algorithm, it can still verify the certificate, ensuring backward compatibility. Moreover, transmitting the certificate with the target field as a hash value reduces communication overhead.

[0213] Figure 9 This is a flowchart illustrating another certificate verification method provided in an embodiment of this application. Figure 9 As shown, the certificate verification method provided in this application embodiment includes the following steps S901 to S911.

[0214] S901, the subscriber generates the first key pair using the first conventional cryptographic algorithm.

[0215] The first key pair includes a first public key and a first private key.

[0216] S902, the subscriber constructs certificate request information, which includes the subscriber's name, first public key, and hash algorithm identifier.

[0217] The hash algorithm is the hash algorithm specified by the subscriber. For example, if the subscriber's name is sub, the first public key is pkA, and the hash algorithm identifier is algidhash, then the certificate request information is as shown in Table 3.

[0218] Table 3

[0219] Subscriber Name First public key Hash Algorithm other sub pkA algidhash ——

[0220] The information included in the certificate request is for illustrative purposes only. Other relevant information may be added as needed for the actual application, and there are no specific limitations on this.

[0221] S903, the subscriber uses the first private key to sign the certificate request information to obtain the first signature.

[0222] S904, The subscriber constructs a certificate signing request, wherein the certificate signing request includes certificate request information, an identifier of a first conventional cryptographic algorithm, and a first signature.

[0223] For example, the first private key skA signs the certificate request information to obtain the signature δA. The identifier of the first conventional cryptographic algorithm is algidA, and the certificate signing request is shown in Table 4. Here, Table 4 is only for illustrating the detailed information in the certificate signing request. The specific format of the certificate signing request can be set according to actual needs, and this embodiment of the application does not specifically limit it.

[0224] Table 4

[0225]

[0226] S905, the subscriber sends a certificate signing request to the CA.

[0227] S906, CA verifies the first signature according to the first conventional cryptographic algorithm.

[0228] After receiving a certificate signing request, the CA can parse the request to obtain the information within. The CA can then invoke the first traditional cryptographic algorithm based on its identifier to verify the first signature. If the signature verification is successful, step S907 is executed.

[0229] S907, if the first signature verification passes, the CA constructs the extended fields.

[0230] In this embodiment, the CA has two key pairs: a third key pair and a fourth key pair. The third key pair consists of a third public key pkCA1 and a third private key skCA1, while the fourth key pair consists of a fourth public key pkCA2 and a fourth private key skCA2. In this embodiment, the third key pair is generated using a third cryptographic algorithm, and the fourth key pair is generated using a second post-quantum cryptographic algorithm.

[0231] To ensure backward compatibility of the certificate, enabling both un-upgraded and upgraded devices to verify subscribers using the certificate, in this embodiment, as follows: Figure 6 As shown, the certificate's extended fields include a target field, an identifier field, and an algorithm identifier field. One possible implementation is... Figure 6 As shown, the extended fields of the certificate can also include a hash algorithm identifier field.

[0232] First, the CA signs the first certificate information using a fourth private key based on the second post-quantum cryptography algorithm, obtaining a fourth signature. In the first certificate information, the target field and identifier field of the extended fields are empty. Next, the CA calculates the hash value of the fourth signature using a hash algorithm and places this hash value in the target field. The identifier field in the certificate contains the first information, which indicates that the information in the target field is in the form of a hash value. The algorithm identifier field in the certificate contains the identifier of the second post-quantum cryptography algorithm, and the hash algorithm identifier field contains the identifier of the hash algorithm. Thus, the extended fields are not empty, resulting in the second certificate information. Then, the CA signs the second certificate information using a third private key based on a third cryptography algorithm, obtaining a third signature. In this case, the target field and identifier field of the second certificate information are not empty.

[0233] For example, such as Figure 10 As shown, after the CA verifies the signature of δA, it calls the cryptographic algorithm algidCA2 and uses the private key skCA2 to sign certificate information 1, obtaining signature δCA2. In certificate information 1, the target field and the identifier field are empty. Next, the hash algorithm algidhash is used to hash the signature δCA2, obtaining the hash value hashD. Then, extended fields are constructed. In the extended fields, the target field is hashD, the identifier field is F, the hash algorithm identifier field is algidhash, and the cryptographic algorithm identifier field is algidCA2.

[0234] S908, CA generates certificates.

[0235] After constructing the extended fields, the CA generates a certificate based on the information in the extended fields, the third signature, and the identifier of the third cryptographic algorithm.

[0236] For example, such as Figure 10 As shown, the CA generates a certificate based on the extended fields, the signature δCA1, and the identifier of the third cryptographic algorithm, algidCA1. Based on... Figure 10 The example shown can yield results such as Figure 11 The certificate shown Figure 11 Only partial certificate information is shown; information such as version number, serial number, issuer, validity period, and subscriber has been omitted. Information for the omitted fields can be generated according to the actual situation.

[0237] S909, the CA sends a certificate and a fourth signature to the subscriber.

[0238] In this embodiment of the application, since the fourth signature is obtained by signing the first certificate information with the fourth private key, and the subscriber cannot obtain the fourth private key, the CA needs to send the fourth signature to the subscriber.

[0239] In other embodiments, the CA can modify the hash value of the target field to a fourth signature and the identifier field to second information before sending the certificate to the subscriber. In this way, the subscriber can obtain the fourth signature through the certificate.

[0240] S910, subscribers send certificates to dependents.

[0241] Once a subscriber receives the certificate, it can send the certificate to the dependent party, enabling the dependent party to authenticate the subscriber's identity based on the certificate.

[0242] Since the capabilities of the physical devices corresponding to different dependent parties are different, in order to ensure backward compatibility, the subscriber determines whether to modify the information in the target field and the identifier field of the certificate based on the capabilities of the dependent party before sending the certificate in the appropriate form to the dependent party.

[0243] In one possible implementation, the subscriber is pre-configured with the capabilities of the dependencies. For example, the subscriber includes a list of capability information for the dependencies, which indicates the algorithmic capabilities supported by different dependencies.

[0244] In another possible implementation, the subscriber can confirm the capabilities of the dependent with the dependent in advance. For example, the dependent can send capability information to the subscriber in advance, whereby the capability information indicates the capabilities the dependent possesses. For instance, the capability information could be a set of identifiers of algorithms supported by the dependent itself, thus representing the dependent's capabilities through the algorithms it supports.

[0245] In this embodiment, the target field of the certificate is the fourth signature, and the identification information is the second information. Therefore, to ensure backward compatibility and reduce communication overhead, if the dependent party does not support the second post-quantum cryptography algorithm, the subscriber calls a hash algorithm to perform a hash calculation on the fourth signature, thereby obtaining the hash value of the fourth signature. The subscriber modifies the fourth signature in the target field to the hash value of the fourth signature and modifies the information in the identification field to the first information. Finally, the subscriber sends the modified certificate to the dependent party. If the dependent party supports the third cryptography algorithm and the second post-quantum cryptography algorithm, the subscriber directly sends the certificate to the dependent party. For example, as shown... Figure 12 As shown, when the subscriber receives the certificate from the CA and the dependent party does not support the second post-quantum cryptography algorithm, the subscriber sends the certificate directly to the dependent party without making any modifications to the certificate.

[0246] S911, the dependent party verifies the validity of the certificate based on the information in the target field and the identification field of the certificate.

[0247] Different dependent parties receive different certificates. The differences lie in the target field and the identifier field. Specifically, if the identifier field contains the first piece of information, it means the target field in the certificate contains the hash value of the fourth signature. In this case, the dependent party uses the identifier of the third cryptographic algorithm in the certificate to invoke the third cryptographic algorithm and uses the third public key to verify the certificate information and the third signature. If the verification passes, the certificate verification is successful; otherwise, it fails.

[0248] If the identifier field contains the second piece of information, it indicates that the target field in the certificate contains the fourth signature. In this case, the dependent party, based on the hash algorithm identifier in the certificate, invokes the hash algorithm to perform a hash calculation on the fourth signature, obtaining a hash value. Next, the dependent party modifies the target field information in the certificate to the hash value and modifies the second piece of information in the identifier field to the first piece of information. Finally, based on the identifier of the third cryptographic algorithm in the modified certificate, the dependent party invokes the third cryptographic algorithm and uses the third public key to verify the certificate information and the third signature in the modified certificate.

[0249] In one possible implementation, if the relying party supports the second post-quantum cryptography algorithm, the relying party first verifies the third signature. If the third signature verification passes, the fourth signature is verified. Specifically, the second post-quantum cryptography algorithm is invoked, using the fourth public key, to verify the first certificate information and the fourth signature. The first signature information is detailed in S907 and will not be repeated here. If both the third and fourth signatures pass verification, the certificate verification is successful. For example, as shown... Figure 12 As shown, after receiving the certificate, the dependent party calls the hash algorithm algidhash to hash the signature δCA2, obtaining the hash value hashD. It then modifies the signature δCA2 in the target field of the certificate to hashD and changes the second information "T" in the identifier field to the first information "F". Next, the dependent party calls the third cryptographic algorithm algidCA1, using the third public key pkCA1, to verify the second certificate information and the third signature δCA1 in the modified certificate. Then, if the third signature δCA1 is verified, it calls the second post-quantum cryptographic algorithm algidCA2, using the fourth public key pkCA2, to verify the first certificate information and the fourth signature δCA2. If the verification is successful, the certificate verification is successful.

[0250] Here, the third public key refers to the CA's public key. The third public key is sent to the dependent party in advance by the CA. For example, after generating the third public key and the third private key, the CA sends the third public key to the dependent party. The fourth public key is the CA's public key. The fourth public key is sent to the dependent party in advance by the CA. For example, after generating the fourth public key and the fourth private key, the CA sends the fourth public key to the dependent party.

[0251] According to the embodiments of this application, the CA generates two key pairs using two different algorithms, enabling a single certificate to carry information related to the public keys corresponding to the two different algorithms. To ensure backward compatibility, the certificate's extended fields define a target field and an identifier field. The identifier field determines whether the target field's information is true, allowing the certificate to contain both the public key and a second public key, in addition to the public key information field. Subscribers can adjust the format of the target field information based on the capabilities of the entity device corresponding to the dependent party, thus transmitting certificates in different formats. During certificate verification, appropriate modifications are required to ensure the target information is in the form of a hash value. This ensures that the certificate has only one verification format but multiple transmission formats. Different transmission formats correspond to dependent parties with different capabilities. Therefore, for upgraded devices, the certificate transmission format is a true value for the target field, providing double security guarantees during signature verification. For un-upgraded devices, the certificate transmission format is a hash value for the target field, allowing certificate verification even if the un-upgraded device does not support the first post-quantum cryptography algorithm, ensuring backward compatibility. Furthermore, when the certificate is transmitted in the form of a hash value as the target field, communication overhead can be reduced.

[0252] Figure 13 This is yet another certificate verification method provided in the embodiments of this application. For example... Figure 13 As shown, the certificate verification method provided in this application embodiment includes the following steps S1301 to S1311.

[0253] S1301, the subscriber generates a first key pair using a first conventional cryptographic algorithm and a second key pair using a first post-quantum cryptographic algorithm.

[0254] S1302, the subscriber constructs certificate request information, which includes the subscriber's name, first public key, second public key and hash algorithm identifier.

[0255] S1303, the subscriber uses the first private key to sign the certificate request information to obtain the first signature, and uses the second private key to sign the certificate request information to obtain the second signature.

[0256] S1304, The subscriber constructs a certificate signing request, wherein the certificate signing request includes certificate request information, an identifier of a first conventional cryptographic algorithm, an identifier of a first post-quantum cryptographic algorithm, a first signature, and a second signature.

[0257] S1305, the subscriber sends a certificate signing request to the CA.

[0258] S1306, CA verifies the first signature according to the first conventional cryptographic algorithm and verifies the second signature according to the first post-quantum cryptographic algorithm.

[0259] The specific implementation methods of S1301 to S1306 and Figure 4 In the corresponding embodiments, S401 to S406 are the same. For details, please refer to the detailed description of S401 to S406 above, which will not be repeated here.

[0260] S1307, if the first and second signatures pass verification, the CA constructs the extended field.

[0261] In this embodiment, the CA has two key pairs: a third key pair and a fourth key pair. The third key pair consists of a third public key pkCA1 and a third private key skCA1, while the fourth key pair consists of a fourth public key pkCA2 and a fourth private key skCA2. In this embodiment, the third key pair is generated using a third cryptographic algorithm, and the fourth key pair is generated using a second post-quantum cryptographic algorithm.

[0262] To ensure backward compatibility of the certificate, enabling both un-upgraded and upgraded devices to verify subscribers, the CA places the first public key in the public key information field of the certificate, the second public key in the extended field, the fourth signature in the extended field, and the third signature in the signature field on the CA's side.

[0263] Specifically, such as Figure 14 As shown, in the certificate provided in this application embodiment, the extended fields include a first target field, a first identifier field, a second target field, a second identifier field, a first cryptographic algorithm identifier field, and a second cryptographic algorithm identifier field. The information in the first target field indicates the second public key, and the first identifier field indicates the form of the second public key. The form of the second public key in the first target field can be the actual value of the second public key or the hash value of the second public key. The information in the second target field indicates the fourth signature, and the second identifier field indicates the form of the fourth signature. The form of the second public key can be the true value of the second public key or the hash value of the second public key. The form of the fourth signature can be the true value of the fourth signature or the hash value of the fourth signature.

[0264] As one possible implementation, such as Figure 14 As shown, the extended fields still include a hash algorithm identifier field, which is used to identify the hash algorithm.

[0265] In one possible implementation, in S1307, the extended fields constructed by the CA include a first target field that is the hash value of the second public key, and a first identifier field that contains first information. The second target field is the fourth signature, and the second identifier field contains second information. In this embodiment, the first information indicates that either the first or second target field is a hash value, and the second information indicates that either the first or second target field is a true value. Next, the CA invokes a second post-quantum cryptography algorithm to sign the first certificate information using the fourth private key, obtaining a fourth signature. The first certificate information includes extended field information and basic field information, and at this time, the second target field and second identifier field information in the extended fields are empty. The basic fields include version number, serial number, issuer, validity period, subscriber, and public key information. Then, the CA calculates the hash value of the fourth signature and places it in the second target field, while the second identifier field contains the first information. Thus, the CA can determine the second certificate information, which includes extended field and basic field information. Finally, the CA invokes a third cryptographic algorithm to sign the second certificate information using the third private key, obtaining a third signature.

[0266] For example, such as Figure 15 As shown, the CA performs a hash calculation on the second public key pkB using the hash algorithm algidhash, thus obtaining the hash value hashB. In the extended fields, the first target field is the hash value hashB of the second public key pkB, the hash algorithm identifier field is algidhash, and the identifier field is F. Here, F indicates that the information of the target field is in the form of a hash value. At this time, the information of the second target field, the second identifier field, and the second cryptographic algorithm identifier field in the extended fields is empty. Then, the CA calls the second post-quantum cryptographic algorithm algidCA2 and signs the certificate information 1 using the private key skCA2, obtaining the signature δCA2. The CA calculates the hash value hashD of the signature δCA2 and places it in the second target field, the second identifier field is F, and the second cryptographic algorithm identifier field is algidCA2. Finally, the CA signs the certificate information 2 using the third cryptographic algorithm algidCA1 and the third private key skCA1, obtaining the signature δCA1. Here, certificate information 2 includes the information of the extended fields and the information of the basic fields. At this time, the information of the second target field, the second identifier field, and the second cryptographic algorithm identifier field in the extended fields is not empty.

[0267] In another possible implementation, in S1307, the CA constructs an extended field where the first target field is the second public key, and the information in the first identifier field is the second information. Next, the CA obtains the first certificate information based on the extended field information and the basic field information. Here, the first certificate information includes the information in the basic fields and the extended fields of the certificate. The basic fields include version number, serial number, issuer, validity period, subscriber, and public key information. At this point, the information in the extended fields—the second target field, the second identifier field, and the second cryptographic algorithm identifier field—is empty. Then, the CA signs the first certificate information using the fourth private key through the second post-quantum cryptographic algorithm, obtaining the fourth signature. The CA calculates the hash value of the fourth signature and places it in the second target field, where the second identifier field is the first information. The first information is used to indicate the information in the target field in the form of a hash value. The second cryptographic algorithm identifier is the identifier of the second post-quantum cryptographic algorithm. Thus, the CA can determine the second certificate information, which includes the extended field information and the basic field information. At this point, the information in the extended fields—the second target field, the second identifier field, and the second cryptographic algorithm identifier field—is not empty. Finally, the CA uses a third cryptographic algorithm and a third private key to sign the second certificate information, thus obtaining a third signature.

[0268] It should be noted that the representation of the identifier field can be set according to the actual situation, and this application does not impose specific limitations. For example, F can be used to indicate that the information in the target field is the value after processing the second public key, and T can be used to indicate that the information in the target field is the second public key. Alternatively, 0 can be used to indicate that the information in the target field is the value after processing the second public key, and 1 can be used to indicate that the information in the target field is the second public key.

[0269] S1308, CA generates certificate.

[0270] After constructing the extended fields, the CA generates a certificate based on the information in the extended fields, the third signature, and the identifier of the third cryptographic algorithm.

[0271] For example, such as Figure 15 As shown, the CA generates a certificate based on the extended fields, the signature δCA1, and the identifier of the third cryptographic algorithm, algidCA1. Based on... Figure 15 The example shown can yield results such as Figure 16 The certificate shown Figure 16 Only partial certificate information is shown; information such as version number, serial number, issuer, validity period, and subscriber has been omitted. Information for the omitted fields can be generated according to the actual situation.

[0272] It is understood that, in addition to the information mentioned above, the extended fields may also include other information, which can be set according to actual needs. This application does not impose specific limitations on this.

[0273] S1309, the CA sends a certificate and a fourth signature to the subscriber.

[0274] The specific implementation of S1309 is the same as that of S909. For details, please refer to the detailed description of S909 in the above embodiments, which will not be repeated here.

[0275] S1310, the subscriber sends a certificate to the dependent.

[0276] Once a subscriber receives the certificate, it can send the certificate to the dependent party, enabling the dependent party to authenticate the subscriber's identity based on the certificate.

[0277] Since the capabilities of the physical devices corresponding to different dependent parties are different, in order to ensure backward compatibility, the subscriber determines whether to send the certificate to the dependent party after modifying the information in the target field and the identifier field of the certificate, based on the capabilities of the dependent party.

[0278] In one possible implementation, the subscriber is pre-configured with the capabilities of the dependencies. For example, the subscriber includes a list of capability information for the dependencies, which indicates the algorithmic capabilities supported by different dependencies.

[0279] In another possible implementation, the subscriber can confirm the capabilities of the dependent with the dependent in advance. For example, the dependent can send capability information to the subscriber in advance, whereby the capability information indicates the capabilities the dependent possesses. For instance, the capability information could be a set of identifiers of algorithms supported by the dependent itself, thus representing the dependent's capabilities through the algorithms it supports.

[0280] As one possible implementation, in the certificate, the first target field is the hash value of the second public key, the first identifier field is the first information, the second target field of the second public key is the fourth signature, and the second identifier information is the second information. Therefore, to ensure backward compatibility and reduce communication overhead, if the dependent party supports the first traditional cryptographic algorithm and the third cryptographic algorithm, but does not support the first and second post-quantum cryptographic algorithms, the subscriber directly sends the certificate to the dependent party to ensure backward compatibility and reduce communication overhead. For example, the certificate is as follows: Figure 16 As shown.

[0281] If the dependent party supports the first traditional cryptographic algorithm, the third cryptographic algorithm, and the second post-quantum cryptographic algorithm, but not the first post-quantum cryptographic algorithm, to ensure backward compatibility of the certificate and reduce communication overhead, the subscriber modifies the hash value of the fourth signature to the fourth signature and modifies the information in the second identifier field to the second information. Finally, the subscriber sends the modified certificate to the dependent party. For example, the modified certificate is as follows: Figure 17aAs shown.

[0282] If the dependent party supports the first traditional cryptographic algorithm, the first post-quantum cryptographic algorithm, and the third cryptographic algorithm, but not the second post-quantum cryptographic algorithm, to ensure backward compatibility of the certificate and reduce communication overhead, the subscriber modifies the hash value of the first target field to the second public key and the first identifier field to the second information. Finally, the subscriber sends the modified certificate to the dependent party. For example, the modified certificate is as follows: Figure 17b As shown.

[0283] If the dependent party supports the first traditional cryptographic algorithm, the first post-quantum cryptographic algorithm, the third cryptographic algorithm, and the second post-quantum cryptographic algorithm, to ensure backward compatibility of the certificate and reduce communication overhead, the subscriber modifies the hash value of the first target field to the second public key, the first identifier field to the second information, the hash value of the second target field to the fourth signature, and the second identifier field to the second information. Finally, the subscriber sends the modified certificate to the dependent party. For example, the modified certificate is as follows: Figure 17c As shown.

[0284] S1311, The dependent party verifies the validity of the certificate based on the information in the target field and the identification field of the certificate.

[0285] To ensure backward compatibility, the certificate's form varies during transmission, but the verification process for the relying party remains consistent. Specifically, first, the relying party needs to determine whether to modify the certificate based on its own capabilities. If the relying party's physical device supports the first traditional cryptographic algorithm but not the first post-quantum cryptographic algorithm, and the information in the first identifier field is the first information, then the relying party does not need to verify the value of the first target field. If the relying party's physical device supports both the first traditional cryptographic algorithm and the first post-quantum cryptographic algorithm, and the information in the first identifier field is the second information, then the relying party needs to call a hash algorithm to calculate the hash value corresponding to the truth value of the first target field and replace the truth value of the first target field in the certificate with the hash value. If the relying party's physical device supports the third cryptographic algorithm but not the second post-quantum cryptographic algorithm, and the information in the second identifier field is the first information, then the relying party does not need to verify the value of the second target field. If the relying party's physical device supports both the third cryptographic algorithm and the second post-quantum cryptographic algorithm, and the information in the second identifier field is the second information, then the relying party needs to call a hash algorithm to calculate the hash value corresponding to the truth value of the second target field and replace the truth value of the second target field in the certificate with the hash value.

[0286] Next, the relying party invokes the third cryptographic algorithm based on the identifier of the third cryptographic algorithm in the certificate, and uses the third public key to verify the certificate information and third signature in the certificate. If the verification is successful, the certificate verification is successful; otherwise, the certificate verification fails.

[0287] In some embodiments, where the relying party supports the second post-quantum cryptography algorithm, the relying party first verifies the third signature. If the third signature verification passes, the fourth signature is verified. Specifically, the second post-quantum cryptography algorithm is invoked, using the fourth public key, to verify the first certificate information and the fourth signature. The first signature information is detailed in S1307 and will not be repeated here. If both the third and fourth signatures pass verification, the certificate verification is successful. For example, as shown... Figure 12 As shown, after receiving the certificate, the dependent party calls the hash algorithm algidhash to hash the signature δCA2, obtaining the hash value hashD. It then modifies the signature δCA2 in the target field of the certificate to hashD and changes the second information "T" in the identifier field to the first information "F". Next, the dependent party calls the third cryptographic algorithm algidCA1, using the third public key pkCA1, to verify the second certificate information and the third signature δCA1 in the modified certificate. Then, if the third signature δCA1 is verified, it calls the second post-quantum cryptographic algorithm algidCA2, using the fourth public key pkCA2, to verify the first certificate information and the fourth signature δCA2. If the verification is successful, the certificate verification is successful.

[0288] In some embodiments, the information in the first target field and the information in the second target field of the certificate can be controlled by the same identifier field. For example, the first target field is a true value and the second target field is a true value, and the identifier field is second information, which indicates that both the information in the first target field and the information in the second target field are true values. Alternatively, the first target field is a hash value and the second target field is a hash value, and the identifier field is the first information. For example, such as... Figure 18a As shown, the first target field is the hash value of the second public key (hashB), the second target field is the hash value of the fourth signature (hashD), and the identifier field is the first information "F". The first information "F" identifies the form of the information in the first target field and the form of the information in the second target field as a hash value. For example, as... Figure 18b As shown, the first target field is the truth value pkB of the second public key, the second target field is the truth value δCA2 of the fourth signature, and the identifier field is the second information "T".

[0289] According to the embodiments of this application, the subscriber generates two key pairs using two different algorithms, and the CA generates two key pairs using two other different algorithms, enabling a single certificate to carry information related to the public keys corresponding to the two different algorithms. To ensure backward compatibility, the certificate's extended fields define a target field and an identifier field. The identifier field determines whether the target field information is true, allowing the subscriber's public key to be placed in the public key information field, and the CA's signature to be placed in the signature field on the CA's side. Additionally, the extended fields can display the hash value of the subscriber's other public key and another signature from the CA. The subscriber can adjust the format of the target field information based on the capabilities of the entity device corresponding to the dependent party. During certificate verification, the hash value is based on the format of the target field information. This ensures that the certificate has only one verification format, but multiple transmission formats. Different certificate formats correspond to dependent parties with different capabilities. Thus, for upgraded devices, the certificate transmission format is a true target field, i.e., a second public key, providing multiple security guarantees during signature verification. For un-upgraded devices, the certificate is transmitted with the target field being a hash value. Even if the un-upgraded device has unsupported cryptographic algorithms, it can still verify the certificate, ensuring backward compatibility. Moreover, transmitting the certificate with the target field as a hash value reduces communication overhead.

[0290] It should be noted that in the above embodiments, the third cryptographic algorithm is a cryptographic algorithm supported by the dependent party. The first and second post-quantum cryptographic algorithms are different post-quantum cryptographic algorithms. The third cryptographic algorithm can be a traditional cryptographic algorithm or a post-quantum cryptographic algorithm, depending on the actual situation. This application does not specifically limit this.

[0291] Based on the same concept as the above-described method embodiments, this application provides a certificate issuance method.

[0292] Figure 19 This application provides a certificate issuance method. The certificate issuance method provided in this application is applied to a first device. In this application embodiment, the first device can be the CA described in the above embodiments. Figure 19 As shown, the certificate verification method provided in this application includes the following steps S1901 to S1903.

[0293] S1901, Obtain the first public key of the second device, wherein the first public key is a public key generated based on the first algorithm.

[0294] The first algorithm refers to the traditional cryptographic algorithms supported by the second device. In the above... Figures 4 to 1 In the embodiment shown in 8, the first algorithm may include a first conventional cryptographic algorithm.

[0295] S1902, Generate a certificate. The certificate includes a public key information field and an extended field. The public key information field indicates the first public key. The extended field includes a target field and an identifier field. The target field indicates the target information, which is generated based on the second algorithm. The identifier field indicates the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms.

[0296] The second algorithm indicates a post-quantum cryptographic algorithm. The first and second algorithms are two different types of cryptographic algorithms. In the above... Figures 4 to 1 In the embodiment shown in 8, the second algorithm may include a first post-quantum cryptography algorithm and a second post-quantum cryptography algorithm, and the third cryptography algorithm may be either the first algorithm or the second algorithm.

[0297] In some embodiments, the first device can also obtain a second public key from the second device, the second public key being a public key generated based on a second algorithm. Specifically, the second algorithm includes a first sub-algorithm, and the second public key is a public key generated based on the first sub-algorithm. Exemplarily, the first sub-algorithm may be the first post-quantum cryptography algorithm described in the above embodiments.

[0298] In this embodiment, the target information in the target field is used to indicate the second public key. The target information is in the form of a hash value; that is, the target field is the hash value of the second public key, and the identifier field is the second information. The second information indicates that the target information is in the form of a hash value. For a detailed implementation of this embodiment, please refer to the above. Figure 4 The implementation process of S401 to S408 in the illustrated embodiment will not be described in detail here.

[0299] In other embodiments, the target information is a fourth signature, which is a signature generated by the second algorithm. In this embodiment, the second algorithm is a second sub-algorithm. Specifically, the first device can generate a fourth key pair based on the second sub-algorithm, the fourth key pair including a fourth public key and a fourth private key. The first device signs the first certificate information using the fourth private key according to the second sub-algorithm. The specific implementation process of this embodiment can be found above. Figure 9 The implementation process of S901 to S908 in the illustrated embodiment will not be described in detail here.

[0300] In some embodiments, the extended field may include at least one target field, and different target fields may indicate different second algorithms corresponding to the target information. Thus, by placing information about different second algorithms in different target fields, the certificate achieves backward compatibility, requiring only one certificate to verify its validity for devices with varying capabilities.

[0301] The format of the target information in the extended fields is identified by an identifier field. In some embodiments, the extended fields may include at least one identifier field. For example, when the format of the target information in multiple target fields is the same, the extended fields may include an identifier field that can identify the format of the target information in multiple target fields, thereby saving communication overhead. As another example, the extended fields may include multiple identifier fields, with each identifier field corresponding one-to-one with a target field. In this way, the format of the target information in the certificate can change, thereby enabling backward compatibility of the certificate.

[0302] For example, the target field includes a first target field and a second target field, the target information includes first target information and second target information, and the post-quantum cryptography algorithm includes a first post-quantum cryptography algorithm and a second post-quantum cryptography algorithm; in this case, the above method further includes: obtaining a second public key of the second device, the second public key being a public key generated based on the first post-quantum cryptography algorithm;

[0303] The first target field is used to indicate the first target information, which is information generated by the first post-quantum cryptography algorithm. The first target information is used to indicate the second public key, which is the second public key or the hash value of the second public key. The second target field is used to indicate the second target information, which is information generated by the second post-quantum cryptography algorithm. The second target information is the fourth signature, which is a signature generated by the second post-quantum cryptography algorithm.

[0304] Furthermore, the identification field includes a first identification field and a second identification field. The first identification field indicates the form of the first target information, and the second identification field indicates the form of the second target information. Alternatively, when the first target information is a second public key and the second target information is a fourth signature, the identification field indicates the form of both the first and second target information. For a detailed implementation of this embodiment, please refer to the above. Figure 13 The implementation process of S1301 to S1308 in the illustrated embodiment will not be described in detail here.

[0305] In some embodiments, the extended field further includes a hash algorithm identifier field, which indicates the identifier of the hash algorithm used to calculate the hash value of the target information. See the above for details. Figure 4 , Figure 9 or Figure 13 The definition of extended fields will not be elaborated here.

[0306] In some embodiments, the extended field further includes an algorithm identifier field, which is used to indicate the identifier corresponding to the second algorithm. See the above for details. Figure 4 , Figure 9 or Figure 13The definition of extended fields will not be elaborated here.

[0307] S1903, send the certificate to the second device.

[0308] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0309] Figure 20 This application provides a certificate adjustment method. The certificate adjustment method provided in this application is applied to a second device. The second device can be a subscriber as shown in the above embodiments. Figure 20 As shown, the certificate adjustment method provided in this application embodiment includes the following steps S2001 to S2003.

[0310] S2001, Obtain a certificate. The certificate includes a public key information field and an extended field. The public key information field indicates the first public key, which is a public key generated based on the first algorithm. The extended field includes a target field and an identifier field. The target field indicates the target information, which is information generated based on the second algorithm. The identifier field indicates the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms.

[0311] The certificate is issued by the first device. The first public key is a public key generated by the second device based on the first algorithm. For details on the first algorithm, please refer to the detailed explanation of S1901 in the above embodiments; it will not be repeated here.

[0312] S2002, adjust the form of the target information according to the capability information of the third device. The capability information is used to indicate the algorithm supported by the third device.

[0313] The capability information of the third device is obtained from the third device itself. This capability information indicates the cryptographic algorithms supported by the third device. One possible implementation is that the capability information is pre-configured in the second device, which can update it periodically. Another possible implementation is that the second device can request the third device's capability information in real time.

[0314] After receiving the certificate, the second device can adjust the format of the target information based on the capability information of the third device, thus enabling the certificate to have different transmission formats. Different transmission formats correspond to third devices with different capabilities. This achieves backward compatibility for the third device; only one certificate is needed, and both upgraded and un-upgraded devices can verify it.

[0315] In some embodiments, S2002 may include the following steps: if the capability information of the third device indicates that the third device supports the second algorithm, adjust the target information to a true value; if the capability information of the third device indicates that the third device does not support the second algorithm, adjust the form of the target information to a hash value.

[0316] Specifically, in one possible implementation, the second algorithm is the first sub-algorithm, and the extended fields also include a hash algorithm identifier field, which is used to indicate the identifier of the hash algorithm.

[0317] Before the certificate is adjusted, the target information is the second public key, which is a public key generated by the second device based on the first sub-algorithm. The identifier field is the second information, and the first information is used to indicate that the target information in the target field is a true value. If the capability information of the third device indicates that the third device does not support the second algorithm, the hash algorithm is called to calculate the hash value of the second public key based on the identifier in the hash algorithm identifier field. The second public key in the certificate is then adjusted to its hash value, and the second information is modified to the first information, which indicates that the target information in the target field is a hash value. The above process can be found in [reference needed]. Figure 4 The detailed implementation process of S410 in the corresponding embodiment will not be repeated here.

[0318] In another possible implementation, the second algorithm is a second sub-algorithm, and the extended fields also include a hash algorithm identifier field, which is used to indicate the identifier of the hash algorithm.

[0319] Before the certificate is adjusted, the target information is the fourth signature, the second public key is the public key generated by the second device based on the first sub-algorithm, the identifier field is the second information, and the first information is used to indicate that the target information in the target field is a true value. If the third device's capability information indicates that the third device does not support the second algorithm, the hash algorithm is called to calculate the hash value of the fourth signature based on the identifier in the hash algorithm identifier field. The fourth signature in the certificate is then adjusted to be the hash value of the fourth signature, and the second information is modified to the first information, which is used to indicate that the target information in the target field is a hash value. The above process can be found in [reference needed]. Figure 4 The detailed implementation process of S910 in the corresponding embodiment will not be repeated here.

[0320] In another possible implementation, before adjusting the certificate, the target fields include a first target field and a second target field, the target information includes first target information and second target information, and the second algorithm includes a first sub-algorithm and a second sub-algorithm. For details on the first and second sub-algorithms, please refer to the detailed description of S1902 in the above embodiments; it will not be repeated here.

[0321] If the third device supports both the first and second sub-algorithms, adjust both the first and second target information to true. If the third device does not support either the first or second sub-algorithms, adjust both the first and second target information to hash values. If the third device supports the first sub-algorithm but not the second, adjust both the first and second target information to hash values. If the third device does not support the first sub-algorithm but supports the second, adjust both the first and second target information to hash values. The above process can be found in [reference needed]. Figure 4 The detailed implementation process of S910 in the corresponding embodiment will not be repeated here.

[0322] Here, adjusting the form of target information includes adjusting target information to target information, adjusting target information to the hash value of target information, adjusting the hash value of target information to target information, and adjusting the hash value of target information to the hash value of target information.

[0323] S2003, send the adjusted certificate to the third device.

[0324] According to embodiments of this application, different key pairs are generated using two different algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field determines whether the information in the target field is true, thus allowing at least one public key to be placed in the extended fields in addition to the public key information field. The second device can adjust the format of the target field information based on the capabilities of the entity device corresponding to the third device, thereby transmitting certificates in different formats. This ensures that the certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to third devices with different capabilities, ensuring backward compatibility and enabling both upgraded and non-upgraded devices to verify the validity of the certificate.

[0325] Figure 21 This application provides a certificate verification method. The certificate verification method provided in this application is applied to a second device. For example... Figure 21 As shown, the certificate verification method provided in this application includes the following steps S2101 to S2103.

[0326] S2101, Obtain a certificate, wherein the certificate includes a public key information field and an extended field. The public key information field is used to indicate a first public key, which is a public key generated based on a first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate target information, which is information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The form of the target information is associated with the capability information of a third device. The capability information is used to indicate the algorithms supported by the third device. The first algorithm and the second algorithm are different types of algorithms.

[0327] For detailed descriptions of the first and second algorithms, please refer to the descriptions of S1901 and S1902 in the above embodiments, which will not be repeated here.

[0328] S2102 verifies the validity of the certificate based on the hash value of the first public key and the target information.

[0329] In some embodiments, the third device supports the second algorithm, and the target information in the certificate is in the form of a true value. In step S2102, the following process may be included: calculating the hash value of the target information by calling the hash algorithm according to its identifier; adjusting the target information in the certificate to its hash value; and verifying the certificate based on the first public key and the hash value of the target information. This ensures that the certificate has only one verification form, thereby guaranteeing backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0330] For the specific implementation process described above, please refer to the above. Figure 4 S411 Figure 9 S911 or Figure 13 The specific implementation process of S1311 will not be elaborated here.

[0331] In some embodiments, the certificate further includes a signature field for indicating a third signature, which is a signature generated based on a third sub-algorithm and the hash value of the target information, wherein the first algorithm includes the third sub-algorithm; in this case, S2102 may include the following process: invoking the third sub-algorithm to verify the validity of the certificate based on the first public key, the third signature, and the hash value of the target information.

[0332] In this way, when verifying the validity of a certificate, the hash value of the target information is used for verification, ensuring that the certificate has only one verification form. This guarantees backward compatibility of the certificate, and with only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0333] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0334] Based on the same concept as the method embodiments of this application, this application also provides a certificate verification device. The certificate verification device includes several modules, each module being used to execute various steps in the certificate verification method provided in this application. The division of modules is not limited here. Those skilled in the art will clearly understand that in practical applications, the various steps in the certificate verification method provided in this application can be assigned to different modules as needed, that is, the internal structure of the device can be divided into different modules to complete all or part of the functions described above. The modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more modules can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the modules in the above device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0335] For example, the certificate verification device is used to perform the certificate verification method provided in the embodiments of this application.

[0336] Figure 22 This is a schematic diagram of the certificate verification device 2200 provided in an embodiment of this application. The certificate verification device 2200 provided in this embodiment is used to execute the method steps executed by the first device in the above embodiment. Figure 22 As shown, the certificate verification device 2200 provided in this application embodiment includes:

[0337] Module 2201 is used to obtain the first public key, which is a public key generated based on the first algorithm.

[0338] The generation module 2202 is used to generate a certificate. The certificate includes a public key information field and an extended field. The public key information field is used to indicate the first public key. The extended field includes a target field and an identifier field. The target field is used to indicate target information, which is information generated based on the second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms.

[0339] The sending module 2203 is used to send a certificate to the second device.

[0340] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0341] In one possible implementation, the acquisition module is also used to acquire a second public key, which is a public key generated based on a second algorithm;

[0342] The target information is used to indicate the second public key or the hash value of the second public key.

[0343] In this way, it can be ensured that there is only one verification form for the certificate, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, thereby ensuring backward compatibility of the certificate, enabling both upgraded and non-upgraded devices to verify the validity of the certificate.

[0344] In one possible implementation, the target information is used to indicate a fourth signature, which is a signature generated by a second algorithm.

[0345] In this way, it can be ensured that there is only one verification form for the certificate, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, thereby ensuring backward compatibility of the certificate, enabling both upgraded and non-upgraded devices to verify the validity of the certificate.

[0346] In one possible implementation, the extended field includes at least one target field, and different target fields indicate different second algorithms corresponding to the target information.

[0347] In this way, the certificate can contain target information generated by multiple second algorithms, thereby ensuring backward compatibility of the certificate. For devices that support different second algorithms, with only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0348] In one possible implementation, the extended fields include at least one identifier field.

[0349] In this way, the form of the target information in the certificate can be changed, thus enabling backward compatibility. Furthermore, identifying multiple target fields with a single identifier field saves communication overhead.

[0350] In one possible implementation, where the extended fields include multiple target fields and multiple identifier fields, the identifier fields correspond one-to-one with the target fields.

[0351] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm used to calculate the hash value of the target information.

[0352] In one possible implementation, the extended fields also include an algorithm identifier field, which is used to indicate the identifier corresponding to the second algorithm.

[0353] In one possible implementation, the certificate also includes a signature field, which indicates a third signature, generated based on a third sub-algorithm and the hash value of the target information.

[0354] The first algorithm includes a third sub-algorithm.

[0355] Figure 23 This is a schematic diagram of the certificate adjustment device 2300 provided in an embodiment of this application. The certificate adjustment device 2300 provided in this embodiment is used to execute the method steps performed by the second device in the above embodiment. Figure 23 As shown, the certificate adjustment device 2300 provided in this application embodiment includes:

[0356] The acquisition module 2301 is used to acquire a certificate, which includes a public key information field, an extended field, and a signature field. The extended field includes a target field and an identifier field. The public key information field is used to indicate the first public key. The target field is used to indicate target information, which is information generated based on a post-quantum cryptography algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The signature field is used to indicate the third signature of the CA, which is a signature generated by a third cryptographic algorithm.

[0357] The adjustment module 2302 is used to adjust the form of the target information according to the capability information of the dependent party;

[0358] Sending module 2303 is used to send the adjusted certificate to the dependent party.

[0359] The acquisition module 2301 is used to acquire a certificate. The certificate includes a public key information field and an extended field. The public key information field is used to indicate a first public key, which is a public key generated based on a first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate target information, which is information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms.

[0360] The adjustment module 2302 is used to adjust the form of the target information according to the capability information of the third device, wherein the capability information is used to indicate the algorithms supported by the third device;

[0361] The sending module 2303 is used to send the adjusted certificate to a third device.

[0362] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0363] In one possible implementation, adjustment module 2302 is used for:

[0364] If the capability information of the third device indicates that the third device supports the second algorithm, adjust the target information to a true value.

[0365] If the capability information of the third device indicates that the third device does not support the second algorithm, the form of the target information is adjusted to a hash value.

[0366] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0367] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm used to calculate the hash value of the target information.

[0368] In one possible implementation, the second algorithm includes a first sub-algorithm. Before adjusting the certificate, the target information is a second public key, which is a public key generated by the second device based on the first sub-algorithm. The identification field is second information, which is used to indicate that the target information in the target field is a true value.

[0369] When the capability information of the third device indicates that the third device does not support the second algorithm, the adjustment module 2302 is used to:

[0370] Based on the identifier in the hash algorithm identifier field, the hash algorithm is called to calculate the hash value of the second public key;

[0371] Adjust the second public key in the certificate to the hash value of the second public key, and modify the second information to the first information. The first information is used to indicate that the target information in the target field is in the form of a hash value.

[0372] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0373] In one possible implementation, the second algorithm includes a second sub-algorithm, the target information is a fourth signature before the certificate is adjusted, the second public key is a public key generated by the second device based on the second sub-algorithm, the identification field is the second information, and the first information is used to indicate that the form of the target information in the target field is a true value.

[0374] When the capability information of the third device indicates that the third device does not support the second algorithm, the adjustment module 2302 is used to:

[0375] Based on the identifier in the hash algorithm identifier field, the hash algorithm is called to calculate the hash value of the fourth signature;

[0376] Adjust the fourth signature in the certificate to the hash value of the fourth signature, and modify the second information to the first information. The first information is used to indicate that the target information in the target field is in the form of a hash value.

[0377] In this way, the second device can adjust the format of the target information according to the capabilities of the third device, thereby transmitting certificates in different formats. This ensures that a certificate has only one verification format, but multiple transmission formats. Different certificate formats can correspond to second devices with different capabilities, thus ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0378] Figure 24 This is a schematic diagram of the certificate verification device 2400 provided in an embodiment of this application. The certificate verification device 2400 provided in this embodiment is used to execute the method steps executed by the third device in the above embodiment. Figure 24 As shown, the certificate verification device 2400 provided in this application embodiment includes:

[0379] The acquisition module 2401 is used to acquire a certificate, wherein the certificate includes a public key information field and an extended field. The public key information field is used to indicate a first public key, which is a public key generated based on a first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate target information, which is information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The form of the target information is associated with the capability information of a third device. The capability information is used to indicate the algorithms supported by the third device. The first algorithm and the second algorithm are different types of algorithms.

[0380] Verification module 2402 is used to verify the validity of the certificate based on the hash value of the first public key and the target information.

[0381] According to embodiments of this application, information such as a first public key and target information are generated using two different types of algorithms, enabling a single certificate to carry information related to public keys corresponding to multiple different types of algorithms. To ensure backward compatibility, a target field and an identifier field are defined in the certificate's extended fields. The identifier field is used to determine whether the information in the target field is true, thus allowing the placement of target information generated by another type of algorithm in the extended fields, in addition to the public key information field. The second device can adjust the form of the target information according to the capabilities of the third device, thereby transmitting certificates in different forms. This ensures that the certificate has only one verification form, but multiple transmission forms. Different certificate forms can correspond to second devices with different capabilities, ensuring backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0382] In one possible implementation, the extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm. The third device supports the second algorithm, the target information in the certificate is in the form of a true value, and the verification module is used for:

[0383] Based on the identifier of the hash algorithm, the hash algorithm is invoked to calculate the hash value of the target information;

[0384] Adjust the target information in the certificate to the hash value of the target information;

[0385] The certificate is verified based on the hash value of the first public key and the target information.

[0386] This ensures that there is only one verification form for the certificate, thus guaranteeing backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0387] In one possible implementation, the certificate also includes a signature field that indicates a third signature, which is a signature generated based on a third sub-algorithm according to the hash value of the target information, and the first algorithm includes the third sub-algorithm.

[0388] The verification module is used for:

[0389] The third sub-algorithm is invoked to verify the validity of the certificate based on the hash value of the first public key, the third signature, and the target information.

[0390] This ensures that there is only one verification form for the certificate, thus guaranteeing backward compatibility. With only one certificate, both upgraded and non-upgraded devices can verify the validity of the certificate.

[0391] Based on the same concept as the method embodiments of this application, this application also provides a computing device. The computing device provided in this application can be a first device, a second device, or a third device. The first device, the second device, and the third device communicate with each other. This computing device can be a server, a host, a computer, or other similar device.

[0392] Figure 25 This is a schematic diagram of the hardware structure of a computing device 2500 provided in an embodiment of this application.

[0393] See Figure 25 The computing device 2500 includes a chip 2501, a memory 2502, a communication interface 2503, and a bus 2504. The chip 2501, memory 2502, and communication interface 2503 are connected to each other via the bus 2504. The chip 2501, memory 2502, and communication interface 2503 can also be connected using other connection methods besides the bus 2504.

[0394] The memory 2502 can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, optical storage, hard disk, etc.

[0395] Chip 2501 can be the aforementioned System-on-a-Chip (SOC), which may include a processor and a connector. The processor can be a general-purpose processor. A general-purpose processor can be a processor that performs specific steps and / or operations by reading and executing contents stored in memory (e.g., memory 2502). For example, a general-purpose processor can be a central processing unit (CPU). Chip 2501 may include at least one circuit to perform... Figure 19 The illustrated embodiment Figure 20 The illustrated embodiments or Figure 21 The illustrated embodiments provide all or part of the steps of the method.

[0396] The communication interface 2503 includes input / output (I / O) interfaces, physical interfaces, and logical interfaces for interconnecting devices within the computing device 2500, as well as interfaces for interconnecting the computing device 2500 with other devices (such as other computing devices or user equipment). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.

[0397] The bus 2504 can be any type of communication bus used to interconnect the chip 2501, memory 2502 and communication interface 2503, such as a system bus.

[0398] The aforementioned devices can be disposed on separate chips, or at least partially or entirely on the same chip. Whether to dispose of the devices independently on different chips or integrate them on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0399] Figure 25 The computing device 2500 shown is merely exemplary. In its implementation, the computing device 2500 may also include other components, which will not be listed here.

[0400] based on Figure 2 In addition to the method shown, this application also provides a computing device cluster.

[0401] Figure 26 This is a computing device cluster 2600 provided in an embodiment of this application. For example... Figure 26 As shown, the computing device cluster includes at least one computing device 2500. The memory 2502 of one or more computing devices 2500 in the computing device cluster may store the same memory for executing... Figure 19 , Figure 20 or Figure 21 The instructions for the method are shown. Exemplarily, modules in the certificate verification device 2200 can be deployed on a single computing device 2500 or distributed across multiple computing devices 2500. In the distributed deployment case, the acquisition module 2201 can be deployed on a single computing device or distributed across multiple computing devices 2500; the generation module 2202 can also be deployed on a single computing device 2500 or distributed across multiple computing devices 2500; the sending module 2203 can also be deployed on a single computing device 2500 or distributed across multiple computing devices 2500. Alternatively, as another example, modules in the certificate verification device 2300 can be deployed on a single computing device 2500 or distributed across multiple computing devices 2500. In a distributed deployment scenario, the acquisition module 2301 can be deployed on one computing device or distributed across multiple computing devices 2500; the adjustment module 2302 can also be deployed on one computing device 2500 or distributed across multiple computing devices 2500; the sending module 2303 can also be deployed on one computing device 2500 or distributed across multiple computing devices 2500.

[0402] The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0403] In some possible implementations, the memory 2502 of one or more computing devices 2500 in the computing device cluster may also store memory for execution. Figure 19 , Figure 20 or Figure 21 The instructions for the method shown are partial. In other words, a combination of one or more computing devices 2500 can coexist for executing... Figure 19 , Figure 20 or Figure 21 The instructions for the method shown.

[0404] It should be noted that the memory 2502 in different computing devices 2500 within the computing device cluster can store different instructions, each for execution. Figure 22 , Figure 23 or Figure 24 The illustrated device performs some of its functions. Specifically, the instructions stored in the memory 2502 of different computing devices 2500 can implement... Figure 22 , Figure 23 or Figure 24 The function of one or more modules in the device shown.

[0405] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 27 One possible implementation is shown. For example... Figure 27 As shown, the two computing devices 2500A and 2500B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 2502 in computing device 2500A stores instructions for implementing the function of the acquisition module 501. Simultaneously, the memory 2502 in computing device 2500B stores instructions for implementing the function of the determination module 502.

[0406] It should be understood that Figure 27 The functions of computing device 2500A shown can also be performed by multiple computing devices 2500. Similarly, the functions of computing device 2500B can also be performed by multiple computing devices 2500.

[0407] In addition to the methods, apparatus, and computing devices described above, embodiments of this application also provide a computer program product, comprising computer program instructions. When executed by a processor, these computer program instructions cause the processor to perform the steps of the methods in the various embodiments of this application described in the "Method" section of this specification. The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The computer program code can be in source code form, object code form, executable file, or some intermediate form. The computer program code can be executed entirely on a user's computing device, partially on a user's device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0408] Furthermore, embodiments of this application also provide a computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps of the display control method according to various embodiments of this disclosure as described in the "Method" section above. The computer-readable storage medium can be any combination of one or more readable media. A readable medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, including but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. It should be noted that the content contained in the computer-readable medium can be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, a computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0409] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0410] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. It should be understood that in the embodiments of this application, the order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0411] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A certificate issuing method characterized by, Applied to the first device, including: Obtain the first public key, which is a public key generated based on the first algorithm; A certificate is generated, the certificate including a public key information field and an extended field. The public key information field is used to indicate the first public key. The extended field includes a target field and an identifier field. The target field is used to indicate target information, the target information being information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, the form of the target information including a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms. Send the certificate to the second device.

2. The method of claim 1, wherein, The method further includes: Obtain the second public key, which is a public key generated based on the second algorithm; The target information is used to indicate the second public key or the hash value of the second public key.

3. The method according to claim 1 or 2, characterized in that, The target information is used to indicate a fourth signature, which is a signature generated by the second algorithm.

4. The method according to any one of claims 1 to 3, characterized in that, The extended fields include at least one of the target fields, and the second algorithm corresponding to the target information indicated by different target fields is different.

5. The method of claim 4, wherein, The extended fields include at least one of the identification fields.

6. The method of claim 5, wherein, When the extended field includes multiple target fields and multiple identifier fields, the identifier field corresponds one-to-one with the target field.

7. The method according to any one of claims 1 to 6, characterized in that, The extended fields also include a hash algorithm identifier field, which is used to indicate the identifier of the hash algorithm used to calculate the hash value of the target information.

8. The method according to any one of claims 1-7, characterized in that, The extended fields also include an algorithm identifier field, which is used to indicate the identifier corresponding to the second algorithm.

9. The method according to any one of claims 1-8, characterized in that, The certificate also includes a signature field, which indicates a third signature, which is a signature generated based on the hash value of the target information using a third sub-algorithm. The first algorithm includes the third sub-algorithm.

10. A certificate adjustment method, characterized in that, Applied to a second device, including: Obtain a certificate, the certificate including a public key information field and an extended field, the public key information field being used to indicate a first public key, the first public key being a public key generated based on a first algorithm, the extended field including a target field and an identifier field, the target field being used to indicate target information, the target information being information generated based on a second algorithm, the identifier field being used to indicate the form of the target information, the form of the target information including a truth value and a hash value, the first algorithm and the second algorithm being different types of algorithms; The form of the target information is adjusted according to the capability information of the third device, wherein the capability information is used to indicate the algorithms supported by the third device; The adjusted certificate is sent to the third device.

11. The method according to claim 10, characterized in that, Adjusting the form of the target information based on the capability information of the third device includes: If the capability information of the third device indicates that the third device supports the second algorithm, the target information is adjusted to a true value; If the capability information of the third device indicates that the third device does not support the second algorithm, the form of the target information is adjusted to a hash value.

12. The method according to claim 11, characterized in that, The extended fields also include a hash algorithm identifier field, which is used to indicate the identifier of the hash algorithm used to calculate the hash value of the target information.

13. The method according to claim 12, characterized in that, The second algorithm includes a first sub-algorithm. Before adjusting the certificate, the target information is a second public key, which is a public key generated by the second device based on the first sub-algorithm. The identifier field is second information, which is used to indicate that the target information in the target field is a true value. When the capability information of the third device indicates that the third device does not support the second algorithm, adjusting the form of the target information to a hash value includes: Based on the identifier in the hash algorithm identifier field, the hash algorithm is invoked to calculate the hash value of the second public key; The second public key in the certificate is adjusted to the hash value of the second public key, and the second information is modified to the first information, wherein the first information is used to indicate that the target information in the target field is in the form of a hash value.

14. The method according to claim 12 or 13, characterized in that, The second algorithm includes a second sub-algorithm. Before adjusting the certificate, the target information is a fourth signature. The second public key is a public key generated by the second device based on the second sub-algorithm. The identifier field is second information. The first information is used to indicate that the form of the target information in the target field is a true value. When the capability information of the third device indicates that the third device does not support the second algorithm, adjusting the form of the target information to a hash value includes: Based on the identifier in the hash algorithm identifier field, the hash algorithm is invoked to calculate the hash value of the fourth signature; The fourth signature in the certificate is adjusted to the hash value of the fourth signature, and the second information is modified to the first information, wherein the first information is used to indicate that the target information in the target field is in the form of a hash value.

15. A certificate verification method, characterized in that, Applied to third-party devices, including: Obtain a certificate, wherein the certificate includes a public key information field and an extended field. The public key information field is used to indicate a first public key, which is a public key generated based on a first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate target information, which is information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The form of the target information is associated with the capability information of the third device. The capability information is used to indicate the algorithms supported by the third device, wherein the first algorithm and the second algorithm are different types of algorithms. The validity of the certificate is verified based on the hash value of the first public key and the target information.

16. The method according to claim 15, characterized in that, The extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm. The third device supports the second algorithm, the target information in the certificate is in the form of a true value, and the verification of the certificate based on the first public key and the hash value of the target information includes: Based on the identifier of the hash algorithm, the hash algorithm is invoked to calculate the hash value of the target information; Adjust the target information in the certificate to the hash value of the target information; The certificate is verified based on the hash value of the first public key and the target information.

17. The method according to claim 15 or 16, characterized in that, The certificate also includes a signature field, which indicates a third signature. The third signature is a signature generated based on a third sub-algorithm and the hash value of the target information. The first algorithm includes the third sub-algorithm. The verification of the certificate's validity based on the hash value of the first public key and the target information includes: The third sub-algorithm is invoked to verify the validity of the certificate based on the hash value of the first public key, the third signature, and the target information.

18. A certificate issuing device, characterized in that, Applied to the first device, including: The acquisition module is used to acquire the first public key, which is a public key generated based on the first algorithm; A generation module is used to generate a certificate, the certificate including a public key information field and an extended field. The public key information field is used to indicate the first public key. The extended field includes a target field and an identifier field. The target field is used to indicate target information, the target information being information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, the form of the target information including a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms. The sending module is used to send the certificate to the second device.

19. The apparatus according to claim 18, characterized in that, The acquisition module is further configured to acquire a second public key, which is a public key generated based on the second algorithm; The target information is used to indicate the second public key or the hash value of the second public key.

20. The apparatus according to claim 18 or 19, characterized in that, The target information is used to indicate a fourth signature, which is a signature generated by the second algorithm based on the hash value of the target information.

21. The apparatus according to any one of claims 18-20, characterized in that, The extended fields include at least one of the target fields, and the second algorithm corresponding to the target information indicated by different target fields is different.

22. The apparatus according to claim 21, characterized in that, The extended fields include at least one of the identification fields.

23. The apparatus according to claim 22, characterized in that, When the extended field includes multiple target fields and multiple identifier fields, the identifier field corresponds one-to-one with the target field.

24. The apparatus according to any one of claims 18-23, characterized in that, The extended fields also include a hash algorithm identifier field, which is used to indicate the identifier of the hash algorithm used to calculate the hash value of the target information.

25. The apparatus according to any one of claims 18-24, characterized in that, The extended fields also include an algorithm identifier field, which is used to indicate the identifier corresponding to the second algorithm.

26. The apparatus according to any one of claims 18-25, characterized in that, The certificate also includes a signature field, which indicates a third signature, which is a signature generated based on the hash value of the target information using a third sub-algorithm. The first algorithm includes the third sub-algorithm.

27. A certificate adjustment device, characterized in that, Applied to a second device, including: An acquisition module is used to acquire a certificate, the certificate including a public key information field and an extended field. The public key information field is used to indicate a first public key, which is a public key generated based on a first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate target information, which is information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The first algorithm and the second algorithm are different types of algorithms. An adjustment module is used to adjust the form of the target information according to the capability information of the third device, wherein the capability information is used to indicate the algorithms supported by the third device; The sending module is used to send the adjusted certificate to the third device.

28. The apparatus according to claim 27, characterized in that, The adjustment module is used for: If the capability information of the third device indicates that the third device supports the second algorithm, the target information is adjusted to a true value; If the capability information of the third device indicates that the third device does not support the second algorithm, the form of the target information is adjusted to a hash value.

29. The apparatus according to claim 28, characterized in that, The extended fields also include a hash algorithm identifier field, which is used to indicate the identifier of the hash algorithm used to calculate the hash value of the target information.

30. The apparatus according to claim 29, characterized in that, The second algorithm includes a first sub-algorithm. Before adjusting the certificate, the target information is a second public key, which is a public key generated by the second device based on the first sub-algorithm. The identifier field is second information, which is used to indicate that the target information in the target field is a true value. The adjustment module is used for: Based on the identifier in the hash algorithm identifier field, the hash algorithm is invoked to calculate the hash value of the second public key; The second public key in the certificate is adjusted to the hash value of the second public key, and the second information is modified to the first information, wherein the first information is used to indicate that the target information in the target field is in the form of a hash value.

31. The apparatus according to claim 29 or 30, characterized in that, The second algorithm includes a second sub-algorithm. Before adjusting the certificate, the target information is a fourth signature. The second public key is a public key generated by the second device based on the second sub-algorithm. The identifier field is second information. The first information is used to indicate that the form of the target information in the target field is a true value. The adjustment module is used for: Based on the identifier in the hash algorithm identifier field, the hash algorithm is invoked to calculate the hash value of the fourth signature; The fourth signature in the certificate is adjusted to the hash value of the fourth signature, and the second information is modified to the first information, wherein the first information is used to indicate that the target information in the target field is in the form of a hash value.

32. A certificate verification device, characterized in that, Applied to third-party devices, including: An acquisition module is used to acquire a certificate, wherein the certificate includes a public key information field and an extended field. The public key information field is used to indicate a first public key, which is a public key generated based on a first algorithm. The extended field includes a target field and an identifier field. The target field is used to indicate target information, which is information generated based on a second algorithm. The identifier field is used to indicate the form of the target information, which includes a truth value and a hash value. The form of the target information is associated with the capability information of the third device. The capability information is used to indicate the algorithms supported by the third device, wherein the first algorithm and the second algorithm are different types of algorithms. The verification module is used to verify the validity of the certificate based on the hash value of the first public key and the target information.

33. The apparatus according to claim 32, characterized in that, The extended fields also include a hash algorithm identifier field, which indicates the identifier of the hash algorithm. The third device supports the second algorithm, the target information in the certificate is in the form of a true value, and the verification module is used for: Based on the identifier of the hash algorithm, the hash algorithm is invoked to calculate the hash value of the target information; Adjust the target information in the certificate to the hash value of the target information; The certificate is verified based on the hash value of the first public key and the target information.

34. The apparatus according to claim 32 or 33, characterized in that, The certificate also includes a signature field, which indicates a third signature. The third signature is a signature generated based on a third sub-algorithm and the hash value of the target information. The first algorithm includes the third sub-algorithm. The verification module is used to call the third sub-algorithm to verify the validity of the certificate based on the hash value of the first public key, the third signature, and the target information.

35. A certificate verification system, characterized in that, include: A first device is configured to perform the method as described in any one of claims 1 to 9; A second device, communicating with the first device, is configured to perform the method as described in any one of claims 10 to 14; A third device, communicating with the first and second devices, is used to perform the method as described in any one of claims 15 to 17.

36. A computing device, comprising a memory and a processor, characterized in that, The memory stores executable code, and when the processor executes the executable code, it performs the method as described in any one of claims 1 to 9, or the method as described in any one of claims 10 to 14, or the method as described in any one of claims 15 to 17.

37. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method as claimed in any one of claims 1 to 9, or the method as claimed in any one of claims 10 to 14, or the method as claimed in any one of claims 15 to 17.

38. A computer program product containing instructions, characterized in that, When the instructions are executed on a computer, the computer performs the method as described in any one of claims 1 to 9, or the method as described in any one of claims 10 to 14, or the method as described in claims 15 to 17.

39. A chip comprising a memory and a processor, characterized in that, The memory stores executable code, and when the processor executes the executable code, it performs the method as described in any one of claims 1 to 9, or the method as described in any one of claims 10 to 14, or the method as described in any one of claims 15 to 17.

Images