Verification method and device
By using digital signature information generated by a post-quantum public-key algorithm during the secure boot process, the vulnerability of traditional public-key algorithms to quantum computer attacks is solved, and the protection against unauthorized programs and compatibility with CMS data are achieved, ensuring the integrity of secure boot.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-04
- Publication Date
- 2026-03-10
AI Technical Summary
In the era of quantum computers, traditional public-key algorithm security startup schemes are vulnerable to quantum computer attacks, leading to the tampering of digital signatures and failing to effectively prevent the execution of unauthorized programs.
Digital signature information generated using the post-quantum public key algorithm is verified using the post-quantum public key certificate and private key in the CMS data to ensure the security of the signature information and resist quantum attacks.
It effectively prevents the execution of unauthorized programs during secure boot, resists traditional and post-quantum attacks, and maintains the compatibility and security of CMS data.
Smart Images

Figure CN121637480A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] Embodiments of the present application relate to the technical field of security, and in particular, to a verification method and device. BACKGROUND
[0002] Secure boot technology is a technology for ensuring the security and integrity of computer systems and images and the like during the boot process. Its manifestation is to prevent unauthorized software or malicious code from executing during system boot through a series of verification and control measures. CMS (Cryptographic Message Syntax) is a cryptographic message syntax standard for encrypting and digitally signing data. CMS defines a general data format for constructing cryptographic operations such as encryption, digital signature, key exchange, and corresponding messages. CMS can be applied to the process of secure boot to achieve the unification of the verification process of secure boot, facilitating the upgrade and maintenance of secure boot verification functions.
[0003] The current secure boot scheme based on CMS is implemented based on traditional public key algorithms. Specifically, in the secure boot process, before loading or starting the image or the startup program, taking the image as an example, the digital signature of the image needs to be verified using the public key for the image in the traditional public key algorithm based on the CMS message corresponding to the image. The digital signature is the signature result of digitally signing the corresponding image using the private key in the traditional public key algorithm. However, in the era of quantum computers, quantum computers can use the public key in the traditional public key algorithm to recover the corresponding private key for digitally signing the image, in order to attack the traditional public key algorithm, thereby threatening the security verification process in the secure boot scenario, such as tampering with the digital signature. SUMMARY
[0004] To solve the above technical problems, the present application provides a verification method and device. In the method, the CMS data corresponding to the target object to be executed can include the post-quantum digital signature information of the target object, which includes the information obtained by signing the target object using a post-quantum public key algorithm and a first private key of the target object related to the post-quantum public key algorithm. The post-quantum public key algorithm can resist quantum attacks, and a quantum computer cannot recover the post-quantum private key (such as the first private key) through the post-quantum public key certificate information (such as the first public key certificate information) in the CMS data, so as to avoid tampering with the post-quantum digital signature information in the CMS data, thereby avoiding the execution of unauthorized program code or software in the secure boot process.
[0005] In a possible implementation, the present application provides a verification method. The method comprises: obtaining, before a target object is run, a cryptographic message syntax (CMS) data corresponding to the target object; verifying the target object based on the CMS data, wherein the CMS data comprises first public key certificate information corresponding to the target object and first digital signature information of the target object, the first digital signature information comprises information obtained after the target object is signed based on a first public key algorithm and a first private key of the target object, the first public key algorithm is a post-quantum public key algorithm, and the first public key certificate information and the first private key are a pair of key information related to the first public key algorithm; and allowing the target object to be run in a case where the target object passes the verification.
[0006] The target object can be an image file, program code, software to be executed, and the like, which is not limited herein.
[0007] For example, in a secure boot scenario, the target object can be any object to be executed in a secure boot process.
[0008] The target object is taken as an image to illustrate the various embodiments.
[0009] For example, the CMS data can comprise post-quantum public key certificate information (also referred to as first public key certificate information) corresponding to the image and post-quantum digital signature information (an example of first digital signature information) of the image, wherein the post-quantum digital signature information comprises information obtained after the image is signed based on a post-quantum public key algorithm (also referred to as a first public key algorithm) and a post-quantum private key (also referred to as a first private key) of the image, and the first public key certificate information and the first private key are a pair of key information related to the first public key algorithm.
[0010] For example, a signer of the image can use the post-quantum public key algorithm and the corresponding post-quantum private key to sign a digest of the image to obtain the post-quantum digital signature information of the image.
[0011] The post-quantum public key algorithm can include but is not limited to an XMSS algorithm, a Dilithium algorithm, and an SPHINCS+ algorithm.
[0012] Taking the Dilithium algorithm as an example of the post-quantum public key algorithm, the first public key certificate information can include but is not limited to a Dilithium public key certificate, a serial number of the Dilithium public key certificate, a certificate name of the Dilithium public key certificate, and the like.
[0013] In this embodiment, the CMS data corresponding to the target object (e.g., a program or image) contains the first digital signature information of the target object. This first digital signature information includes information obtained by signing the target object using a post-quantum public-key algorithm and the target object's post-quantum private key (also referred to as the first private key). Before running the target object, this method can verify the target object based on the CMS data, thereby verifying the first digital signature information. Only after the target object is verified will it be started or executed. Because the first digital signature information of the target object in the CMS data is a post-quantum digital signature, and the post-quantum public-key algorithm can resist quantum attacks, a quantum computer cannot recover the post-quantum private key (e.g., the first private key) through the post-quantum public-key certificate information (e.g., the first public-key certificate information) in the CMS data. Therefore, it cannot tamper with the first digital signature information in the CMS data, thus preventing tampering with the target object and its post-quantum digital signature. This avoids the execution of unauthorized program code or software during secure startup.
[0014] Furthermore, this application, based on the original data structure of CMS, does not change the outer data structure of CMS data, and realizes the carrying of post-quantum public key certificate information and post-quantum digital signature information of target objects in CMS data. This makes the method of this application not only resistant to quantum attacks during the secure boot process, but also has excellent compatibility with CMS data.
[0015] In one possible implementation, the step of verifying the target object based on the CMS data includes: obtaining the first public key certificate information based on the CMS data; and verifying the first public key certificate information.
[0016] For example, CMS data can be parsed to obtain post-quantum public key certificate information, and then the post-quantum public key certificate can be verified.
[0017] In this embodiment of the application, when verifying the target object based on CMS data, the post-quantum public key certificate information obtained from the CMS data can be verified to achieve the "public key certificate verification" mentioned above.
[0018] In one possible implementation, verifying the first public key certificate information includes: obtaining a CRL and a certificate chain based on the CMS data; and verifying the first public key certificate information based on the CRL and the certificate chain.
[0019] For example, CMS data can be parsed to obtain CRLs and certificate chains.
[0020] For example, the CRL can be used to determine whether the first public key certificate has been revoked; if the first public key certificate has not been revoked, the validity of the first public key certificate can be determined based on the certificate chain, thereby verifying the legitimacy of the first public key certificate in the CMS data.
[0021] In one possible implementation, the step of verifying the target object based on the CMS data includes: obtaining the first digital signature information based on the CMS data; and verifying the first digital signature information of the target object based on the first public key certificate information if the first public key certificate information is verified successfully.
[0022] For example, CMS data can be parsed to obtain the post-quantum digital signature information (first digital signature information) of the target object. If the post-quantum public key certificate verification is successful, the post-quantum digital signature of the target object can then be verified based on this certificate information, thus achieving post-quantum digital signature verification. Only after successful verification of the post-quantum digital signature will the target object be started or executed. Because the digital signature of the target object in the CMS data contains the post-quantum digital signature, and the post-quantum public key algorithm is resistant to quantum attacks, a quantum computer cannot recover the post-quantum private key from the post-quantum public key certificate in the CMS data, thus preventing tampering with the post-quantum data signature and avoiding the execution of unauthorized program code or software during secure boot.
[0023] In one possible implementation, verifying the first digital signature information of the target object based on the first public key certificate information includes: obtaining a first signature attribute and a first public key algorithm corresponding to the first digital signature information based on the CMS data; and verifying the first digital signature information based on the first public key algorithm, the first public key certificate information, and the first signature attribute.
[0024] For example, CMS data can be parsed to obtain the signature attributes corresponding to the post-quantum digital signature and the relevant algorithm parameters of the post-quantum public key algorithm. The signature attributes may include, but are not limited to, the signature time and the digest of the target object.
[0025] Then, the post-quantum digital signature can be verified based on the relevant algorithm parameters of the post-quantum public key algorithm, the post-quantum public key certificate information parsed from the CMS data, and the aforementioned signature attributes. The specific implementation principle is similar to that of traditional signature verification, and will not be elaborated here.
[0026] In one possible implementation, the first signature attribute includes a first digest of the target object, and the verification of the target object based on the CMS data further includes: obtaining a second digest of the target object based on the CMS data; and verifying the second digest based on the first digest if the first digital signature information is verified successfully.
[0027] In this process, the digest in the first signature attribute of the target object, parsed from the CMS data, is named the first digest information. Furthermore, a second digest information of the target object can be obtained based on the CMS data. For example, the CMS data can be parsed to obtain the storage location of the target object, accessed according to that storage location, and its digest calculated using a digest algorithm to obtain the second digest information. If the post-quantum numerical signature verification of the target object passes, the second digest information can be further verified based on the first digest information to check the digest of the mirror image. For example, if the first digest information and the second digest information are the same, it indicates that the first digest information of the target object in the first signature attribute has not been tampered with; conversely, if the first digest information and the second digest information are different, it indicates that the first digest information of the target object in the first signature attribute has been tampered with, and the target object verification fails.
[0028] In one possible implementation, the verification of the target object based on the CMS data includes: obtaining second digital signature information of the CRL and second public key certificate information corresponding to the CRL based on the CMS data, wherein the second digital signature information includes information obtained by signing the CRL based on the first public key algorithm and the second private key of the CRL issuer, and the second public key certificate information and the second private key are a pair of key information related to the first public key algorithm; and verifying the second digital signature information of the CRL based on the second public key certificate information.
[0029] In the above implementation, before verifying the first public key certificate based on the CRL, the legitimacy of the CRL can be verified. Specifically, the digital signature of the CRL can be verified. This embodiment mainly describes how to verify the digital signature of the CRL.
[0030] Taking the Dilithium algorithm as the first public key algorithm as an example, the Dilithium algorithm not only provides a private key for signing the image (the first private key mentioned above) and a public key certificate for verifying the signature of the image (e.g., the first public key certificate information), but also provides a post-quantum public key certificate for the CRL issuer (e.g., the second public key certificate information, referred to as the CRL post-quantum public key certificate) and a private key for the CRL issuer (e.g., the second private key of the CRL issuer, referred to as the CRL post-quantum private key). The CRL issuer can use the CRL post-quantum private key to sign the CRL to obtain the signed CRL.
[0031] The second public key certificate information and the second private key are a pair of key information related to the first public key algorithm. This pair of key information is used to sign and verify the CRL. The first public key certificate information and the first private key are another pair of key information related to a post-quantum public key algorithm. This other pair of key information is strongly associated with a target object (e.g., a mirror image) and is used to sign and verify the mirror image. However, both of these pairs of key information are keys provided by post-quantum public key algorithms (e.g., the Dilithium algorithm).
[0032] Thus, in this embodiment of the application, the second public key certificate information for the CRL issuer can be obtained from the CMS data, and the second digital signature information of the CRL (which is the information after digitally signing the CRL with the CRL using the quantum private key after the CRL) can be verified based on the second public key certificate information, so that the digital signature of the CRL can also be lower than quantum attack, thus preventing attackers from tampering with the CRL.
[0033] In one possible implementation, the CMS data further includes third public key certificate information corresponding to the target object and third digital signature information of the target object. The third digital signature information includes information obtained by signing the target object based on the second public key algorithm and the third private key of the target object. The second public key algorithm is not a post-quantum public key algorithm. The third public key certificate information and the third private key are a pair of key information related to the second public key algorithm.
[0034] The second public key algorithm differs from the post-quantum public key algorithm. The second public key algorithm is a traditional public key algorithm, such as any one of RSA (Rivest-Shamir-Adleman), DSA (Digital Signature Algorithm), ECC (Elliptic Curve Cryptography), etc. There are no restrictions here.
[0035] In this embodiment, the CMS data includes not only the target object's post-quantum public key certificate information and post-quantum digital signature, but also the target object's traditional public key certificate information (here, the third public key certificate information) and traditional digital signature (here, the third digital signature information) related to the traditional public key algorithm. This allows the application to maintain the outer data structure of the CMS without altering its internal fields (e.g., Certificate, CRL, Singerinfos fields), enabling the CMS data to support carrying public key certificate information, CRL digital signatures, and signer information for traditional public key algorithms, as well as those for post-quantum public key algorithms. Thus, based on the existing CMS format, the post-quantum extended field can flexibly support both traditional and post-quantum secure boot. This ensures that during secure boot, it can defend against both traditional and post-quantum attacks.
[0036] In one possible implementation, the step of verifying the target object based on the CMS data further includes: obtaining the third public key certificate information based on the CMS data; and verifying the third public key certificate information.
[0037] In this embodiment, the verification principle for the third public key certificate information is similar to that for the verification principle for the first public key certificate information in the above embodiments, and the effect is also similar. The only difference is that the third public key certificate information is provided by a traditional public key algorithm, while the first public key certificate information is provided by a post-quantum public key algorithm.
[0038] In one possible implementation, verifying the third public key certificate information includes: if the second digital signature information of the CRL is verified successfully based on the second public key certificate information, then the third public key certificate is verified based on the CRL and the certificate chain.
[0039] In this embodiment, the CRL and certificate chain used when verifying the first public key certificate information and the third public key certificate information are the same. In other words, when parsing CMS data, this method only needs to obtain the CRL and certificate chain once, without having to obtain them repeatedly, and can be used to verify the first public key certificate and the third public key certificate.
[0040] In one possible implementation, the step of verifying the target object based on the CMS data includes: obtaining the third digital signature information based on the CMS data; and verifying the third digital signature information of the target object based on the third public key certificate information if the third public key certificate information is verified successfully.
[0041] For example, the traditional digital signature information of the target object (an example of third digital signature information) can be parsed from CMS data. If the traditional public key certificate information (third public key certificate information, also parsed from CMS data) associated with the traditional digital signature is verified, the traditional digital signature information of the target object can be verified based on the traditional public key certificate information.
[0042] Thus, embodiments of this application can use CMS data to support resistance to conventional and post-quantum attacks on the target object during the secure boot process, and prevent tampering with the target object's conventional and post-quantum digital signatures.
[0043] In one possible implementation, verifying the third digital signature information of the target object based on the third public key certificate information includes: obtaining a second signature attribute and a second public key algorithm corresponding to the third digital signature information based on the CMS data; and verifying the third digital signature information based on the second public key algorithm, the third public key certificate information, and the second signature attribute.
[0044] The implementation principle of this embodiment is similar to that of the above embodiment, which verifies the first digital signature information based on the first signature attribute, the first public key algorithm, and the first public key certificate information corresponding to the first digital signature information. The only difference is that the first digital signature information is the post-quantum public key signature information of the target object, while the third digital signature information is the traditional public key signature information of the target object.
[0045] Thus, the CMS data in this application embodiment can support dual defense against both conventional and post-quantum attacks.
[0046] In one possible implementation, the second signature attribute includes third digest information of the target object, and the verification of the target object based on the CMS data further includes: verifying the second digest information based on the third digest information if the third digital signature information is verified successfully.
[0047] The implementation principle of this embodiment is similar to that of the above embodiment, which verifies the second digest information based on the first digest information. In this way, the verification of signature attributes in traditional public key algorithms and the verification of signature attributes in post-quantum public key algorithms can be realized.
[0048] In one possible implementation, the verification of the target object based on the CMS data includes: obtaining the fourth digital signature information of the CRL and the fourth public key certificate information corresponding to the CRL based on the CMS data, wherein the fourth digital signature information includes information obtained by signing the CRL based on the second public key algorithm and the fourth private key of the CRL issuer, and the fourth public key certificate information and the fourth private key are a pair of key information related to the second public key algorithm; and verifying the fourth digital signature information of the CRL based on the fourth public key certificate information.
[0049] The implementation principle of this embodiment is similar to that of the above embodiment: "Based on the CMS data, obtain the second digital signature information of the CRL and the second public key certificate information corresponding to the CRL. The second digital signature information includes information obtained by signing the CRL based on the first public key algorithm and the second private key of the CRL issuer. The second public key certificate information and the second private key are a pair of key information related to the first public key algorithm. Based on the second public key certificate information, verify the second digital signature information of the CRL." The difference is that in this embodiment, the digital signature of the CRL (e.g., the fourth digital signature information) is a digital signature of the CRL performed using a traditional public key algorithm and a private key related to the traditional public key algorithm for the CRL issuer. In the previous embodiment, the digital signature of the CRL (e.g., the second digital signature information) was a digital signature of the CRL performed using a post-quantum public key algorithm and a private key related to the post-quantum public key algorithm for the CRL issuer.
[0050] In one possible implementation, this application provides a verification device. The device includes: an acquisition module, configured to acquire Cryptographic Message Syntax (CMS) data corresponding to the target object before the target object is run; a verification module, configured to verify the target object based on the CMS data, wherein the CMS data includes first public key certificate information corresponding to the target object and first digital signature information of the target object, the first digital signature information including information obtained by signing the target object based on a first public key algorithm and the first private key of the target object, the first public key algorithm being a post-quantum public key algorithm, and the first public key certificate information and the first private key being a pair of key information related to the first public key algorithm; and a control module, configured to allow the target object to run if the target object verification passes.
[0051] In one possible implementation, the verification module is specifically used to: obtain the first public key certificate information based on the CMS data; and verify the first public key certificate information.
[0052] In one possible implementation, the verification module is specifically used to: obtain a CRL and a certificate chain based on the CMS data; and verify the first public key certificate information based on the CRL and the certificate chain.
[0053] In one possible implementation, the verification module is specifically used to: obtain the first digital signature information based on the CMS data; and verify the first digital signature information of the target object based on the first public key certificate information if the first public key certificate information is verified successfully.
[0054] In one possible implementation, the verification module is specifically used to: obtain a first signature attribute and a first public key algorithm corresponding to the first digital signature information based on the CMS data; and verify the first digital signature information based on the first public key algorithm, the first public key certificate information, and the first signature attribute.
[0055] In one possible implementation, the verification module is specifically used to: obtain second digest information of the target object based on the CMS data; and verify the second digest information based on the first digest information if the first digital signature information is verified successfully.
[0056] In one possible implementation, the verification module is specifically configured to: obtain, based on the CMS data, the second digital signature information of the CRL and the second public key certificate information corresponding to the CRL, wherein the second digital signature information includes information obtained by signing the CRL based on the first public key algorithm and the second private key of the CRL issuer, and the second public key certificate information and the second private key are a pair of key information related to the first public key algorithm; and verify the second digital signature information of the CRL based on the second public key certificate information.
[0057] In one possible implementation, the CMS data further includes third public key certificate information corresponding to the target object and third digital signature information of the target object. The third digital signature information includes information obtained by signing the target object based on the second public key algorithm and the third private key of the target object. The second public key algorithm is not a post-quantum public key algorithm. The third public key certificate information and the third private key are a pair of key information related to the second public key algorithm.
[0058] The effects of the verification devices in the above embodiments are similar to those of the verification methods in the above embodiments, and will not be repeated here.
[0059] In one possible implementation, this application provides a verification device. The verification device includes a processor, which, when executing computer instructions, is configured to implement the method in any of the above-described embodiments.
[0060] The effect of the verification device in this embodiment is similar to that of the verification methods in the above embodiments, and will not be described again here.
[0061] In one possible implementation, this application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program that, when executed on a computer or processor, causes the computer or processor to perform the methods described in any of the above embodiments.
[0062] The effect of the computer-readable storage medium in this embodiment is similar to that of the verification methods in the embodiments described above, and will not be repeated here.
[0063] In one possible implementation, this application provides a computer program product. The computer program product includes a software program that, when executed by a computer or processor, causes the methods described in any of the above embodiments to be performed.
[0064] The effect of the computer program product in this embodiment is similar to that of the verification methods in the above embodiments, and will not be repeated here. Attached Figure Description
[0065] Figure 1 This is a schematic diagram of the data structure of a CMS as an example.
[0066] Figure 2 This is a schematic diagram illustrating the mirror verification process as an example.
[0067] Figure 3 A block diagram of the apparatus 10 as an example;
[0068] Figure 4 This is a schematic diagram illustrating a security verification process as an example.
[0069] Figure 5a This is a schematic diagram of the data structure of a CMS as an example.
[0070] Figure 5b This is a schematic diagram of the data structure of a CMS as an example.
[0071] Figure 6 This is a schematic diagram illustrating a security verification process as an example.
[0072] Figure 7 This is a schematic diagram illustrating a security verification process as an example.
[0073] Figure 8 This is a schematic diagram of the structure of a verification device provided in an embodiment of this application;
[0074] Figure 9 A schematic diagram of the structure of an apparatus provided in an embodiment of this application;
[0075] Figure 10 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation
[0076] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0077] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.
[0078] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.
[0079] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0080] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.
[0081] The following explains and clarifies some technical terms used in this field and in this application:
[0082] A quantum computer is a physical device that follows the laws of quantum mechanics and is used for high-speed mathematical and logical operations, as well as the storage and processing of quantum information. When a device processes and calculates quantum information and runs quantum algorithms, it is called a quantum computer.
[0083] Asymmetric algorithms, also known as public-key cryptography or traditional public-key algorithms, are a type of cryptographic algorithm that differs from traditional symmetric encryption algorithms (such as AES (Advanced Encryption Standard) and Data Encryption Standard (DES)). They use a pair of keys for encryption and decryption operations, consisting of a public key and a private key.
[0084] In asymmetric algorithms, public and private keys are used by each entity participating in the communication (e.g., a user or device). The public key is public and used to encrypt data or verify signatures; the private key is kept secret and used to decrypt data or generate signatures.
[0085] Digital Signatures: Asymmetric algorithms can be used not only for data encryption but also for generating and verifying digital signatures. By signing a message using the signer's private key in an asymmetric algorithm, the integrity and authenticity of the message can be ensured. Anyone can verify the signature using the public key associated with the signer to confirm that the message has not been tampered with and was indeed generated by the signer. Common asymmetric algorithms include RSA (Rivest-Shamir-Adleman), DSA (Digital Signature Algorithm), and ECC (Elliptic Curve Cryptography). They are widely used in secure communication, digital signatures, key exchange, and other fields, and are an important component of modern cryptography.
[0086] A Certificate Revocation List (CRL) is a list of public key certificates that have been revoked. Each revocation entry in the CRL includes information such as the revoked certificate's serial number, the reason for revocation, and the revocation date. This information is crucial for network and system security because it helps ensure that only those certificates that remain trusted are used for encrypted communication and authentication.
[0087] Post-quantum public-key algorithms, also known as post-quantum signature verification algorithms, are algorithms resistant to quantum attacks. Unlike traditional public-key algorithms, post-quantum public-key algorithms correspond to post-quantum private keys and post-quantum public-key certificates. The post-quantum private key can be used for digital signatures, resulting in a signature (referred to as a post-quantum digital signature in this application). The post-quantum public-key certificate contains the post-quantum public key and can be used to verify the post-quantum digital signature. Post-quantum public-key algorithms can include, but are not limited to, the XMSS algorithm, the Dilithium algorithm, and SPHINCS+.
[0088] The following explains the relevant fields in the CMS data structure. This explanation is applicable to... Figure 1 , Figure 5a , Figure 5b The corresponding fields of the data structure shown in the CMS data are:
[0089] ContentInfo: Content information
[0090] ContentType: Content type. The value of the ContentType field is an object identifier of type SignedData.
[0091] Content: The content itself; the value of the Content field is SignedData (signature data).
[0092] Certificates field: Multiple certificate fields
[0093] CertificateSet field: Certificate settings field
[0094] CertificateChoices field: Certificate selection field
[0095] Certificate field: Certificate field
[0096] encapContentInfo field: The field containing the encapsulated content information.
[0097] The eContentType field: The encapsulation type of the encapsulated content information.
[0098] The eContent field contains encapsulated content information used to indicate the storage location of the target object (e.g., an image) to be verified.
[0099] CRLs field: Multiple CRL fields
[0100] RevocationFochoices field: Revocation options field
[0101] CRL field: CRL field
[0102] SignerInfos field: Signer information field
[0103] SignerInfo field: A field containing signer information.
[0104] Sid field: Signature identifier field
[0105] The issuerAndSerialNumber field: Issuer and serial number.
[0106] issuer field: Public key certificate name field
[0107] serialNumber field: Public key certificate serial number field
[0108] signedAttrs field: Signature attribute field
[0109] Attribute field: property field
[0110] The attrType field: an attribute type field, such as (content type attribute [required] / message digest attribute [required] / signature time attribute identifier).
[0111] attrValues field: Content type attribute field
[0112] Time field: Signature time attribute field
[0113] MessageDigest field: Message digest attribute field
[0114] signatureAlgorithm field: Signature algorithm field
[0115] signature field: Signature field
[0116] also, Figure 1 , Figure 5a , Figure 5b The relationship between two fields connected by an arrow is as follows: the internal fields of the field connected at the origin of the arrow include the fields connected at the destination of the arrow. For example, CertificateSet field -> CertificateChoices field means that the internal fields of CertificateSet field include CertificateChoices field.
[0117] Secure Boot is a technology that ensures the security and integrity of computer systems and data such as system images during the boot process. It manifests as a series of verification and control measures to prevent unauthorized software or malicious code from executing during system startup. CMS (Cryptographic Message Syntax) is a cryptographic message syntax standard used for encrypting and digitally signing data. CMS defines a common data format for constructing cryptographic operations such as encryption, digital signatures, and key exchange, as well as the corresponding messages. CMS can be applied to the secure boot process to unify the verification process and facilitate the upgrading and maintenance of secure boot verification functions.
[0118] Current secure boot schemes based on CMS are implemented using traditional public-key algorithms. Specifically, during secure boot, before loading or starting the image or program, the digital signature of the image or program is verified using the public key specific to the image or program within the traditional public-key algorithm, based on the CMS message. This digital signature is the result of signing the corresponding image or program using the corresponding private key within the traditional public-key algorithm. However, in the era of quantum computing, quantum computers can use the public key in the traditional public-key algorithm to recover the corresponding private key used for signing, thereby attacking the traditional public-key algorithm and threatening the security verification process in secure boot scenarios, such as by tampering with the digital signature.
[0119] The following is combined with Figure 1 and Figure 2 This paper introduces a scheme that utilizes traditional public key algorithms to achieve secure boot based on CSM in related technologies.
[0120] Figure 1 This is a schematic diagram illustrating the data structure of a CMS in related technologies, as an example. Figure 2 For based on Figure 1 The flowchart shown illustrates the secure startup process of the CMS.
[0121] based on Figure 1 Please refer to the data structure shown. Figure 2 The secure boot process may include the following steps:
[0122] S101, enter the Unified Extensible Firmware Interface (UEFI) boot service.
[0123] UEFI ensures system security during startup through the Secure Boot feature. Secure Boot uses digital certificates to verify the integrity and authentication of the boot loader and operating system, preventing malware attacks during the Secure Boot process.
[0124] UEFI firmware performs signature verification and integrity checks on every image file read from the boot device before loading the operating system. Only verified image files are loaded and executed, which helps prevent malware and unauthorized modifications.
[0125] The UEFI boot service may include a parsing module and a verification module.
[0126] S102, the parsing module can parse the CMS message corresponding to the image and obtain the CMS message content.
[0127] In this step, the CMS message can be parsed to obtain the CMS message content, specifically the various data in the CMS message's data structure.
[0128] Figure 1 The data of each structure in the parsed CMS message data structure is shown.
[0129] For example, CMS message content may include, but is not limited to: public key certificates of traditional public key algorithms (e.g., Figure 1 The Certificate field shown contains the ECDSA certificate and the CRL (e.g., Figure 1 The ECDSA certificate Ctrl field shown in the Ctrl field), and the signature message (e.g.) Figure 1 The signature field shown includes fields such as the ECDSA algorithm signature.
[0130] The ECDSA algorithm provides a private key for signing images and a public key certificate for verifying the signatures of images (e.g., ...). Figure 1 (The ECDSA certificate shown in the Certificate field).
[0131] in, Figure 1 The ECDSA algorithm signature in the signature field shown is the private key provided by the ECDSA algorithm for signing images, used by the signer of the image. Figure 1 The image within the dashed box shows the signature result after the signature attribute of the image has been signed.
[0132] in, Figure 1 The fields within the dashed box shown, such as the Attribute field and its internal fields, describe the signature attributes, which may include the Timer field (signature time field) and the MessageDigest field.
[0133] The Timer field indicates the signing time for signing the image digest, and the MessageDigest field indicates the image digest.
[0134] Figure 1 The eContent field shown indicates the storage location of the image.
[0135] In addition, the ECDSA algorithm also provides a public key certificate (CRL public key certificate) and a private key (CRL private key) for CRL issuers. CRL issuers can use the CRL private key to sign the CRL to obtain a signed CRL, for example... Figure 1 The ECDSA certificate Ctrl field shown.
[0136] S103, Perform CMS validation on the CMS message content.
[0137] The CMS verification process can be implemented through the verification module.
[0138] Specifically, the verification module can execute each of the verification steps in S1031, S1032, S1033, and S1034, and these verification steps can be executed serially.
[0139] S1031, Perform CRL verification on the CRL message.
[0140] The CRL verification process can be divided into the following steps: 1. CRL issuer certificate verification; 2. CRL digital signature verification; 3. Verification of whether the public key certificate of the traditional public key algorithm has been revoked.
[0141] 1. CRL issuer certificate verification:
[0142] First, retrieve the CRL issuer certificate from the CRL message. Figure 1 (Not shown), based on the validity information of the CRL issuer certificate carried in the CRL message ( Figure 1 (Not shown) to determine whether the CRL issuer certificate is valid; if the CRL issuer certificate is not valid, the CRL verification fails and proceeds to S104.
[0143] If the CRL issuer certificate is valid, the public key used to verify the digital signature of the CRL can be obtained from the CRL issuer certificate (the aforementioned CRL public key certificate). It should be noted that the aforementioned CRL public key certificate is not a public key certificate for image or program verification in the aforementioned traditional public key algorithm (such as an ECDSA certificate in the Certificate field).
[0144] 2. CRL digital signature verification;
[0145] Next, the signed CRL (e.g., using the CRL public key certificate) is verified. Figure 1 Verify the ECDSA certificate (Crl) within the Crrl field shown.
[0146] Wherein, if the CRL verification after the signature is successful, the CRL (e.g.) is explained. Figure 1 If the ECDSA certificate (Crl) in the Crl field shown is valid, otherwise, if the digital signature verification of the CRL fails, it means that the CRL is invalid and the process will proceed directly to S104.
[0147] 3. Verify whether the public key certificate for the traditional public key algorithm has been revoked;
[0148] The public key certificate of the traditional public key algorithm will only be checked if the CRL is valid (e.g., ...). Figure 1 Does the ECDSA certificate shown in the Certificate field exist within the CRL?
[0149] If the public key certificate of the traditional public key algorithm is not in the CRL, it means that the public key certificate of the traditional public key algorithm in the CMS message has not been revoked. Conversely, if the public key certificate of the traditional public key algorithm is in the CRL, it means that the public key certificate of the traditional public key algorithm in the CMS message has been revoked. This indicates that the CRL verification is successful, and the process proceeds to S104.
[0150] If all three points above are verified, it means that the CRL verification is successful, and S1032 can be executed.
[0151] S1032 verifies the public key certificate for traditional public key algorithms.
[0152] Based on the certificate chain in the CMS message ( Figure 1 (Not shown) is used to verify the validity of the public key certificate of the traditional public key algorithm; if the public key certificate is in the certificate chain, it means that the public key certificate of the traditional public key algorithm in the CMS message is valid, and the verification of S1032 passes; conversely, if the public key certificate is not in the certificate chain, it means that the public key certificate of the traditional public key algorithm in the CMS message is invalid, and the verification of S1032 fails.
[0153] If the verification in S1032 passes, then proceed to S1033.
[0154] S1033, Verification of signature attributes.
[0155] The signature attributes may include, for example: Figure 1 The attributes shown in the dashed box, such as the Timer field and MessageDigest field, can use the public key from a public key certificate of a traditional public key algorithm, such as... Figure 1 The dashed boxes shown in the image represent various attributes, and traditional public-key algorithms are used to evaluate the signature result (e.g., ...). Figure 1The ECDSA algorithm signature in the signature field shown is verified. If the ECDSA algorithm signature verification passes, step S1034 can be executed. If the ECDSA algorithm signature verification fails, it indicates that... Figure 3 The signature attribute of the image within the dashed box shown has been tampered with, causing the signature attribute verification of S1033 to fail.
[0156] If the verification in S1033 passes, S1034 can be executed.
[0157] S1034, Mirror digest verification.
[0158] This step is used to verify whether the image has been tampered with.
[0159] by Figure 3 For example, the data to be signed (e.g., the image itself) can be obtained based on the storage location of the image indicated by the eContent field. Then, a digest of the image data is calculated using a pre-defined digest algorithm to obtain the image digest. Next, the calculated image digest is compared with the digest obtained from parsing the CMS message. Figure 3 The image digest verification is performed to check if the image digest indicated by the MessageDigest field is the same as the image digest value. If the calculated image digest is the same as the MessageDigest field value, the image digest has not been tampered with and the image digest verification is successful. Conversely, if the calculated image digest is different from the MessageDigest field value, the image digest has been tampered with and the image digest verification is unsuccessful.
[0160] If the verification in S1034 passes, it means that the verification module has successfully verified the CMS content of the parsed CMS message.
[0161] During the CMS verification process of the CMS message content executed by the verification module, if each verification step in S1031 to S1034 above passes the verification, it means that the CMS verification of the parsed CMS message content has passed, and it also means that the image verification has passed. Then the image can be loaded or executed.
[0162] S104, Release Resources: Release all allocated resources.
[0163] During the CMS verification process of the CMS message content performed by the verification module, if any step in S1031 to S1034 fails verification, the CMS verification of the CMS message will fail, and then S104 will be executed.
[0164] This includes the ability to release all resources allocated during the CMS verification process. These resources may include, but are not limited to, resources used for parsing CMS messages, verifying CMS messages, and storing various fields in CMS messages (such as memory resources, computing resources, etc.).
[0165] However, quantum computers can use the public key certificate (used for image verification) from the asymmetric algorithm (also known as the traditional public key algorithm) obtained by parsing CMS messages to recover the corresponding private key used to sign the image in the traditional public key algorithm. They can then tamper with the signed image, modify it into unauthorized software or malicious code, recalculate the digest of the modified image, and use the recalculated digest to alter the signature attributes. Finally, they can use the recovered private key to digitally sign the modified signature attributes, thereby tampering with the image's digital signature and threatening the security verification process in a secure boot scenario.
[0166] To resist attacks by quantum computers on CMS-based secure boot schemes, this application provides a method and apparatus. In this method and apparatus, the CMS data corresponding to the target object (e.g., a program or image) contains a post-quantum digital signature of the target object. This post-quantum digital signature is the result of signing the target object using a post-quantum public-key algorithm and a post-quantum private key. The method can use a post-quantum public-key algorithm and a post-quantum public-key certificate to verify the post-quantum digital signature in the CMS data. Only after successful verification will the target object be started or executed. Because the digital signature of the target object in the CMS data includes a post-quantum digital signature, and the post-quantum public-key algorithm is resistant to quantum attacks, the quantum computer cannot recover the post-quantum private key through the post-quantum public-key certificate in the CMS data, thus preventing tampering with the post-quantum data signature and avoiding the execution of unauthorized program code or software during the secure boot process.
[0167] Figure 1 This is a schematic diagram of the apparatus 10 of this application, shown as an example.
[0168] like Figure 3 As shown, the device 10 may include a verification module 101 and a processing module 102. The device 10 can verify the CMS data corresponding to the target object during the secure startup process to verify the target object. If the CMS data verification passes, it means that the target object has passed the verification, and the target object will be run.
[0169] The target object can be an image file to be executed, program code, software, etc., and there are no restrictions here.
[0170] For example, in a secure boot scenario, the target object can be any object to be executed during the secure boot process.
[0171] The following uses the target object as an image (e.g., a boot image) as an example to illustrate the method and apparatus of this application. When the target object is other objects, the implementation principle is the same, and will not be repeated here.
[0172] like Figure 3 As shown, the verification module 101 can be used to execute the method provided in this application to verify the CMS data corresponding to the image and send the verification result to the processing module 102.
[0173] The processing module 102 can run the image if the verification result shows that the CMS data verification is successful.
[0174] If the verification result indicates that the CMS data verification fails, the processing module 102 will not run the image. For example, it can release all resources used in the process of verifying the CMS data (such as memory resources, computing resources, etc.). The specific process is as follows: Figure 3 The same applies to S104, so it will not be elaborated here.
[0175] The data structure of a mirror image can include two parts: a data header and data content. The data header can carry the CMS data of the mirror image, and the data content can carry the content of the mirror image.
[0176] Therefore, each image can have a unique set of CMS data. The CMS data differs between different images.
[0177] When the target object is a program or code, it also has a unique CMS data set. This CMS data typically contains information about the target object (e.g., an image file, program, or code) used during the boot process. This information may include the target object's digital signature, signature algorithm information, and possible hash values. This information helps components (such as UEFI components used for secure boot) accurately verify the integrity and legitimacy of the target object during the boot process.
[0178] For example, during the secure boot process, if image file 1, image file 2, program 1, and program 2 need to be run, then image file 1 has a corresponding CMS data 1, image file 2 has a corresponding CMS data 2, program 1 has a corresponding CMS data 3, and program 2 has a corresponding CMS data 4.
[0179] Figure 4 An exemplary structural schematic diagram of device 10 is shown. It should be understood that, Figure 4 The device shown is merely an example. The device of this application may have more or fewer modules than those shown in the figure, may combine two or more modules, or may have different module configurations.Figure 3 The various modules shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.
[0180] Device 10 can be implemented via software or hardware.
[0181] In the first example, when device 10 is implemented in software, device 10 may be, for example, an application running on a computing instance, such as a virtual machine, container, or host.
[0182] In the second example, when device 10 is implemented in hardware, it can be implemented through at least one physical device including a processor, such as a server. The processor can be a central processing unit (CPU), or any combination of an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a system-on-chip (SoC), a software-defined infrastructure (SDI) chip, an artificial intelligence (AI) chip, and a data processing unit (DPU). Furthermore, the number of processors included in device 10 can be arbitrary, and the types of processors can be one or more. The specific number and types of processors can be determined according to the actual application's business requirements, and this application does not impose any limitations on this.
[0183] The physical device can be a server, terminal device, base station, relay device, satellite device, etc., and there are no restrictions here.
[0184] The terminal devices may include, but are not limited to: mobile phones, laptops, personal computers, wearable devices, smart TVs, and in-vehicle infotainment systems.
[0185] In a third example, when device 10 is implemented in hardware, device 10 can be a computing cluster comprising multiple computing nodes. Further, these multiple computing nodes can communicate through the at least one switching node. Exemplarily, the computing nodes can be accelerator cards, such as deep-learning processing units (DPUs), data processing units (DPUs), graphics processing units (GPUs), neural-network processing units (NPUs), or tensor processing units (TPUs), or other types of accelerator cards. Alternatively, the computing nodes can be general-purpose processors, such as central processing units (CPUs).
[0186] Figure 3 This is a flowchart illustrating a method of an embodiment of this application, using a mirror image of the target object as an example. The method is similar when the target object is another object. Figure 4 The method shown can be combined with Figure 5a The apparatus shown, but not limited to, the combination Figure 5a The apparatus shown.
[0187] like Figure 5a As shown, the process may include the following steps:
[0188] S201: Before running the image, obtain the CMS data corresponding to the image.
[0189] In one possible implementation, after S201, the image can be verified based on CMS data; if the image verification passes, S205 is executed to run the image or allow the image to run.
[0190] The CMS data includes the post-quantum public key certificate information (also referred to as the first public key certificate information) corresponding to the image and the post-quantum digital signature information of the image (an example of the first digital signature information). The post-quantum digital signature information includes information obtained by signing the image based on the post-quantum public key algorithm (also referred to as the first public key algorithm) and the post-quantum private key of the image (also referred to as the first private key). The first public key certificate information and the first private key are a pair of key information related to the first public key algorithm.
[0191] When verifying an image, the target type can be verified based on CMS data. The target type verification can be at least one of the following types: CRL verification, public key certificate verification, signature attribute verification, and image digest verification.
[0192] If each type of validation passes in the validation of the target type, the target object can be determined to have passed the validation. If at least one type of validation fails in the validation of the target type, the target object fails the validation.
[0193] In another possible implementation, S202 may be executed after S201.
[0194] S202, based on CMS data, obtains post-quantum public key certificate information, and optionally, also obtains mirrored post-quantum digital signature information.
[0195] The post-quantum digital signature information includes the signature result obtained by signing the image using the aforementioned post-quantum public key algorithm and post-quantum private key.
[0196] For example, the signer of a mirror image can use a post-quantum public-key algorithm and the corresponding post-quantum private key to sign the digest of the mirror image to obtain the signature result of the mirror image.
[0197] The method in this embodiment can parse CMS data to obtain data such as post-quantum public key certificate information and mirrored post-quantum digital signature information.
[0198] Taking the Dilithium algorithm as an example of this post-quantum public-key algorithm, Figure 1 An exemplary diagram illustrates the data structure of the CMS data in this image. When the post-quantum public key algorithm is XMSS algorithm, SPHINCS+, the data structure of the CMS data in this image is different from... Figure 5a The data structure shown has similar fields, except that the field values related to the post-quantum public key algorithm are replaced with field values related to the XMSS algorithm or SPHINCS+, which will not be elaborated here.
[0199] Figure 1 The data structure of the CMS data shown is the same as that in the CMS standard. Based on the original data structure of CMS, this application realizes the carrying of post-quantum public key certificate information and mirrored post-quantum digital signature information in CMS data.
[0200] Compared to Figure 5a Please refer to the data structure diagram of the CMS data shown below. Figure 5aThis application does not change any of the fields in the CMS data structure, but sets the corresponding information about the post-quantum public key certificate in the fields about public key certificate information (such as Certificate field, Crl field, issuer field, serialNumber field), and sets the information about the post-quantum public key algorithm and post-quantum digital signature in the fields about digital signature information of the mirror (such as signatureAlgorithm field, signature field).
[0201] Specifically, it can be compared to Figure 1 and Figure 5a The orange fields with the same name and their corresponding green field values.
[0202] like Figure 5a As shown, the post-quantum public key certificate information obtained in this application embodiment may include, but is not limited to: Dilithium certificate (a type of post-quantum public key certificate) in the Certificate field, Dilithium certificate Crl in the Crl field, the recognizable name of Dilithium certificate (the name of the post-quantum public key certificate) in the issuer field, and the Dilithium certificate serial number (the serial number of the post-quantum public key certificate) in the serialNumber field.
[0203] The Dilithium algorithm provides not only a private key (the first private key mentioned above) for signing images, but also a public key certificate (e.g., for verifying the signature of an image) for verifying the signature. Figure 5a The Certificate field shown contains an ECDSA certificate, and also provides a post-quantum public key certificate (also referred to as second public key certificate information, e.g., simply called the CRL post-quantum public key certificate) and a private key (also referred to as the CRL issuer's second private key, e.g., simply called the CRL post-quantum private key) for the CRL issuer. The CRL issuer can use this CRL post-quantum private key to sign the CRL to obtain a signed CRL, for example... Figure 1 The field value shown in the Crl field is: Dilithium Certificate Crl.
[0204] The second public key certificate information and the second private key are a pair of key information related to the first public key algorithm. This pair of key information is used to sign and verify the CRL. The first public key certificate information and the first private key are another pair of key information related to a post-quantum public key algorithm. This other pair of key information is strongly associated with a specific image and is used to sign and verify that image. However, both of these pairs of key information are keys provided by post-quantum public key algorithms (such as the Dilithium algorithm).
[0205] like Figure 5a As shown, the post-quantum digital signature information of the image obtained in this application embodiment may include, but is not limited to: the Dilithium algorithm identifier and parameters in the signatureAlgorithm field (e.g., describing the algorithm identifier and algorithm parameters of the post-quantum public key algorithm), and the Dilithium algorithm signature in the signature field (a post-quantum digital signature of the image). For example, the Dilithium algorithm signature in the signature field uses the Dilithium algorithm and the corresponding post-quantum private key (the first private key for the image). Figure 5b The signature result after signing the signature attribute in the dashed box shown.
[0206] It should be understood that Figure 4 , Figure 6 and in the following embodiments Figure 6 In this document, fields with the same name have the same meaning. The orange and green colors in the fields are only for illustrating the technical solution of this application and are not intended to limit the data structure of the CMS data.
[0207] S204 verifies the image based on the post-quantum public key certificate information and the post-quantum digital signature information of the image.
[0208] When verifying an image, the target type can be verified based on CMS data. The target type verification can be at least one of the following types: CRL verification, public key certificate verification, signature attribute verification, and image digest verification.
[0209] If each type of validation passes in the validation of the target type, the target object can be determined to have passed the validation. If at least one type of validation fails in the validation of the target type, the target object fails the validation.
[0210] S205, run the image if the CMS data verification passes.
[0211] In this embodiment, the original data structure of the CMS data is modified by setting the field values of the fields indicating the public key certificate information of the public key algorithm to the relevant information of the public key certificate of the post-quantum public key algorithm of this application, and setting the field values of the fields indicating digital signature information (e.g., public key algorithm and corresponding digital signature) to the signature result of digital signature using the post-quantum public key algorithm of this application and the corresponding post-quantum private key. Because the post-quantum public key algorithm can resist attacks from quantum computers, it prevents quantum computers from recovering the corresponding post-quantum private key based on the post-quantum public key certificate in the CMS data during secure boot, thereby preventing tampering with the post-quantum digital signature and thus resisting quantum attacks during secure boot.
[0212] In some embodiments, when verifying CMS data, the following steps are taken as an example to illustrate the process: sequentially performing CRL verification, public key certificate verification, signature attribute verification, and image digest verification. Figure 6 The verification process of CMS data in S204 is shown.
[0213] Figure 2 This is an illustrative diagram illustrating one implementation process for verifying the image based on the CMS data. This application does not limit the implementation process for verifying the image based on the CMS data. Figure 2 The process is shown. In Figure 2 In the process shown, CRL verification can be implemented through S301 and S302; public key certificate verification can be implemented through S303; signature attribute verification can be implemented through S304; and mirror digest verification can be implemented through S305.
[0214] Among the four verification and related technologies described in the embodiments of this application, Figure 6 The four verification methods shown in S1031 to S1034 are based on the same principle. The following mainly focuses on [the following]. Figure 5a The differences in the verification process shown will be described, while other similarities will be referenced. Figure 5a The relevant introduction is sufficient and will not be repeated here.
[0215] The following is an introduction Figure 6 At that time, with Figure 1 The data structure of the CMS data shown is used as an example for illustration, but it is not limited to applications in [specific context]. Figure 1 The data structure of the CMS data shown is illustrated.
[0216] Please refer to Figure 5a Based on CMS data, the process of verifying the image can be divided into:
[0217] In one possible implementation, when verifying the image based on the CMS data, the post-quantum public key certificate information of the image can be obtained based on the CMS data; then, the post-quantum public key certificate information (an example of the first public key certificate information) is verified.
[0218] In one possible implementation, when verifying the first public key certificate information, a CRL and a certificate chain can be obtained based on the CMS data; the first public key certificate can then be verified based on the CRL and the certificate chain.
[0219] Among them, it can verify whether the CRL is valid. If the CRL is valid, the post-quantum public key certificate of the mirror can be verified based on the CRL and the certificate chain.
[0220] Verifying the validity of a CRL can be achieved through S301; verifying the post-quantum public key certificate of a mirror based on the CRL and certificate chain can be achieved through S302 and S303.
[0221] S301, verify whether the CRL of the quantum public key certificate is valid.
[0222] For example, when implementing S301, you can refer to Figure 5a The text description explains the principles behind "1. CRL issuer certificate verification" and "2. CRL digital signature verification" to verify the legitimacy of the CRL.
[0223] 1. CRL issuer certificate verification
[0224] Parsing the CRL data yields the CRL issuer certificate, and the validity period information of the CRL issuer certificate is then used to... Figure 5a (Not shown) is used to determine whether the CRL issuer certificate is valid; if the CRL issuer certificate is not valid, the mirror verification will fail.
[0225] If the CRL issuer certificate is valid, the public key used to verify the digital signature of the CRL can be obtained from the CRL issuer certificate (the aforementioned CRL post-quantum public key certificate). It should be noted that the aforementioned CRL post-quantum public key certificate is not the public key certificate for mirror or program verification in the aforementioned post-quantum public key algorithm (e.g., the Dilithium certificate in the Certificate field).
[0226] 2. CRL digital signature verification;
[0227] Next, the signature information of the CRL (e.g., using the CRL-post quantum public key certificate) is applied. Figure 5a Verify the Dilithium certificate (Crl) within the Crrl field shown.
[0228] Wherein, if the CRL verification after the signature passes, it indicates the signature of the CRL (e.g. Figure 5a If the Dilithium certificate (Crl) in the Crl field shown passes verification, it means the CRL is valid. Otherwise, if the digital signature verification of the CRL fails, it means the CRL is invalid, and the mirror verification will fail.
[0229] If the CRL is valid, then S302 is executed; otherwise, it means that the CRL is invalid, which means that the image verification fails and error handling can be performed.
[0230] S302, verify whether the quantum public key certificate is within this CRL.
[0231] For example, CRL and post-quantum public key certificate information can be obtained from CMS data.
[0232] The post-quantum public key certificate information may include, but is not limited to: Figure 5a The Certificate field contains the Dilithium certificate, the issuer field contains the Dilithium certificate name, and the serial number field contains the Dilithium certificate serial number.
[0233] Then, it can be detected whether there are any related Dilithium certificates, Dilithium certificate distinguishable names, and Dilithium certificate serial numbers within the CRL.
[0234] If the Dilithium certificate, its distinguishable name, and its serial number described in the fields extracted from the CMS data do not exist in the CRL, it means that the Dilithium certificate carried in the CMS data is not in the CRL, indicating that the post-quantum public key certificate (here, the Dilithium certificate) has not been revoked, and thus S303 is executed; otherwise, if the Dilithium certificate, its distinguishable name, and its serial number described in the fields extracted from the CMS data exist in the CRL, it means that the Dilithium certificate carried in the CMS data has been revoked, further indicating that the mirror verification failed, and error handling can be performed.
[0235] S303 verifies the validity of the quantum public key certificate.
[0236] Based on the certificate chain obtained from the CMS data, if the post-quantum public key certificate is found to be within the certificate chain, it indicates that the post-quantum public key certificate is valid and S304 can be executed; if the post-quantum public key certificate is not found to be within the certificate chain, it indicates that the post-quantum public key certificate is invalid, which in turn indicates that the mirror verification fails and error handling can be performed.
[0237] In this application, the certificate chains carried by the CMS data corresponding to the multiple images of the device are generally the same, and this application does not impose any restrictions on this.
[0238] by Figure 5a For example, in the case of... Figure 4 If the field values extracted from the Certificate field (e.g., Dilithium certificate), the field values extracted from the issuer field (Dilithium certificate distinguishable name), and the field values extracted from the serialNumber field (e.g., Dilithium certificate serial number) all exist in a mutually related chain in the certificate chain, then the Dilithium certificate is valid.
[0239] From such Figure 5a If the field values extracted from the Certificate field (e.g., Dilithium certificate), the field values extracted from the issuer field (Dilithium certificate distinguishable name), and the field values extracted from the serialNumber field (e.g., Dilithium certificate serial number) do not exist in a related chain in the certificate chain, then the Dilithium certificate is invalid.
[0240] By using S301 to S303 above, it can be determined that the post-quantum public key certificate information of the image has been verified. Then, the post-quantum digital signature information of the image can be verified through S304, or optionally S305.
[0241] S304 verifies post-quantum digital signatures based on post-quantum public key certificate information.
[0242] by Figure 5a For example, in Figure 5a The process has already obtained the field value of the signature field from the CMS data, specifically the mirrored post-quantum digital signature, such as the Dilithium algorithm signature; and the field value has already obtained from the CMS data such as Figure 5a The field values of the signatureAlgorithm field shown are specifically the relevant parameters of the post-quantum public key algorithm, such as the Dilithium algorithm identifier and parameters.
[0243] Subsequently, it can be based on post-quantum public-key algorithms (e.g., ...Figure 5a The Dilithium algorithm identifier and parameters shown), and the mirrored post-quantum public key certificate (e.g., Figure 5a The image shows the Dilithium certificate, Dilithium certificate distinguishable name, Dilithium certificate serial number, and the image's signature attributes (e.g., ...). Figure 5a The attributes within the dashed boxes shown are used to evaluate the post-quantum digital signature of the mirror image (e.g., ...). Figure 5a The Dilithium algorithm signature shown is verified to obtain the verification result of the mirrored post-quantum digital signature.
[0244] If the post-quantum digital signature verification of the mirror image passes, S305 can be executed; if the post-quantum digital signature verification of the mirror image fails, it indicates that the post-quantum digital signature of the mirror image has been tampered with (e.g., ...). Figure 5a (The signature attribute within the dashed box shown has been tampered with), the post-quantum digital signature verification of the mirror image fails, indicating that the mirror image verification fails and error handling can be performed.
[0245] S305, Verify the image digest.
[0246] For example, a digest algorithm that can obtain a mirror image from CMS data; and from, for example Figure 5a The image digests obtained from each signature attribute within the dashed box shown, such as the field value of the MessageDigest field.
[0247] For example, Figure 7 The field value of the eContent field shown indicates the storage location of the image;
[0248] Then the value of the eContent field can be extracted from the CMS data, and the image can be obtained based on the value of this field;
[0249] Then, using this digest algorithm, a digest of the image is calculated;
[0250] Next, the calculated summary can be compared with that obtained from... Figure 5b The value of the MessageDigest field extracted from the CMS data shown (specifically, the image's digest) is compared. If they are the same, it means the image's digest has not been tampered with, indicating that the image's digest verification has passed. If the calculated digest matches the value from the data... Figure 1 If the values of the MessageDigest field extracted from the CMS data shown are different (specifically, the image's digest), it indicates that the image's digest has been tampered with, thus indicating that the image's digest verification fails.
[0251] If all of the above verifications in S301 to S305 pass, the image verification is successful; if at least one of the above verifications in S301 to S305 fails, the image verification fails.
[0252] In this embodiment of the application, without changing the CMS data structure, the fields used to store digital signatures, signature attributes, public key certificates, and CRL signatures related to the public key algorithm are used to store the mirrored digital signatures, signature attributes, public key certificates, and CRL post-quantum signatures related to the post-quantum public key algorithm. This enables secure booting of the post-quantum algorithm based on the existing data structure of the CMS, avoiding attacks on the quantum computer during the secure boot process.
[0253] The following is combined with Figure 5a and Figure 5b This paper will introduce another implementation of the method in this application.
[0254] Please refer to Figure 5b , Figure 1 Let's take a look Figure 1 ,like Figure 5b The data structure of the CMS data shown in this application is as follows: Figure 5b The original data structure of the CMS data shown is unchanged. The outer data structure of the CMS is not changed, but the process is performed in the internal domain segment so that there is no change to the interface of the outer system, which has excellent backward compatibility.
[0255] Compared to Figure 5b Please refer to Figure 5b This application adds the following internal field segments to the CMS data structure:
[0256] A new Certificate field has been added within the CertificateChoices field, resulting in two Certificate fields with the same name, used to store ECDSA certificates and Dilithium certificates respectively.
[0257] A new Cr1 field has been added to the RevocationFochoices field, so that the two Cr1 fields with the same name in the RevocationFochoices field are used to store the ECDSA certificate Cr1 and the Dilithium certificate Cr1, respectively.
[0258] A new SignerInfo field has been added within the SignerInfos field, so that the two SignerInfo fields with the same name within the SignerInfos field can be used to store ECDSA-related information and Dilithium-related information for the image, respectively. This information may include public key certificate information, public key algorithm information, signature attribute information, digital signature information, etc.
[0259] Among them, due to such Figure 1 The CMS shown is a mirror image of the corresponding CMS data, making it as follows Figure 5b The field values of all signature attributes within the two dashed boxes shown are the same, except for the field values related to the signature time (e.g., the Time field).
[0260] Figure 5a For an explanation of the field values stored in each field of ECDSA and the process of verifying the image during secure boot, please refer to [link to documentation / reference]. Figure 7 Related introduction, Figure 5a For an explanation of the field values stored in each field of Dilithium and the process of verifying the image, please refer to [link / reference needed]. Figure 6 The relevant procedures will not be elaborated here.
[0261] like Figure 1 As shown, the process may include the following steps:
[0262] S401 retrieves the CMS data corresponding to the image before the image is run.
[0263] S402a, based on CMS data, performs post-quantum verification on the image.
[0264] The implementation process of S402a is similar to that of the methods in the above embodiments, for example, refer to Figure 2 and Figure 5b And related implementation examples.
[0265] S402b performs traditional verification on the image based on CMS data.
[0266] The implementation process of S402b is similar to that in the related technologies described above (e.g., Figure 5b , Figure 1 The verification process is similar to that shown in the diagram.
[0267] S402a and S402b can be executed serially or in parallel. This application does not restrict the execution order of S402a and S402b.
[0268] If both S402a and S402b pass the verification, then S405 is executed.
[0269] S405 allows the above image to be run.
[0270] In another possible implementation, prior to S402a and S402b, the method may further include:
[0271] Determine a single digital signature in the CMS data that carries only the image.
[0272] This single digital signature can be a signature made to the image using a traditional public-key algorithm and the corresponding private key (referred to as a traditional digital signature), for example... Figure 5b The ECDSA algorithm signature in the signature field shown.
[0273] Alternatively, the single digital signature can be a signature made to the image using a post-quantum public-key algorithm and the corresponding private key (referred to as a post-quantum digital signature), for example... Figure 5b The Dilithium algorithm signature is shown in the signature field.
[0274] If the single digital signature is a traditional digital signature, then S402b is executed, for example, according to... Figure 5b The verification process shown performs a mirror verification.
[0275] If the single digital signature is a post-quantum digital signature, then S402a is executed, for example, the image can be verified according to the methods of the various embodiments described above in this application.
[0276] In another possible implementation, prior to S402a and S402b, the method may further include:
[0277] The CMS data is determined to include the mirror's conventional digital signature (also referred to as the third digital signature information) and the mirror's post-quantum digital signature (also referred to as the first digital signature information); or, the CMS data is determined to include the mirror's first public key certificate information (corresponding to the public key certificate of the conventional public key algorithm) and third public key certificate information (corresponding to the public key certificate of the post-quantum public key algorithm).
[0278] Specifically, the system can determine whether each field in the parsed CMS data contains public key certificate information for both traditional public key algorithms, based on a pre-configured list of public key certificate information for traditional public key algorithms and / or a list of public key certificate information for post-quantum public key algorithms.
[0279] For example, it can be based on such Figure 5bThe ECDSA certificate distinguishable name in the issuer field and the Dilithium certificate distinguishable name in another issuer field are matched with the two lists mentioned above. The ECDSA certificate distinguishable name can be matched with the list of public key certificate information for traditional public key algorithms, and the Dilithium certificate distinguishable name can be matched with the list of public key certificate information for post-quantum public key algorithms. Thus, it is determined that the CMS data includes both the traditional digital signature and the post-quantum digital signature of the mirror.
[0280] It should be understood that using the issuer field value to match with lists of two public key certificate information is merely one exemplary implementation. Alternatively, the values of other fields in the CMS data can be compared with relevant lists of traditional and post-quantum public key algorithms to determine whether the CMS data contains digital signatures that mirror each of the two public key algorithms.
[0281] As an example, the following describes the processing steps of CMS data obtained after digitally signing a mirror image using traditional public-key algorithms and post-quantum public-key algorithms, respectively, to achieve mirror image verification:
[0282] Step 1: Obtain CMS messages and parse them.
[0283] First, ASN.1 decoding is performed, yielding the relevant data structure, including fields such as certificate, CRL, and signature message. When retrieving the certificate, CRL, and signature message, in a hybrid traditional + post-quantum scenario, the certificate involved in the traditional public-key algorithm (e.g., ...) will also be retrieved. Figure 5b The Certificate field shown), CRL (such as) Figure 5b The Ctrl field shown), fields of the signature message (such as...) Figure 5b The SignerInfo field shown) and the certificate involved in the post-quantum public key algorithm (such as...) Figure 5b The Certificate field shown), CRL (such as) Figure 5b The Ctrl field shown), fields of the signature message (such as...) Figure 5b The SignerInfo field shown in the image contains a total of 6 fields.
[0284] Internal CMS verification requires executing steps 2 through 5 for both traditional and post-quantum related structures, resulting in steps 2 through 5 being executed twice. However, the field values processed in the two executions differ. For example, one execution might target the public key certificate involved in traditional public key algorithms (such as...). Figure 5b The Certificate field shown), CRL (such as) Figure 5b The Ctrl field shown), fields of the signature message (such as...) Figure 5bThe SignerInfo field shown is one example; another is for public key certificates involved in post-quantum public key algorithms (such as...). Figure 8 The Certificate field shown), CRL (such as) Figure 9 The Ctrl field shown), fields of the signature message (such as...) Figure 9 The SignerInfo field shown is validated.
[0285] Step 2: CRL verification. Check if CRL verification is enabled, retrieve the CRL issuer certificate, check the CRL validity period, obtain the public key to verify the CRL signature, and check if the certificate is in the CRL.
[0286] Step 3: Verify the validity of the certificate through the certificate chain.
[0287] Specifically, when verifying public key certificates involved in traditional public key algorithms and public key certificates involved in quantum public key algorithms through certificate chains, it is only necessary to extract the certificate chain once from the CMS data corresponding to the image, and use the same certificate chain to verify the validity of the above two types of public key certificates.
[0288] Step 4: Signature attribute verification. The signature attributes mainly include the Timer field and the MessageDigest field. The signature attribute is used to verify the signature using the public key certificate corresponding to the private key.
[0289] Step 5: Obtain econtent and digest algorithm, calculate the digest value of the data corresponding to econtent, then obtain the digest value in the signature attribute, and compare whether the two are equal. If they are equal, the verification passes.
[0290] Step 6: Since the single-composite CMS contains both traditional and post-quantum domain segments, only when both are verified can the safe startup of the traditional + post-quantum domain be considered complete.
[0291] In this embodiment, the CMS format is extended to fields such as Certificate, CRL, and Singerinfos to support hybrid post-quantum secure boot schemes. Each field includes both traditional public key algorithm fields and post-quantum public key algorithm fields. Based on the existing CMS format, the post-quantum extended fields can flexibly support both traditional secure boot and post-quantum secure boot.
[0292] The post-quantum extension based on CMS enables the post-quantum secure boot scheme based on CMS to possess quantum resistance properties.
[0293] In one possible implementation, please refer to Figure 9This application provides a verification device 800. The device includes: an acquisition module 801, used to acquire Cryptographic Message Syntax (CMS) data corresponding to the target object before the target object is run; a verification module 802, used to verify the target object based on the CMS data, wherein the CMS data includes first public key certificate information corresponding to the target object and first digital signature information of the target object, the first digital signature information including information obtained by signing the target object based on a first public key algorithm and the first private key of the target object, the first public key algorithm being a post-quantum public key algorithm, and the first public key certificate information and the first private key being a pair of key information related to the first public key algorithm; and a control module 803, used to allow the target object to run if the target object verification passes.
[0294] In one possible implementation, the verification module 802 is specifically used to: obtain the first public key certificate information based on the CMS data; and verify the first public key certificate information.
[0295] In one possible implementation, the verification module 802 is specifically used to: obtain a CRL and a certificate chain based on the CMS data; and verify the first public key certificate information based on the CRL and the certificate chain.
[0296] In one possible implementation, the verification module 802 is specifically used to: obtain the first digital signature information based on the CMS data; and verify the first digital signature information of the target object based on the first public key certificate information if the first public key certificate information is verified successfully.
[0297] In one possible implementation, the verification module 802 is specifically used to: obtain a first signature attribute and a first public key algorithm corresponding to the first digital signature information based on the CMS data; and verify the first digital signature information based on the first public key algorithm, the first public key certificate information, and the first signature attribute.
[0298] In one possible implementation, the verification module 802 is specifically used to: obtain second digest information of the target object based on the CMS data; and verify the second digest information based on the first digest information if the first digital signature information is verified successfully.
[0299] In one possible implementation, the verification module 802 is specifically configured to: obtain, based on the CMS data, the second digital signature information of the CRL and the second public key certificate information corresponding to the CRL, wherein the second digital signature information includes information obtained by signing the CRL based on the first public key algorithm and the second private key of the CRL issuer, and the second public key certificate information and the second private key are a pair of key information related to the first public key algorithm; and verify the second digital signature information of the CRL based on the second public key certificate information.
[0300] In one possible implementation, the CMS data further includes third public key certificate information corresponding to the target object and third digital signature information of the target object. The third digital signature information includes information obtained by signing the target object based on the second public key algorithm and the third private key of the target object. The second public key algorithm is not a post-quantum public key algorithm. The third public key certificate information and the third private key are a pair of key information related to the second public key algorithm.
[0301] The effects and implementation methods of the verification device 800 in the above embodiments are similar to those of the methods in the above embodiments, and will not be described again here.
[0302] Figure 10 This is a schematic diagram of the structure of a device 500 provided in an embodiment of this application. Figure 10 As shown, the device 500 may include: a processor 501, optionally a transceiver 505, and optionally a memory 502.
[0303] The transceiver 505, also known as a transceiver unit, transceiver, or transceiver circuit, is used to implement transceiver functions. The transceiver 505 may include a receiver and a transmitter. The receiver, also known as a receiver circuit, is used to implement the receiving function; the transmitter, also known as a transmitter or transmitting circuit, is used to implement the transmitting function.
[0304] The transceiver 505 can also be a communication interface.
[0305] The memory 502 may store computer programs, software code, or instructions 504, which may also be referred to as firmware. The processor 501 can implement the verification methods provided in the embodiments of this application by running the computer programs, software code, or instructions 503 therein, or by calling the computer programs, software code, or instructions 504 stored in the memory 502. The processor 501 may be a central processing unit (CPU), and the memory 502 may be, for example, a read-only memory (ROM) or a random access memory (RAM).
[0306] The processor 501 and transceiver 505 described in this application can be implemented on integrated circuits (ICs), analog ICs, radio frequency integrated circuits (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), printed circuit boards (PCBs), electronic devices, etc.
[0307] Optionally, the device 500 may also include an antenna 506. The modules included in the device 500 are merely illustrative examples and are not intended to limit the scope of this application.
[0308] For example, the structure of the verification device can be unaffected by The verification device can be a standalone device or part of a larger device. For example, the verification device can be implemented as follows:
[0309] (1) A standalone integrated circuit IC, or chip, or chip system or subsystem; (2) A collection of one or more ICs, optionally including storage components for storing data or instructions; (3) A module that can be embedded in other devices; (4) Vehicle equipment, etc.; (5) Others, etc.
[0310] For the implementation of device 500 as a chip or chip system, please refer to... The diagram shows the structure of the chip. The chip shown includes a processor 601, and optionally, an interface 602. The number of processors 601 can be one or more, and the number of interfaces 602 can be multiple. Optionally, the chip or chip system may include a memory 603. The processor 601 is used to call and execute instructions from the interface 602. When the processor 601 executes the instructions, it can perform the steps of the above-described method embodiments.
[0311] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.
[0312] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a computer to control the computer to implement the above-described method embodiments.
[0313] Based on the same technical concept, this application also provides a computer program, which, when executed, is used to implement the above-described method embodiments.
[0314] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.
[0315] Based on the same technical concept, embodiments of this application also provide a chip, including a processor. The processor can implement the above-described method embodiments.
[0316] The steps of the methods or algorithms described in conjunction with 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), 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 well known in the art. An exemplary storage medium is coupled to a 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.
[0317] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.
[0318] 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 method of checking, characterized by, The method comprises: Before running of a target object, acquiring CMS data corresponding to the target object; Based on the CMS data, the target object is checked, wherein the CMS data includes first public key certificate information corresponding to the target object and first digital signature information of the target object, the first digital signature information includes information obtained by signing the target object based on a first public key algorithm and a first private key of the target object, the first public key algorithm is a post-quantum public key algorithm, and the first public key certificate information and the first private key are a pair of key information related to the first public key algorithm; In the case that the target object passes the check, the target object is allowed to run.
2. The method of claim 1, wherein, The checking of the target object based on the CMS data comprises: Based on the CMS data, the first public key certificate information is obtained; The first public key certificate information is verified.
3. The method of claim 2, wherein, The verification of the first public key certificate information comprises: Based on the CMS data, CRL and a certificate chain are obtained; Based on the CRL and the certificate chain, the first public key certificate information is verified.
4. The method according to any one of claims 1 to 3, characterized in that, The checking of the target object based on the CMS data comprises: Based on the CMS data, the first digital signature information is obtained; In the case that the first public key certificate information passes the verification, the first digital signature information of the target object is verified based on the first public key certificate information.
5. The method of claim 4, wherein, The verification of the first digital signature information of the target object based on the first public key certificate information comprises: Based on the CMS data, a first signature attribute corresponding to the first digital signature information and the first public key algorithm are obtained; Based on the first public key algorithm, the first public key certificate information and the first signature attribute, the first digital signature information is verified.
6. The method of claim 5, wherein, The first signature attribute includes first digest information of the target object, and the checking of the target object based on the CMS data further comprises: Based on the CMS data, second digest information of the target object is obtained; In the case that the first digital signature information passes the verification, the second digest information is verified based on the first digest information.
7. The method according to any one of claims 1 to 6, characterized in that, The checking of the target object based on the CMS data comprises: Based on the CMS data, second digital signature information of the CRL and second public key certificate information corresponding to the CRL are obtained, the second digital signature information includes information obtained by signing the CRL based on the first public key algorithm and a second private key of a CRL issuer, and the second public key certificate information and the second private key are a pair of key information related to the first public key algorithm; Based on the second public key certificate information, the second digital signature information of the CRL is verified.
8. The method according to any one of claims 1 to 7, characterized in that, The CMS data further includes third public key certificate information corresponding to the target object and third digital signature information of the target object, the third digital signature information includes information obtained by signing the target object based on a second public key algorithm and a third private key of the target object, the second public key algorithm is not a post-quantum public key algorithm, and the third public key certificate information and the third private key are a pair of key information related to the first public key algorithm.
9. A checking device, characterized in that The verification device includes: An acquisition module, configured to acquire, before a target object runs, cryptographic message syntax (CMS) data corresponding to the target object; A verification module, configured to verify the target object based on the CMS data, wherein the CMS data includes first public key certificate information corresponding to the target object and first digital signature information of the target object, the first digital signature information includes information obtained by signing the target object based on a first public key algorithm and a first private key of the target object, the first public key algorithm is a post-quantum public key algorithm, and the first public key certificate information and the first private key are a pair of key information related to the first public key algorithm; A control module, configured to allow the target object to run if the target object passes the verification.
10. The apparatus of claim 9, wherein, The verification module is specifically configured to: Obtain the first public key certificate information based on the CMS data; Verify the first public key certificate information.
11. The apparatus of claim 10, wherein, The verification module is specifically configured to: Obtain a certificate revocation list (CRL) and a certificate chain based on the CMS data; Verify the first public key certificate information based on the CRL and the certificate chain.
12. The apparatus of any one of claims 9 to 11, wherein, The verification module is specifically configured to: Obtain the first digital signature information based on the CMS data; Verify the first digital signature information of the target object based on the first public key certificate information if the first public key certificate information passes the verification.
13. The apparatus of claim 12, wherein, The verification module is specifically configured to: Obtain a first signature attribute corresponding to the first digital signature information and the first public key algorithm based on the CMS data; Verify the first digital signature information based on the first public key algorithm, the first public key certificate information, and the first signature attribute.
14. The apparatus of claim 13, wherein, The verification module is specifically configured to: Obtain second digest information of the target object based on the CMS data; Verify the second digest information based on the first digest information if the first digital signature information passes the verification.
15. The apparatus of any one of claims 9 to 14, wherein, The verification module is specifically configured to: Obtain second digital signature information of a CRL and second public key certificate information corresponding to the CRL based on the CMS data, the second digital signature information includes information obtained by signing the CRL based on the first public key algorithm and a second private key of a CRL issuer, and the second public key certificate information and the second private key are a pair of key information related to the first public key algorithm; Verify the second digital signature information of the CRL based on the second public key certificate information.
16. The apparatus of any one of claims 9 to 15, wherein, The CMS data further comprises third public key certificate information corresponding to the target object and third digital signature information of the target object, the third digital signature information comprising information obtained by signing the target object based on a second public key algorithm and a third private key of the target object, the second public key algorithm not being a post-quantum public key algorithm, and the third public key certificate information and the third private key being a pair of key information related to the second public key algorithm.
17. A computer-readable storage medium, characterized in that, A computer program is included, which, when running on a computer or a processor, causes the computer or the processor to perform the method according to any one of claims 1 to 8.
18. A checking device, characterized in that A processor is included, which, when executing computer instructions, is configured to perform the method according to any one of claims 1 to 8.
19. A computer program product, characterised in that, The computer program product comprises a software program, which, when executed by a computer or a processor, causes the steps of the method according to any one of claims 1 to 8 to be performed.