Digital certificate implementation method based on Merkel tree

Abstract

The invention discloses a digital certificate implementation method based on a Merkel tree, and belongs to the technical field of digital certificates.The digital certificate implementation method comprises a certificate generation scheme and a certificate signature validity verification scheme, and the certificate generation scheme comprises the following steps that 1, a terminal generates a certificate request; step 2, the terminal submits a certificate request to a CA mechanism; step 3, the CA constructs a digital certificate TBSCertifiate (TBSCertifiate); 4, the CA signs the TBSCertifiate constructed in the construction step, and a signature value S is obtained; 5, the CA sends the signature value S to a signature storage service system; step 6, waiting for the signature storage service system to return, wherein the return value comprises: (1) a signature hash value generated by the signature storage system; (2) signing an authentication path generated by the storage system; and (3) signing the Merkel tree root hash value generated by the storage system. According to the digital certificate implementation method based on the Merkel tree, the certificate signature value is stored to the third-party system based on the signature storage system and the Merkel tree structure, and the certificate size is greatly reduced.

Description

Technical Field

[0001] The present invention belongs to the technical field of digital certificates, and in particular, to a method for implementing digital certificates based on a Merkle tree. Background Art

[0002] X.509 is a digital certificate standard widely used in the public key infrastructure (PKI), defined by the International Telecommunication Union (ITU-T). The X.509 certificate provides a basic guarantee for identity authentication and data encryption in network communication by binding the public key with the identity information of entities (such as individuals, devices, or organizations). Its core goal is to establish a trust chain so that the two communicating parties can securely exchange encrypted data and verify their identities.

[0003] The prior art mainly includes the following steps: 1. The terminal generates a certificate request; 2. The terminal submits the certificate request to the CA institution; The CA (Digital Certificate Authentication System) constructs and issues a digital certificate. The following is the digital certificate format: Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] EXPLICIT Extensions OPTIONAL } 4. The CA returns the digital certificate to the terminal.

[0004] The limitation of the prior art is that if the signature value field (signatureValue) of the digital certificate generated by the CA institution stores a post-quantum signature value, since the post-quantum signature algorithm usually generates relatively large signature data, this will cause a significant increase in the overall size of the digital certificate. This problem of size expansion is particularly prominent in resource-constrained devices, such as IoT devices and mobile devices, which have limited storage space and are difficult to efficiently process large-sized digital certificates. Summary of the Invention

[0005] The purpose of the present invention is to provide a method for implementing a digital certificate based on a Merkle tree to solve the problems proposed in the background technology.

[0006] To achieve the above purpose, the present invention provides the following technical solution: A method for implementing a digital certificate based on a Merkle tree, including a certificate generation scheme and a certificate signature validity verification scheme. Among them, the certificate generation scheme includes the following steps: Step 1. The terminal generates a certificate request; Step 2. The terminal submits the certificate request to the CA institution; Step 3. The CA constructs the digital certificate TBSCertificate; Step 4. The CA signs the TBSCertificate constructed in the construction step to obtain the signature value S; Step 5. The CA sends the signature value S to the signature storage service system; Step 6. Wait for the return of the signature storage service system. The return value includes: (1) The signature hash value generated by the signature storage system; (2) The authentication path generated by the signature storage system; (3) The Merkle root hash value generated by the signature storage system; Step 7. The CA adds the content returned by the signature storage system to the signature list extension item according to the following structure; Step 8. The CA sets the certificate signatureAlgorithm field to the actual signature algorithm identifier; Step 9. The CA sets the certificate signatureValue field to Null to complete the construction and issuance of the digital certificate. Step Ten: The CA returns the certificate to the terminal.

[0007] Preferably, the specific definition of the signature list extension item: --SssIDExtension: Used to save the ID of the signature storage service SssIDExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, -- Extension identifier, 1.3.6.1.4.1.46210.400.1) Critical, BOOLEAN DEFAULT FALSE, -- Whether the extension is critical extnValue, OCTETSTRING, -- Signature storage system service identifier. When verifying the certificate, the system has built-in the mapping relationship between the service ID and the SSS service URL} --MerklePathExtension: Used to save the authentication path of the MerkleTree MerklePathExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, -- Extension identifier, 1.3.6.1.4.1.46210.400.2) Critical, BOOLEAN DEFAULT FALSE, -- Default non-critical extnValue, OCTETSTRING, -- Authentication path} Among them, the MerklePath structure contains data composed of the hash values of each node in the authentication path and their position information, ensuring that the verifier can verify the existence and correctness of the corresponding signature hash value in the Merkle tree through this authentication path; --MerkleRootExtension: Used to save the root hash value of the MerkleTree MerkleRootExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, -- Extension identifier, 1.3.6.1.4.1.46210.400.3) Critical, BOOLEAN DEFAULT FALSE, -- Default non-critical extnValue, OCTETSTRING -- Root hash value} This extension ensures that the digital certificate carries a compact representation of the aggregated signature data. When verifying the integrity of the certificate, the verifier can use this root hash value to quickly check the validity of multiple signature data; --SignHashExtension: Used to save the hash value of the certificate signature value SignHashExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, -- Extension identifier, 1.3.6.1.4.1.46210.400.4) Critical, BOOLEAN DEFAULT FALSE, -- Default non-critical extnValue, OCTETSTRING -- Hash value of the signature value}

[0008] Preferably, the certificate signature validity verification scheme includes the following steps: Step 1, Parse the certificate; Step 2, Extract the root hash value: Used for subsequent integrity verification of the Merkle authentication; Step 3, Extract the authentication path: Includes the authentication path from the hash value of the signature data to the Merkle tree root; Step 4, Extract the signature storage system service identifier: Then query the interface address of the SSS system according to the SssID, and the interface address of the SSS is pre-built in the verification system; Step 5, Extract the hash of the signature value: This hash value is used as the leaf node data for subsequent verification of the correspondence with the complete signature S; Step 6, Reconstruct the tree root using the Merkle proof (1) The verifier uses the Merkle authentication path and leaf node data extracted from the certificate to perform step-by-step hashing operations according to a pre-defined hashing algorithm, and finally calculates a "calculated tree root"; (2) Compare the calculated tree root with the Merkle tree root hash stored in the certificate: If the two are the same, it proves that the aggregation of the signature data is complete and has not been tampered with. If they are different, it indicates that there may be problems during the aggregation data process or the transmission process, the verification fails, and the process ends; Step 7, Construct a request message for querying the signature value of the SSS system. The message content includes at least the following fields: (1) Serial number and issuer information, used to uniquely identify the signature data; (2) Hash of the signature value, used to query the signature value; (3) Timestamp, used to prevent replay attacks; Step 8. Query the signature value S of the certificate based on the interface address in Step 4 and the message in Step 6; Step 9. Verify the signature value of the certificate (1) According to the signature algorithm signatureAlgorithm in the certificate, then use the issuer's public key and the signature value S to verify the validity of the certificate signature value. Note: When verifying the signature value, the following extension items need to be removed from the signed original text: SssIDExtension, MerklePathExtension, MerkleRootExtension, SignHashExtension (2) If the signature value verification passes, the certificate is valid; if the signature value verification fails, the certificate is invalid.

[0009] Compared with the prior art, the technical effects and advantages of the present invention: This implementation method of digital certificate based on Merkle tree effectively solves the problem of over - sized certificate size in resource - limited scenarios caused by over - sized signature values in certificates; This implementation method of digital certificate based on Merkle tree is applicable to post - quantum algorithm certificates; This implementation method of digital certificate based on Merkle tree, based on the signature storage system and Merkle tree structure, stores the certificate signature value in a third - party system, greatly reducing the certificate size. Description of the Drawings

[0010] Figure 1 is the flowchart of the certificate generation scheme of the present invention; Figure 2 is the flowchart of the certificate signature validity verification scheme of the present invention. Detailed Embodiments

[0011] In the following description, a large number of specific details are given to provide a more thorough understanding of the present invention. However, it is obvious to those skilled in the art that the present invention can be implemented without one or more of these details. In other examples, some well - known technical features are not described to avoid confusion with the present invention.

[0012] Please refer to Figures 1 to 2 , an implementation method of digital certificate based on Merkle tree, including a certificate generation scheme and a certificate signature validity verification scheme. Among them, the certificate generation scheme includes the following steps: Step 1. The terminal generates a certificate request; Step 2. The terminal submits the certificate request to the CA institution; Step 3. The CA constructs the digital certificate TBSCertificate; Step 4: The CA signs the TBSCertificate constructed in the CA pair construction step to obtain the signature value S; Step 5: The CA sends the signature value S to the signature storage service system; Step 6: Wait for the return of the signature storage service system. The return value includes: (1) The signature hash value generated by the signature storage system; (2) The authentication path generated by the signature storage system; (3) The Merkle tree root hash value generated by the signature storage system; Step 7: The CA adds the content returned by the signature storage system to the signature list extension item according to the following structure; Step 8: The CA sets the certificate signatureAlgorithm field to the actual signature algorithm identifier; Step 9: The CA sets the certificate signatureValue field to Null to complete the construction and issuance of the digital certificate; Step 10: The CA returns the certificate to the terminal.

[0013] Preferably, the specific definition of the signature list extension item: --SssIDExtension: Used to save the ID of the signature storage service SssIDExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, -- Extension identifier, 1.3.6.1.4.1.46210.400.1) Critical, BOOLEAN DEFAULT FALSE, -- Whether the extension is critical extnValue, OCTETSTRING, -- Signature storage system service identifier. When verifying the certificate, the system has a built-in mapping relationship between the service ID and the SSS service URL} --MerklePathExtension: Used to save the authentication path of the MerkleTree MerklePathExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, -- Extension identifier, 1.3.6.1.4.1.46210.400.2) Critical, BOOLEAN DEFAULT FALSE, -- Default non-critical extnValue, OCTETSTRING, -- Authentication path} Among them, the MerklePath structure contains data composed of the hash values of each node in the authentication path and their position information, ensuring that the verifier can verify the existence and correctness of the corresponding signature hash value in the Merkle tree through this authentication path; --MerkleRootExtension: Used to store the root hash value of the MerkleTree MerkleRootExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, -- Extension identifier, 1.3.6.1.4.1.46210.400.3) Critical, BOOLEAN DEFAULT FALSE, -- Default non-critical extnValue, OCTETSTRING -- Root hash value} This extension item ensures that the digital certificate carries a compact representation after aggregating the signature data. When the verifier performs integrity verification on the certificate, the root hash value can be used to quickly check the validity of multiple signature data; --SignHashExtension: Used to store the hash value of the certificate signature value SignHashExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, -- Extension identifier, 1.3.6.1.4.1.46210.400.4) Critical, BOOLEAN DEFAULT FALSE, -- Default non-critical extnValue, OCTETSTRING -- Hash value of the signature value}.

[0014] Preferably, the certificate signature validity verification scheme includes the following steps: Step 1, Parse the certificate; Step 2, Extract the root hash value: For subsequent integrity verification of the Merkle authentication; Step 3, Extract the authentication path: Include the authentication path from the hash value of the signature data to the Merkle tree root; Step 4, Extract the signature storage system service identifier: Then query the interface address of the SSS system according to the SssID, and the interface address of the SSS is pre-built in the verification system; Step 5, Extract the hash of the signature value: This hash value is used as the leaf node data for subsequent verification of the correspondence with the complete signature S; Step 6, Reconstruct the tree root using the Merkle proof (1) The verifier uses the Merkle authentication path and leaf node data extracted from the certificate to perform step-by-step hashing operations according to a predefined hashing algorithm, and finally calculates a "calculated root". (2) Compare the calculated root with the Merkle root hash stored in the certificate: If the two are the same, it proves that the aggregation of the signature data is complete and has not been tampered with. If they are different, it indicates that there may be problems during the aggregation or transmission of the data, the verification fails, and the process ends. Step Seven: Construct a request message for invoking the SSS system to query the signature value. The message content shall include at least the following fields: (1) Serial number and issuer information, used to uniquely identify the signature data. (2) Hash of the signature value, used to query the signature value. (3) Timestamp, used to prevent replay attacks. Step Eight: Query the signature value S of the certificate according to the interface address in Step Four and the message in Step Six. Step Nine: Verify the signature value of the certificate (1) According to the signature algorithm signatureAlgorithm in the certificate, then use the issuer's public key and the signature value S to verify the validity of the certificate signature value. Note: When verifying the signature value, the following extension items need to be removed from the signed original text: SssIDExtension, MerklePathExtension, MerkleRootExtension, SignHashExtension (2) If the signature value verification passes, the certificate is valid. If the signature value verification fails, the certificate is invalid.

[0015] It should be noted that in this article, relational terms such as "one" and "two" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0016] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for implementing a digital certificate based on a Merkle tree, including a certificate generation scheme and a certificate signature validity verification scheme, characterized in that: in, The certificate generation scheme includes the following steps: Step 1: The terminal generates a certificate request; Step 2: The terminal submits the certificate request to the CA organization; Step 3: CA constructs digital certificate TBSCertificate; Step 4: CA signs the TBSCertificate constructed in the construction step to obtain the signature value S; Step 5: CA sends the signature value S to the signature storage service system; Step 6: Wait for the signature storage service system to return. The return value includes: (1) The signature hash value generated by the signature storage system; (2) The authentication path generated by the signature storage system; (3) The Merkle tree root hash value generated by the signature storage system; Step 7: CA adds the content returned by the signature storage system to the signature list extension item according to the following structure; Step 8: The CA sets the certificate signatureAlgorithm field to the actual signature algorithm identifier; Step 9: CA sets the certificate signatureValue field to Null to complete the construction and issuance of the digital certificate; Step 10: CA returns the certificate to the terminal.

2. A method for implementing a digital certificate based on a Merkle tree according to claim 1, characterized in that: The specific definition of the signature list extension item is: --SssIDExtension: used to save the ID of the signature storage service SssIDExtension::=SEQUENCE{ extnID,OBJECTIDENTIFIER,--Extended identifier, 1.3.6.1.4.1.46210.400.1) Critical, BOOLEANDEFAULTFALSE, -- Whether the extension is critical extnValue, OCTETSTRING, --Signature storage system service ID. When verifying the certificate, the system has a built-in mapping relationship between the service ID and the SSS service URL.} --MerklePathExtension: used to save the MerkleTree authentication path MerklePathExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, --Extended identifier, 1.3.6.1.4.1.46210.400.2) Critical, BOOLEANDEFAULTFALSE,--non-critical by default extnValue, OCTETSTRING, --Authentication path} The MerklePath structure contains data consisting of the hash value and location information of each node in the authentication path, ensuring that the verifier can verify the existence and correctness of the corresponding signature hash value in the Merkle tree through the authentication path; --MerkleRootExtension: used to save the root hash value of MerkleTree MerkleRootExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, --Extended identifier, 1.3.6.1.4.1.46210.400.3) Critical, BOOLEANDEFAULTFALSE,--non-critical by default extnValue, OCTETSTRING -- root hash value} This extension ensures that the digital certificate carries a compact representation of the aggregated signature data. When the verifier verifies the integrity of the certificate, the root hash value can be used to quickly check the validity of multiple signature data. --SignHashExtension: used to save the hash value of the certificate signature value SignHashExtension::=SEQUENCE{ extnID, OBJECTIDENTIFIER, --Extended identifier, 1.3.6.1.4.1.46210.400.4) Critical, BOOLEANDEFAULTFALSE,--non-critical by default extnValue, OCTETSTRING -- hash value of signature value}.

3. A method for implementing a digital certificate based on a Merkle tree according to claim 1, characterized in that: The certificate signature validity verification scheme includes the following steps: Step 1: parse the certificate; Step 2: Extract the root hash value: used for subsequent integrity verification of Merkle authentication; Step 3: Extract the authentication path: the authentication path from the hash value of the signature data to the root of the Merkle tree; Step 4: Extract the signature storage system service identifier: Then query the interface address of the SSS system according to the SssID, and verify the interface address of the SSS built-in in the system in advance; Step 5: Extract the hash of the signature value: This hash value is used as the leaf node data for subsequent verification of the corresponding relationship with the complete signature S; Step 6: Reconstruct the root using Merkle proof (1) The verifier uses the Merkle certification path and leaf node data extracted from the certificate to perform hash operations step by step according to a pre-defined hash algorithm, and finally calculates a "calculated tree root"; (2) Compare the calculated root with the Merkle root hash stored in the certificate: If the two are consistent, it proves that the aggregation of the signature data is complete and has not been tampered with. If they are inconsistent, it means that there may be a problem in the data aggregation process or transmission process, the verification fails, and the process ends; Step 7: Construct a request message to call the SSS system to query the signature value. The message content contains at least the following fields: (1) Serial number and issuer information, used to uniquely identify the signature data; (2) A hash of the signature value, used to query the signature value; (3) Timestamp, used to prevent replay attacks; Step 8: Obtain the signature value S of the certificate according to the interface address of step 4 and the message query of step 6; Step 9: Verify the signature value of the certificate (1) According to the signature algorithm signatureAlgorithm in the certificate, the validity of the certificate signature value is verified using the issuer's public key and signature value S. Note: When verifying the signature value, the following extensions need to be removed from the original signature: SssIDExtension, MerklePathExtension, MerkleRootExtension, SignHashExtension (2) If the signature value verification passes, the certificate is valid; if the signature value verification fails, the certificate is invalid.

Images