Electronic certificate signing, issuing and showing method based on block chain distributed digital identity
By using blockchain distributed digital identity technology, the problems of existing electronic certificates being unable to be independently verified, anonymously verified, and selectively presented have been solved, enabling independent verification and privacy protection of electronic certificates and improving the reliability and efficiency of verification.
Patent Information
- Application Number
- CN202510758501.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-09
- Publication Date
- 2025-12-12
AI Technical Summary
Existing electronic certificate technologies cannot achieve self-verification, anonymous verification, and selective presentation and verification, thus failing to meet users' privacy protection needs.
Through blockchain distributed digital identity technology, the issuer creates public and private keys and a blockchain account, generates a certificate request file and stores the certificate information on the blockchain, uses smart contracts to manage the certificate data, and the certificate holder selectively presents plaintext or salted hash information. The verifier verifies the authenticity and integrity of the certificate through the blockchain.
It enables self-verification, anonymous verification, and selective presentation of electronic certificates, ensuring user privacy and information security, and improving the reliability and efficiency of verification.
Smart Images

Figure CN121125151A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the fields of digital identity, digital certificate, electronic license, cryptography and blockchain technology, and particularly relates to an electronic license issuing and presenting method based on a blockchain distributed digital identity. BACKGROUND
[0002] Most of the existing electronic license technologies store and manage user identity information through a server of a license issuer, and a third-party verifier needs to verify user identity or license-related information through a verification interface provided by the license issuer. Another electronic license technology based on CA digital certificate can enable a verifier to independently verify the authenticity of a certificate through a CA root certificate, but cannot realize anonymous verification or selective presentation and verification of part of the content in the license. SUMMARY
[0003] The present application aims to at least solve the problems of electronic licenses that cannot be independently verified, cannot be anonymously verified, and cannot be selectively presented and verified in the prior art, and provides an electronic license issuing and presenting method based on a blockchain distributed digital identity to solve the problems raised in the background.
[0004] To achieve the above-mentioned purpose, the present application provides the following technical solutions: The issuing party creates a pair of public and private keys and a blockchain account through a corresponding blockchain algorithm (Secp256K1, ED25519, SM2, etc.), then creates a certificate request file (CSR) using the pair of public and private keys and attaches a real issuing party entity identity proof file to submit to an authoritative certificate authority (CA).
[0005] After the issuing party obtains the digital certificate (X509 certificate) issued by the authoritative certificate authority, the issuing party calls the smart contract on the blockchain using the blockchain account corresponding to the private key of the digital certificate to store the digital certificate, the license template field to be issued, the digital signature of the issuing party on the license template, and other information on the chain and obtains a DID license template ID.
[0006] The DID license applicant sends the public key corresponding to the blockchain account of the applicant and the necessary information of the applied license to the issuing party.
[0007] The issuing party audits the DID license applicant information according to the process, and after the information is passed, the issuing party generates a corresponding salted hash using each piece of necessary information (license declaration information) of the DID license applicant, then combines each piece of salted hash and executes a hash algorithm again to obtain a license declaration master hash, and then uses a private key to digitally sign the license declaration master hash to obtain a license master credential.
[0008] The issuing party calls the smart contract on the blockchain to store the template ID of the DID certificate, the public key of the certificate applicant, and the main credential on the chain, and returns the DID certificate containing the DID certificate basic information, declaration information, all salted hashes, main credential, template ID, etc. to the applicant.
[0009] Revoking the DID certificate of a certain certificate holder, the issuing party will need to revoke the public key of the certificate holder and the main credential to store the revocation list of the smart contract on the blockchain.
[0010] The presentation method includes: the certificate holder selectively presents the name, extracts the plaintext of the name in the DID certificate of the certificate holder, and extracts the salted hash (ciphertext) of the remaining fields, and then presents the main credential, the public key of the certificate holder, the template ID, the verification challenge, and the digital signature of the verification challenge to the verifier.
[0011] The verifier uses the selectively presented plaintext field (name) to perform a salted hash operation to obtain the corresponding salted hash, and then uses the salted hash combined with the salted hash of the remaining fields to hash again to obtain the main hash of the certificate declaration.
[0012] The verifier queries whether the main credential is revoked by calling the smart contract on the blockchain through the certificate template ID, the public key of the certificate holder, and the main credential, and if not revoked, further queries the corresponding digital certificate of the issuing party, the basic field in the certificate template, and the declaration field.
[0013] The verifier first uses the digital certificate of the issuing party to verify the real entity identity corresponding to the public key of the issuing party according to the X509 certificate verification process, and then uses the public key of the issuing party to decrypt the main credential, and compares the obtained result with the main hash of the certificate declaration obtained before, if the comparison is passed (the values are equal), it indicates that the presented DID certificate information has not been tampered with, and if the issuing party identity is matched successfully, it indicates that the DID certificate is issued by the issuing party declared in the template basic field.
[0014] The verifier uses the public key of the certificate holder to decrypt the digital signature of the verification challenge, and compares the decrypted result with the verification challenge (timestamp or verification code) or the hash of the verification challenge, if the comparison is passed (the values are equal), it indicates that the certificate holder is the holder of the DID certificate corresponding to the public key. BRIEF DESCRIPTION OF DRAWINGS
[0015] The present application will be further described below in conjunction with the drawings and examples: Figure 1 A schematic diagram of an electronic certificate issuing method based on a blockchain distributed digital identity.
[0016] Figure 2A schematic diagram of an electronic certificate presentation method based on a blockchain distributed digital identity. DETAILED DESCRIPTION
[0017] Referring to Figure 1 With Figure 2 The application provides a technical solution for medical personnel qualification certificate issuance and presentation: Step S101, the certificate issuing party creates a public key and a private key and a blockchain account, then creates a certificate request file CSR and submits it to the CA together with the identity file.
[0018] Specifically, the certificate issuing party is the supervising unit (health bureau or health commission) of the medical institution where the medical personnel are located, the Secp256K1 algorithm is used when creating the public and private keys, the blockchain account is in the account format of the EVM chain standard, the certificate request file CSR includes the basic information of the certificate issuing party, the public key of the certificate issuing party, the digital signature of the certificate issuing party, etc., and the CA is a domestic CA with electronic authentication license in accordance with the Electronic Signature Law.
[0019] Step S102, the certificate issuing party stores the certificate basic information and the declaration field, the digital signature of the certificate issuing party, and the digital certificate on the chain to obtain the DID certificate template ID.
[0020] Specifically, the certificate basic information includes the certificate name (physician qualification certificate), the issuing authority (XX health bureau), and the issuing authority website; the declaration field includes name, gender, birth date, professional level, professional category, and other information; the digital signature of the certificate issuing party is the digital signature of the certificate issuing party for the certificate basic information and the declaration field in the certificate template; the digital certificate is the X509 digital certificate obtained from the CA in step S101 to prove the entity identity of the certificate issuing party; and the template ID is a decimal integer returned after calling the TrustvrDID electronic certificate contract related interface on the blockchain.
[0021] Step S103, the DID certificate applicant sends his / her public key corresponding to the blockchain account and the necessary information of the applied certificate to the certificate issuing party.
[0022] Specifically, the DID certificate applicant needs to create a pair of public and private keys and a blockchain account through the user terminal device APP first, and the necessary information of the applied certificate refers to the information required by the certificate issuing party such as name, ID number, and mobile phone number.
[0023] Step S104, after the certificate issuing party approves, the corresponding salted hash, main hash, and main credential are generated.
[0024] Specifically, after receiving the information of the applicant, the certificate issuing party verifies and audits through SMS verification code, real name three elements, and physician qualification certificate database; Salted hashes are generated by combining each necessary piece of information of the applicant, such as name, gender, and date of birth, with the applicant's blockchain account using the DID certificate, and then performing the SHA256 algorithm on the combined result. The result is the salted hash. The main hash is generated by combining all the salted hashes and then performing the SHA256 algorithm again; the result is the main hash. The master credential is generated by the issuing party encrypting the master hash using its own private key, and the result is the master credential.
[0025] In step S105, the issuing party calls the smart contract to store the template ID, the applicant's public key, and the master credential on the blockchain, and returns the applicant's corresponding master credential, salted hash, template ID, and other certificate information.
[0026] Specifically, the template ID is the decimal integer obtained in step S102, the applicant's master public key is obtained in step S103, the master credential is obtained in step S104, and the DID certificate returned to the applicant includes the master credential, salted hash, template ID, basic certificate information, and certificate declaration information.
[0027] Step S106, Revoke the certificate: The issuing party calls the smart contract to store the public key and master credential of the certificate holder to be revoked into the revocation list of this certificate.
[0028] Step S201, Selective Presentation: Present the required fields, the salted hash of the remaining fields, the master credential, the certificate holder's public key, the template ID, the verification challenge, and the digital signature of the verification challenge to the verifier.
[0029] The verification challenge is the current timestamp, and the digital signature of the verification challenge is the result obtained by the certificate holder encrypting the SHA256 value of the current timestamp using their own private key.
[0030] In step S202, the verifier calculates the master hash using the plaintext field content and other information provided by the certificate holder.
[0031] Specifically, the master hash calculation process involves calculating the salted hash of the plaintext field presented according to step S104, and then combining the calculated salted hash with the salted hash (ciphertext) presented by the certificate holder according to step S104 to calculate the master hash.
[0032] In step S203, the verifier calls the smart contract to query whether the master certificate has been revoked and further queries the issuer's digital certificate, the basic fields in the certificate template, and the declaration fields.
[0033] Specifically, the verifier calls the TrustvrDID smart contract on the blockchain using the credential template ID obtained in step S201. If the main credential is revoked by the issuer, the verification process is terminated and a message indicating verification failure is returned.
[0034] Step S204, verify whether the identity of the issuing party and the presented credential information are tampered with.
[0035] Specifically, the verifier first uses the digital certificate of the issuing party obtained in step S203 to verify whether the real entity identity corresponding to the public key of the issuing party matches the identity of the issuing party in the credential template basic field according to the X509 certificate verification process. If they match, it indicates that the DID credential corresponding to this template ID is issued by the issuing party declared in the template basic field. Then use the public key of the issuing party to decrypt the main credential presented by the certificate holder in step S201, and compare the obtained result with the main hash obtained in step S202. If the comparison is passed (the values are equal), it indicates that the presented DID credential information has not been tampered with, and the DID credential is valid.
[0036] Step S205, verify whether the presenter of this time is the real holder of the DID credential.
[0037] Specifically, the verifier uses the public key of the certificate holder obtained in step S201 to decrypt the digital signature of the verification challenge, and compares the decrypted result with the verification challenge (timestamp or SHA256 value of timestamp). If the comparison is passed (the values are equal), it indicates that the certificate holder of this verification is the holder of the DID credential corresponding to this public key, that is, this DID credential belongs to the current credential presenter.
Claims
1. A method for issuing and presenting electronic certificates (DID certificates) based on blockchain distributed digital identity, characterized in that: The issuance method includes: the issuer creates a public-private key pair and a blockchain account using the corresponding blockchain algorithm (Secp256K1, ED25519, SM2, etc.), and then uses this public-private key pair to create a certificate request file (CSR) and attaches the real identity verification document of the issuer entity to submit to the authoritative certificate authority (CA). After receiving the digital certificate (X509 certificate) issued by the authoritative certificate authority, the issuing party uses the blockchain account corresponding to the private key of the digital certificate to call the smart contract on the blockchain to store information such as the digital certificate, the fields of the certificate template to be issued, and the issuing party's digital signature on the certificate template on the blockchain and obtain a DID certificate template ID. DID certificate applicants send the public key corresponding to their blockchain account and the necessary information for the certificate they are applying for to the issuing authority. After the issuing party reviews and approves the DID certificate applicant's information according to the process, it generates a corresponding salted hash using each necessary piece of information (certificate declaration information) of the DID certificate applicant. Then, it combines each salted hash and executes the hash algorithm again to obtain the certificate declaration master hash. Finally, it uses the private key to digitally sign the certificate declaration master hash to obtain the certificate master credential. The issuing party calls a smart contract on the blockchain to store the template ID of the DID certificate, the applicant's public key, and the master certificate on the blockchain, and returns the DID certificate containing basic information, declaration information, all salted hashes, master certificate, template ID, and other information to the applicant. To revoke a DID certificate of a certificate holder, the issuing party will use the public key and master credential of the certificate holder to call a smart contract on the blockchain to store the revocation list of this certificate.
2. A method for issuing and presenting electronic certificates (DID certificates) based on blockchain distributed digital identity, characterized in that: The presentation methods include: if the certificate holder selectively presents the name, the plaintext of the name is extracted from the certificate holder's DID certificate, and the salted hash (ciphertext) of the remaining fields is extracted, and then presented to the verifier along with the master certificate, the certificate holder's public key, the template ID, the verification challenge, and the digital signature of the verification challenge. The verifier uses the selectively presented plaintext field (name) to perform a salted hash operation to obtain the corresponding salted hash, and then uses this salted hash to combine with the salted hashes of the remaining fields and hashes again to obtain the certificate declaration master hash; The verifier uses the certificate template ID, the certificate holder's public key, and the master certificate to call the smart contract on the blockchain to query whether the master certificate has been revoked. If it has not been revoked, it can further query the corresponding issuer's digital certificate, the basic fields in the certificate template, and the declaration fields. The verifier first uses the issuer's digital certificate to verify, according to the X.509 certificate verification process, whether the real entity identity corresponding to the issuer's public key matches the issuer identity in the basic fields of the certificate template. Then, the verifier uses the issuer's public key to decrypt the master credential and compares the result with the master hash of the certificate declaration obtained earlier. If the comparison passes (the values are equal), it indicates that the presented DID certificate information has not been tampered with. If the issuer identity matches successfully, it indicates that the DID certificate was issued by the issuer declared in the basic fields of the template. The verifier uses the certificate holder's public key to decrypt the digital signature of the verification challenge, and compares the decrypted result with the verification challenge (timestamp or verification code) or the hash of the verification challenge. If the comparison passes (the values are equal), it indicates that the certificate holder of this verification is the holder of the DID certificate corresponding to this public key.
3. As described in claim 1, after the issuing party obtains a digital certificate (X509 certificate) issued by an authoritative certificate authority, it uses the blockchain account corresponding to the private key of the digital certificate to call the smart contract on the blockchain to store the digital certificate, the fields of the certificate template to be issued, the issuing party's digital signature on the certificate template, and other information on the blockchain to obtain a DID certificate template ID, characterized in that: The corresponding blockchain account creation method is to generate a corresponding public key using the private key corresponding to the digital certificate, and then use this public key to perform one or more hash algorithms to extract a partial fragment, or to encode it using BASE64 or BASE58 and extract a partial fragment to obtain the final blockchain account. The fields of the certificate template that need to be issued mainly include: certificate name, certificate description, basic information such as the issuing authority of the certificate, and declaration information such as the name of the certificate holder.
4. As described in claim 1, after the issuing party verifies the DID certificate applicant's information according to the procedure, a corresponding salted hash is generated using each necessary piece of information (certificate declaration information) of the DID certificate applicant, characterized in that... The method for generating the salted hash is to combine each necessary piece of information with the applicant's blockchain account, public key, or other digital identity and then execute a hash algorithm, or to execute a hash algorithm on each necessary piece of information and then combine it with the applicant's blockchain account, public key, or other digital identity and then execute a hash algorithm. The result obtained is the corresponding salted hash.
5. As described in claim 2, if the certificate holder selectively presents their name, the plaintext of the name is extracted from the certificate holder's DID certificate, and the remaining fields are extracted using salted hashes (ciphertext). Then, the name, along with the master credential, public key, template ID, verification challenge, and the digital signature of the verification challenge, is presented to the verifier, characterized in that... The digital signature of the verification challenge is to prevent replay attacks and ensure that the current DID certificate presenter is the true DID certificate holder. The verification challenge can be the current timestamp, a verification code specified by the verifier, or a verification code specified by the certificate holder.