WO2023160090A1

WO2023160090A1 - Proof generation method and apparatus, electronic device, and storage medium

Info

Publication number: WO2023160090A1
Application number: PCT/CN2022/135583
Authority: WO
Inventors: 林渝淇; 魏长征
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-02-25
Filing date: 2022-11-30
Publication date: 2023-08-31
Also published as: CN114785511A

Abstract

The present description provides a proof generation method and apparatus, an electronic device, and a storage medium. The method may comprise: obtaining private data of a prover, the private data being encrypted by means of an encryption algorithm based on the zero-knowledge proof technology to obtain ciphertext data, and the ciphertext data being recorded in a verifiable claim of the prover; and generating a corresponding proof according to the private data and a proof generation algorithm matched with the encryption algorithm, the proof being used for proving, under the verification of a proof verification algorithm matched with the proof generation algorithm, that the ciphertext data in the verifiable claim meets a verification passing condition.

Description

Proof generation method and device, electronic device, storage medium

This application claims the priority of the Chinese patent application with the application number 202210178102.7 and the title of the invention "proof generation method and device, electronic equipment, storage medium" submitted to the China Patent Office on February 25, 2022, the entire contents of which are incorporated by reference in this application.

technical field

One or more embodiments of this specification relate to the technical field of data processing, and in particular, to a method and device for generating a certificate, electronic equipment, and a storage medium.

Background technique

Out of consideration for privacy protection, users also hope that private data will not be leaked while using their own private data. Zero-Knowledge Proof (Zero-Knowledge Proof) or zero-knowledge protocol consists of two parts: the prover (prover) who declares that a certain proposition is true and the verifier (verifier) who confirms that the proposition is indeed true; among them, the prover can Provide the verifier with any useful information to convince the verifier that a certain assertion is correct.

A zero-knowledge proof is essentially an agreement involving two or more parties, that is, a series of steps that two or more parties need to take to complete a task. The prover proves to the verifier and makes him believe that he knows or has a certain message, but the proof process cannot leak any information about the proven message to the verifier, so as to avoid leaking the privacy of the prover.

Contents of the invention

In view of this, one or more embodiments of this specification provide a certificate generation method and device, electronic equipment, and a storage medium.

In order to achieve the above purpose, one or more embodiments of this specification provide technical solutions as follows:

According to a first aspect of one or more embodiments of the present specification, a proof generation method is proposed, including:

Obtain the private data of the prover, the private data is encrypted by an encryption algorithm based on zero-knowledge proof technology to obtain ciphertext data, and the ciphertext data is recorded in the verifiable statement of the prover;

Generate a corresponding certificate based on the privacy data and a certificate generation algorithm that matches the encryption algorithm, and the certificate is used to indicate the verifiable statement under the verification of a certificate verification algorithm that matches the certificate generation algorithm The ciphertext data in meets the verification criteria.

According to a second aspect of one or more embodiments of the present specification, a certificate generation device is proposed, including:

An acquisition unit, which acquires private data of the proving party, the private data is encrypted by an encryption algorithm based on zero-knowledge proof technology to obtain ciphertext data, and the ciphertext data is recorded in the verifiable statement of the proving party;

A generation unit, generating a corresponding certificate according to the privacy data and a certificate generation algorithm matching the encryption algorithm, and the certificate is used to indicate that the The ciphertext data in the verifiable statement meets the conditions for passing the verification.

According to a third aspect of one or more embodiments of the present specification, an electronic device is provided, including:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to the first aspect by running the executable instruction.

According to a fourth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

Description of drawings

Fig. 1 is a flow chart of a certificate generation method provided by an exemplary embodiment.

Fig. 2 is an interaction diagram for creating a DID provided by an exemplary embodiment.

Fig. 3 is an interaction diagram for generating verifiable claims and corresponding proofs provided by an exemplary embodiment.

Fig. 4 is an interaction diagram for verifying a prover provided by an exemplary embodiment.

Fig. 5 is a schematic structural diagram of a device provided by an exemplary embodiment.

Fig. 6 is a block diagram of a certificate generation device provided by an exemplary embodiment.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. Implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of one or more embodiments of the present specification as recited in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

In related technologies, identities can be created for each user through DIS (Decentralized Identifier Service, decentralized identity service). DIS can provide users with a DID (Decentralized Identifier, decentralized identity identifier) that is not restricted by any single registration center, identity service provider or authentication center, and is completely controlled by the user itself. DID can be used as the identification of an entity, and the specific information such as the authority, capability, behavior and even assets of the entity can be expressed through VC (Verifiable Claim, verifiable claim). VC is a descriptive statement issued by the issuer using its own distributed digital identity (DID) to endorse certain attributes of the user's DID, and is attached with the digital signature of the issuer. Then, the user can prove to other users that the attribute information about himself recorded in the VC is true and reliable by providing his own VC to other users.

It can be seen that the attribute information of the user holding the VC is recorded in the VC, and the attribute information is usually the user's private information, and there is a risk of exposing the private information when the user provides his/her own VC to other users. In this regard, this specification aims to provide a proof generation scheme that can protect the private information recorded in the verifiable statement held by users who adopt distributed digital identities, so that the private information is "available and invisible".

Please refer to FIG. 1 , which is a flow chart of a certificate generation method provided by an exemplary embodiment. As shown in Figure 1, the method may include the following steps:

Step 102, obtain private data of the prover, the private data is encrypted by an encryption algorithm based on zero-knowledge proof technology to obtain ciphertext data, and the ciphertext data is recorded in the verifiable statement of the prover.

In this embodiment, the certifier can request the issuer to issue a VC that records the real private information of the certifier, and the issuer can encrypt the private information recorded in the issued VC when issuing the corresponding VC to the certifier Processing, so as to realize the privacy protection of the prover. Among them, the zero-knowledge proof technology can be combined to ensure that the private information of the record holder in the VC is not leaked, and it can still be used to describe the private information (prove that the private information is true and valid), that is, the private information in the VC "Available and invisible".

Specifically, zero-knowledge proof technology includes encryption algorithms, proof generation algorithms, and proof verification algorithms. Among them, the encryption algorithm is used to encrypt the private data of the prover. Since the private data is in the form of ciphertext, a proof generation algorithm matching the encryption algorithm is required to generate a corresponding proof, which can indicate the private data of the prover. (in ciphertext form) meets the verification pass conditions set for the private data, and for the proof, it can be verified by a proof verification algorithm that matches the above proof generation algorithm to determine whether the content indicated by the proof is correct. In short, in the process of encrypting private data, generating certificates, and verifying certificates, the above three types of algorithms included in the zero-knowledge proof technology are in a corresponding relationship.

For example, user A's private data includes age information, and the verification pass condition set for age is "age at least 18 years old". Then, user A can provide his own age information to the issuer of VC (for example, trusted institutions such as civil affairs bureaus and public security organs), and the issuer will send the information to user A after verifying the authenticity of the age information and passing the verification. A corresponding VC is issued, and age information in ciphertext is recorded in the VC. After user A obtains VC, he can generate a certificate indicating "18 years of age" based on the age information in VC, and provide VC and certificate to the verifier (for example, a store with age restrictions for the products sold), so as to The verifier judges whether user A is over 18 years old based on VC and proof. Among them, user A, the issuer and the verifier pre-negotiate and determine the algorithms they use, that is, the certificate generation algorithm used by user A, the encryption algorithm used by the issuer, and the certificate verification algorithm used by the verifier match each other.

For the zero-knowledge proof technology, a commitment algorithm (Commitment) or a homomorphic encryption (Homomorphic Encryption) algorithm with homomorphic characteristics can be used. For the convenience of description, the homomorphic commitment/encryption algorithm is denoted by HE(), and the ciphertext form of plaintext t is HE(t). Homomorphic commitment/encryption is a special encryption method that allows processing the ciphertext to obtain an encrypted result, that is, directly processing the ciphertext is the same as processing the plaintext and then encrypting the processing result. Taking additive homomorphism as an example, HE(t1)+HE(t2)=HE(t1+t2). Homomorphic commitment algorithms include Pedersen commitment, etc. Homomorphic encryption algorithms include Paillier algorithm, Gentry algorithm, Okamoto–Uchiyama homomorphic encryption and Boneh-Goh-Nissim homomorphic encryption, etc.; of course, this manual does not describe the encryption algorithms used. Restrictions; for example, hashing algorithms may also be used. Correspondingly, range proof technology is a secure proof protocol in the field of cryptography, which can be used to prove that a number is within a certain reasonable range without disclosing the specific value of the number and other information. For example, zero-knowledge proof technologies such as Borromean ring signature scheme, Bulletproof scheme, and zkSNARK can be used for range proof.

Based on the above homomorphic characteristics, taking transfer as an example, for the purpose of transaction privacy protection, the transaction amount can be protected through homomorphic encryption or homomorphic commitment technology, and the range proof technology can be used to ensure that the transaction amount is non-negative and the account balance is sufficient Pay (by generating a range proof that shows that the transaction amount is non-negative and the account balance is sufficient to pay).

In this embodiment, when encrypting the plaintext private information of the prover, a random character string can be used as a mask to improve the randomness of the encrypted ciphertext data, thereby preventing the ciphertext data from being cracked by force. For example, the plaintext private information is age, and the encryption algorithm used is hash operation. Since the numerical range of age is small, if the age is directly hashed, the total amount of generated ciphertext data will be relatively small, so easy It was cracked violently, thus revealing the user's age privacy. Therefore, a random string can be generated (generated by the prover and provided to the issuer, or generated by the issuer), and the random string can be concatenated with plaintext private information to obtain private data, and then the private data can be encrypted to obtain ciphertext data. In other words, the private data in this embodiment includes plaintext private information and random character strings of the prover.

Furthermore, before issuing the VC to the prover, the issuer can verify the authenticity of the plaintext private information provided by the prover, so as to generate an original verifiable statement if the authenticity check passes. In the original verifiable statement Contains plaintext privacy information, random strings, and ciphertext data. Then, the prover can obtain the original verifiable statement generated by the issuer after verifying the plaintext private information, and delete the plaintext private information and random strings in the original verifiable statement to obtain a verifiable statement. The verifiable statement is It is a verifiable statement that can be provided to the verifier for verification later. It should be noted that this specification does not limit the specific manner of the above-mentioned authenticity verification operation.

In the process of generating the original verifiable statement by the issuer, the issuer can distinguish the first statement content (including the statement issuer, statement receiver, statement expiration time, Statement issuance time, etc., will be described in detail below) to sign to obtain the first signature, and record the first signature in the original verifiable statement. In other words, the original verifiable statement contains the issuer's first signature on the content of the first statement in the original verifiable statement, and the issuer endorses the certifier through the first signature. Based on the fact that the original verifiable statement contains the issuer's first signature, the verifier determines that the prerequisites for the prover to pass the verification include passing the verification of the certificate corresponding to the verifiable statement and passing the verification of the first signature.

In addition, the issuer can sign the content of the second statement in the original verifiable statement (including at least plaintext private information and random strings) to obtain the second signature, and record the second signature in the original verifiable statement, That is, the original verifiable statement includes the issuer's second signature on the content of the second statement in the original verifiable statement. Then, after obtaining the original verifiable statement, the prover can perform signature verification on the second signature contained in the original verifiable statement, so that if the second signature verification passes (indicating that the original verifiable statement was generated by the issuer and has not been tampered with) to generate the above verifiable claim.

Step 104: Generate a corresponding certificate according to the private data and a certificate generation algorithm that matches the encryption algorithm, and the certificate is used to indicate that the The ciphertext data in the verifiable statement meets the conditions for passing the verification.

In this embodiment, after the proving party obtains the verifiable statement, it can generate a certificate corresponding to the verifiable statement, which is used to show that the ciphertext data recorded in the verifiable statement meets the verification pass condition (can be set by the verifier or provide). Specifically, the prover can input the private data, the verification pass condition, and the judgment result indicating that the private data meets the verification pass condition into the proof generation algorithm to generate the above proof.

Continuing from the above example, user A's age is 25 years old, and the verification qualification set by the verification party for age is "age over 18 years old". Since 25 years old > 18 years old, the judgment result is "Yes", that is, the judgment result is the user A's age meets the verification pass condition "age at least 18 years old". Therefore, the prover can input "user A's age is 25 years old", "age is over 18 years old" and the judgment result is "yes" into the proof generation algorithm to generate a proof corresponding to the verifiable statement.

Among them, there may be multiple sets of encryption algorithms based on zero-knowledge proof technology and corresponding proof generation algorithms and proof verification algorithms, that is, each set of algorithms includes mutually matching encryption algorithms, proof generation algorithms, and proof verification algorithms. Alternatively, the issuer, prover, and verifier did not pre-negotiate which algorithm based on zero-knowledge proof technology. In view of the above situation, during the process of generating the original verifiable statement, the issuer records in the original verifiable statement the algorithm identification of the proof generation algorithm and the proof verification algorithm that match the encryption algorithm adopted by itself, so as to instruct the corresponding user to adopt The algorithm corresponding to the algorithm ID. Specifically, the verifiable statement includes the first algorithm identification of the proof generation algorithm, and the first algorithm identification is used to instruct the prover to determine the corresponding proof generation algorithm according to the first algorithm identification; and/or, the verifiable statement includes the proof verification algorithm The second algorithm identifier, the second algorithm identifier is used to instruct the verifier to determine the proof verification algorithm according to the second algorithm identifier.

For ease of understanding, the technical solution of this specification will be described in detail below with reference to the accompanying drawings 2-4.

Fig. 2 is an interaction diagram for creating a DID provided by an exemplary embodiment. As shown in Figure 2, the interaction process may include the following steps:

In step 202, the prover creates a DID, a key pair corresponding to the DID and a corresponding DID document.

In this embodiment, the user as the certifier can log in his own user account on the used client, so that the client can be used as the certifier. Among them, DIS (Decentralized Identifier Service, decentralized identity service) can be used to create identities for each user. DIS can provide users with an identity that is not restricted by any single registration center, identity service provider or authentication center, and is completely controlled by the user. DID (Decentralized Identifier, decentralized identity identifier). Take the DID created by the prover as an example. The key pair corresponding to the DID of the prover includes a public key and a private key. The public key needs to be published to the blockchain for deposit, while the private key corresponding to the DID of the prover is kept by the prover. , such as being saved locally on the above-mentioned client.

In the DIS system, a DID (Decentralized Identifier, decentralized identity identifier) corresponds to an entity (for example, VC issuer, certifier, verifier and other users), and for the specific use of the DID, it is up to and The DID document (DID Document) description corresponding to the DID. The DID document is used to describe how to use the corresponding DID, at least including the public key of the corresponding DID; in addition, information such as encryption method, proof purpose, verification method and server can also be recorded. Among them, the proof purpose is combined with the verification method to provide a mechanism for proving things. For example, a DID document can specify a specific authentication method, such as a cryptographic public key or a pseudonymous biometric protocol, that can be used to authenticate methods created for the purpose. Service endpoints support trusted interactions with DID controllers. DID and DID documents can be directly registered on the blockchain or other distributed networks without applying to a centralized registration agency. By utilizing the non-tamperable, hash encryption and other characteristics of distributed network technologies such as blockchain, it is possible to realize the Digital identities are truly owned and controlled by users, and there is no longer any middleman (even DID technology providers) who owns and controls users' identities and data.

Step 204, the prover creates a transaction for depositing the DID and the DID document.

Step 206, the prover submits the transaction for depositing the DID and the DID document to the blockchain network.

Step 208, the blockchain network deposits the DID and the DID document on the blockchain.

Step 210, the prover obtains the receipt of the successful creation of the DID from the blockchain network.

In this embodiment, after depositing the certificate DID and the DID document, the blockchain network can generate an event for recording the success of the certificate DID and the DID document, and store it in the blockchain log. Then, the prover can obtain the event through the callback mechanism of the blockchain, so as to determine that the DID and the DID document have been stored on the blockchain, that is, the prover succeeds in creating the DID. Alternatively, a corresponding prompt message can also be generated for the prover to view, so as to inform the prover that the DID is successfully created on the chain.

Fig. 3 is an interaction diagram for generating verifiable claims and corresponding proofs provided by an exemplary embodiment. As shown in Figure 3, the interaction process may include the following steps:

In step 302, the certifier creates a statement issuance request (including the certifier DID, plaintext private information and identity information of the certifier).

Step 304, the certification sends a claim issuance request to the issuer.

In step 306, the issuer reads the certifier DID included in the statement issuance request.

Step 308, the issuer initiates a query transaction for the DID of the prover to the blockchain network.

In step 310, the blockchain network queries the DID document corresponding to the DID of the prover in response to the query transaction.

Step 312, the blockchain network returns the queried DID document to the issuer.

Step 314, the issuer sends a DID authentication challenge message (including challenge data) to the prover.

In this embodiment, it can be known from the process of creating a DID in Figure 2 above that the public key corresponding to the DID of the certifier is recorded in the DID file of the certifier DID, so the public key can be used to verify the certifier DID in the statement issuance request Whether it is the DID actually held by the certifier, that is, to verify whether the certifier is the legal owner of the certifier DID in the statement issuance request.

The issuer can randomly generate a challenge data (for example, a character string), and send the challenge data to the certifier through a DID authentication challenge message (DID auth challenge) to instruct the certifier to pass its own private key (that is, the same as the certifier DID corresponding private key) to sign it, and return the challenge data and signature. Then, the issuer can use the public key in the DID document to perform signature verification on the signature, and then confirm that the certifier is the legal owner of the certifier DID recorded in the statement issuance request if the signature verification is passed.

Step 316, the prover signs the challenge data through the private key corresponding to the prover DID.

Step 318, the prover returns challenge data to the issuer.

Step 320, the issuer uses the public key in the DID document to perform signature verification.

In this embodiment, in addition to the above method of sending a DID authentication challenge message, a method of adding a signature to the statement issuing request may also be used. Specifically, the certifier adds a signature for the content of the statement issuance request to the created statement issuance request, and the issuer can use the public key recorded in the DID document to sign the signature in the statement issuance request after obtaining the DID document Verification to confirm that the prover is the legal owner of the prover DID recorded in the claim issuance request.

In step 322, the issuer verifies the authenticity of the plaintext private information if the signature verification is passed.

In this embodiment, when creating a statement issuance request, the identity information of the certifier may be recorded in the statement issuance request as a basis for the issuer to verify the authenticity of the plaintext private information. Then, after the verification of the DID of the prover is completed, the authenticity of the plaintext private information can be further verified according to the identity information of the prover recorded in the statement issuance request. For example, the identity information of the certifier may include the certifier's ID number, place of origin, date of birth, household registration information, etc., then the issuing party (such as the Civil Affairs Bureau or public security organ) can verify the authenticity of the certifier's age based on the above identity information. check.

In step 324, if the verification is passed, the issuer uses an encryption algorithm to encrypt the plaintext private information and random character strings to obtain ciphertext data, and generates an original verifiable statement for the ciphertext data.

In this embodiment, DID is an identifier of an entity, and specific information such as rights, capabilities, behaviors, and assets owned by the entity is expressed through VC. It should be noted that a DID can have one or more VCs. For example, the following fields can be included in VC:

issuer: statement issuer (issuer);

didsubject: declare the DID of the recipient (issuing object);

expire: declare expiration time;

issuance date: the date when the statement was issued;

claim: claim content;

proof: proof of validity (different from the proof generated by the above-mentioned prover).

The issuer can generate a random string, and then splice it with the plaintext private information, and then use an encryption algorithm to encrypt the spliced string to obtain ciphertext data. Among them, the issuer can record its own DID (that is, the issuer DID) in the issuer, record the DID of the certifying party in the didsubject, record the expiration time of the statement in expire, record the time when the VC is issued in the issuance date, and record the plaintext in the claim Private information, random strings, and ciphertext data. Specifically, the claim field can be extended to further include plaintext, random, and commitment. Plaintext is used to record plaintext private information, such as age; random is used to record random strings, and commitment is used to record ciphertext data.

In order to prove that the VC is issued by the issuer, on the one hand, the issuer can use its own private key to declare other content in the VC except plaintext privacy information and random strings (that is, the first statement content, including ciphertext data) to obtain the first signature, and record the first signature in the proof, for example, in the zkpsignaturevalue field of the proof; on the other hand, the issuer can use its own private key pair to at least include plaintext privacy information and random strings The content of the statement (that is, the content of the second statement) is signed to obtain the second signature, and the second signature is recorded in the proof, for example, in the signaturevalue field of the proof.

For example, the original verifiable claim reads:

In addition, there may be multiple sets of encryption algorithms based on zero-knowledge proof technology and corresponding proof generation algorithms and proof verification algorithms, that is, each set of algorithms includes matching encryption algorithms, proof generation algorithms, and proof verification algorithms. Alternatively, the issuer, prover, and verifier did not pre-negotiate which algorithm based on zero-knowledge proof technology. In view of the above situation, in the process of generating the original verifiable statement, the issuer can record in the original verifiable statement the algorithm identification of the proof generation algorithm and the proof verification algorithm that match the encryption algorithm adopted by itself, so as to indicate that the corresponding user The algorithm corresponding to the algorithm ID is adopted. Of course, if the issuer, the certifier and the verifier pre-negotiate which algorithm based on the zero-knowledge proof technology to use, there is no need to record the above-mentioned algorithm identification.

It should be noted that the above description of the fields included in the VC is only an example, and can be flexibly adjusted according to actual conditions in actual applications.

Step 326, the issuer returns the original verifiable statement to the prover.

In this embodiment, after obtaining the original verifiable statement, the prover can perform signature verification on the first signature and the second signature respectively, so that subsequent steps can be performed when both signature verifications pass.

In step 328, the prover obtains plaintext private information and random character strings.

In one case, the random string is claimed by the issuer, then the prover can read the random string recorded in the original verifiable claim. In another case, the random string is generated by the prover and provided to the issuer (such as through a claim issuance request), then the prover can first read the random string recorded in the original verifiable claim, and then compare it with the self-generated Random strings are compared to perform subsequent steps if the comparison is consistent.

In step 330, the prover obtains the verification passing conditions and judgment results.

In step 332, the prover inputs the plaintext private information, random character strings, verification passing conditions and judgment results into the proof generation algorithm to generate a proof.

For example, the age of user A (private information in plain text) is 25 years old, the random string is h@$fwehdu, and the age-based verification pass condition set by the verification party is "18 years of age". Since 25 years old > 18 years old , the judgment result is "Yes", that is, the judgment result is that the age of user A meets the verification passing condition "age over 18 years old". Therefore, the prover can first concatenate the plaintext private information "user A's age is 25" and the random string "h@$fwehdu", and then combine the concatenated string, the verification passing condition "age over 18" and judge The result "yes" is input to the proof generation algorithm to generate a proof corresponding to the verifiable claim.

In step 334, the prover deletes the plaintext private information and random strings in the original verifiable statement to obtain the final verifiable statement.

In this embodiment, in order to ensure that the private information of the record holder in the VC is not leaked, it can still be used to describe the private information (to prove that the private information is true and valid), the obtained from the issuer can be The plaintext field and the random field in the VC are deleted (the second signature can also be deleted), so as to obtain the final usable VC.

Following the above example, the final verifiable statement is as follows:

Fig. 4 is an interaction diagram for verifying a prover provided by an exemplary embodiment. As shown in Figure 4, the interaction process may include the following steps:

Step 402, the prover creates a verification request (including the prover DID).

Step 404, the prover sends a verification request to the verifier.

In step 406, the verifier verifies the DID of the prover.

Since the prover expresses its own identity through DID, the prover needs to provide the prover DID to the verifier, so that the verifier can verify the prover DID, that is, verify that the prover is the legal owner of the provided prover DID. For the process of verifying the DID of the prover, reference may be made to steps 308-320 in FIG. 3 above, which will not be repeated here.

Step 408, the prover sends the verifiable statement and corresponding proof to the verifier.

In this embodiment, the prover needs to prove to the verifier that its private information meets the verification pass conditions set by the verifier, then it needs to provide the verifier with the VC obtained in the embodiment shown in Figure 3 above and the corresponding certificate.

Step 410, the verifier verifies the verifiable claim.

In this embodiment, the verifier can use the issuer's public key to perform signature verification on the first signature in the verifiable statement, thereby verifying the data integrity of the verifiable statement (whether it has been tampered with) and whether it is issued by the issuer. Among them, since the issuer DID is recorded in the issuer field of the verifiable statement, the public key of the issuer can be queried from the blockchain network according to the issuer DID. The specific process is similar to the above steps 306-312 and will not be repeated here.

Step 412, the verifier verifies the certificate.

In this embodiment, the verifier can verify the ciphertext data in the verifiable statement through the proof verification algorithm and the proof, and determine whether the ciphertext data meets the verification passing condition. Wherein, in the case that the certificate verification and the first signature verification pass, it may be determined that the prover has passed the verification.

Step 414, the verifier determines that the prover passes the verification, and executes relevant business operations for the prover.

Step 416, the verifier returns the execution result of the business operation to the prover.

Take the Internet cafe to verify whether user A is over 18 years old as an example. After determining that user A has passed the verification, the Internet cafe verifier can generate a payment order for user A and return the payment order information to user A's client.

Corresponding to the foregoing method embodiments, this specification also provides an embodiment of a certificate generation device.

Fig. 5 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 5 , at the hardware level, the device includes a processor 502 , an internal bus 504 , a network interface 506 , a memory 508 and a non-volatile memory 510 , and of course it may also include hardware required by other services. The processor 502 reads the corresponding computer program from the non-volatile memory 510 into the memory 508 and then runs it, forming a certificate generation device on a logical level. Of course, in addition to software implementations, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.

Please refer to FIG. 6, in a software implementation, the certificate generation device may include:

The acquiring unit 61 is configured to acquire private data of the prover, the private data is encrypted by an encryption algorithm based on zero-knowledge proof technology to obtain ciphertext data, and the ciphertext data is recorded in the verifiable statement of the prover;

The generation unit 62 generates a corresponding certificate according to the private data and the certificate generation algorithm matching the encryption algorithm, and the certificate is used to indicate that the The ciphertext data in the above verifiable statement meets the conditions for passing the verification.

Optionally, the generating unit 62 is specifically used for:

Inputting the private data, the verification passing condition, and a judgment result indicating that the private data meets the verification passing condition into the proof generating algorithm to generate the proof.

optional,

The verifiable statement includes a first algorithm identification of the proof generation algorithm, and the first algorithm identification is used to instruct the prover to determine the proof generation algorithm according to the first algorithm identification;

And/or, the verifiable statement includes a second algorithm identification of the proof verification algorithm, and the second algorithm identification is used to instruct the verifier to determine the proof verification algorithm according to the second algorithm identification.

Optionally, the privacy data includes plaintext privacy information and random character strings of the prover.

Optionally, the acquisition unit 61 is also used for:

Obtaining an original verifiable statement generated by the issuer after verifying that the plaintext privacy information passes, the original verifiable statement includes the plaintext privacy information, the random character string and the ciphertext data;

The plaintext private information and random character strings in the original verifiable statement are deleted to obtain the verifiable statement.

Optionally, the original verifiable statement includes the issuer's first signature on the content of the first statement in the original verifiable statement, and the content of the first statement is different from the plaintext privacy information and the random string ; Wherein, the verifier determines that the preconditions for the verification of the certifying party include passing the verification of the certificate and passing the verification of the first signature.

Optionally, the original verifiable statement includes a second signature of the issuer on the content of the second statement in the original verifiable statement, and the content of the second statement includes at least the plaintext privacy information and the random string ; The device also includes:

The verification unit 63 is configured to verify the second signature, so as to generate the verifiable statement when the verification of the second signature passes.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

Terms used in one or more embodiments of the present specification are for the purpose of describing specific embodiments only, and are not intended to limit the one or more embodiments of the present specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a", "the", and "the" are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of the present specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. should be included in the scope of protection of one or more embodiments of this specification.

Claims

A proof generation method comprising:

Obtain the private data of the prover, the private data is encrypted by an encryption algorithm based on zero-knowledge proof technology to obtain ciphertext data, and the ciphertext data is recorded in the verifiable statement of the prover;

Generate a corresponding certificate based on the privacy data and a certificate generation algorithm that matches the encryption algorithm, and the certificate is used to indicate the verifiable statement under the verification of a certificate verification algorithm that matches the certificate generation algorithm The ciphertext data in meets the verification criteria.
The method according to claim 1, said generating a corresponding certificate according to said private data and a certificate generating algorithm matching said encryption algorithm, comprising:

Inputting the private data, the verification passing condition, and a judgment result indicating that the private data meets the verification passing condition into the proof generating algorithm to generate the proof.
The method according to claim 1,

The verifiable statement includes a first algorithm identification of the proof generation algorithm, and the first algorithm identification is used to instruct the prover to determine the proof generation algorithm according to the first algorithm identification;

And/or, the verifiable statement includes a second algorithm identification of the proof verification algorithm, and the second algorithm identification is used to instruct the verifier to determine the proof verification algorithm according to the second algorithm identification.
According to the method according to claim 1, the private data includes plaintext private information and random character strings of the prover.
The method according to claim 4, further comprising:

Obtaining an original verifiable statement generated by the issuer after verifying that the plaintext privacy information passes, the original verifiable statement includes the plaintext privacy information, the random character string and the ciphertext data;

The plaintext private information and random character strings in the original verifiable statement are deleted to obtain the verifiable statement.
The method according to claim 5, wherein the original verifiable statement includes the first signature of the issuer on the content of the first statement in the original verifiable statement, and the content of the first statement is different from the plaintext private information and The random character string; wherein the preconditions for the verifier to determine that the certifier passes the verification include passing the verification of the certificate and passing the verification of the first signature.
The method according to claim 5, wherein the original verifiable statement includes a second signature of the issuing party on the second statement content in the original verifiable statement, and the second statement content includes at least the plaintext private information and The random string; the method also includes:

Verifying the second signature, so as to generate the verifiable statement if the verification of the second signature is passed.
A proof generating device, comprising:

An acquisition unit, which acquires private data of the proving party, the private data is encrypted by an encryption algorithm based on zero-knowledge proof technology to obtain ciphertext data, and the ciphertext data is recorded in the verifiable statement of the proving party;

A generation unit, generating a corresponding certificate according to the privacy data and a certificate generation algorithm matching the encryption algorithm, and the certificate is used to indicate that the The ciphertext data in the verifiable statement meets the conditions for passing the verification.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to any one of claims 1-7 by running the executable instruction.
A computer-readable storage medium, on which computer instructions are stored, and the steps of the method according to any one of claims 1-7 are implemented when the instructions are executed by a processor.