CN114389810B - Method and device for generating certification, electronic equipment and storage medium - Google Patents

Method and device for generating certification, electronic equipment and storage medium Download PDF

Info

Publication number
CN114389810B
CN114389810B CN202210179222.9A CN202210179222A CN114389810B CN 114389810 B CN114389810 B CN 114389810B CN 202210179222 A CN202210179222 A CN 202210179222A CN 114389810 B CN114389810 B CN 114389810B
Authority
CN
China
Prior art keywords
proof
party
proving
condition
verifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210179222.9A
Other languages
Chinese (zh)
Other versions
CN114389810A (en
Inventor
林渝淇
魏长征
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ant Blockchain Technology Shanghai Co Ltd
Original Assignee
Ant Blockchain Technology Shanghai Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ant Blockchain Technology Shanghai Co Ltd filed Critical Ant Blockchain Technology Shanghai Co Ltd
Priority to CN202210179222.9A priority Critical patent/CN114389810B/en
Publication of CN114389810A publication Critical patent/CN114389810A/en
Priority to PCT/CN2022/135645 priority patent/WO2023160097A1/en
Application granted granted Critical
Publication of CN114389810B publication Critical patent/CN114389810B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H04L9/3221—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

The specification provides a proof generating method, comprising: acquiring privacy data and judgment conditions of a proving party, wherein the declaration of the proving party comprises ciphertext data obtained by encrypting the privacy data; generating a first proof when a first proof generating condition is satisfied, wherein the first proof generating condition comprises that a first proof generating request for the statement initiated by the proving party is received, and the relation between the privacy data and the judging condition is verified to be matched with a first judging result provided by the proving party, and the first proof is used for indicating that the relation between the ciphertext data and the judging condition is matched with the first judging result; and generating a second certificate under the condition that a second certificate generation request for the statement initiated by the verifier is received, wherein the second certificate is used for indicating that the relation between the ciphertext data and the judgment condition is matched with a second judgment result provided by the verifier.

Description

Method and device for generating certification, electronic equipment and storage medium
Technical Field
One or more embodiments of the present disclosure relate to the field of data processing technologies, and in particular, to a method and apparatus for generating a certificate, an electronic device, and a storage medium.
Background
For privacy protection, it is also desirable that the user not only uses his own private data, but also does not compromise the private data. Zero-Knowledge Proof (Zero-knowledgeproof) or Zero-Knowledge protocol includes two parts: a prover (provider) claiming a proposition as true and a verifier (verifier) confirming that the proposition is indeed true; wherein the prover is able to let the verifier believe that a certain assertion is correct without providing any useful information to the verifier.
Zero knowledge proof is essentially a protocol involving two or more parties, i.e., a series of steps that two or more parties need to take to complete a task. The prover proves to the verifier and believes itself to know or own a certain message, but the proving process cannot reveal any information about the proved message to the verifier, thus avoiding revealing the prover's privacy.
Disclosure of Invention
In view of this, one or more embodiments of the present disclosure provide a method and apparatus for generating a certificate, an electronic device, and a storage medium.
In order to achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:
According to a first aspect of one or more embodiments of the present specification, there is provided a proof generating method, comprising:
Acquiring private data of a proving party and judging conditions aiming at the private data, wherein declarations of the proving party comprise ciphertext data obtained by encrypting the private data;
generating a first proof under the condition that a first proof generating condition is met, wherein the first proof generating condition comprises that a first proof generating request which is initiated by the proving party and aims at the statement is received, and the relation between the privacy data and the judging condition is verified to be matched with a first judging result provided by the proving party, and the first proof is used for indicating that the relation between the ciphertext data and the judging condition is matched with the first judging result to a verifying party under the verification of a zero knowledge proving algorithm;
And generating a second proof under the condition that a second proof generating condition is met, wherein the second proof generating condition comprises the receiving of a second proof generating request for the statement initiated by the verifier, and the second proof is used for indicating that the relation between the ciphertext data and the judging condition is matched with a second judging result provided by the verifier under the verification of a zero knowledge proof algorithm.
According to a second aspect of one or more embodiments of the present specification, there is provided a proof generating apparatus comprising:
an acquisition unit that acquires private data of a proving party and a judgment condition for the private data, wherein a declaration of the proving party contains ciphertext data obtained by encrypting the private data;
A first generation unit configured to generate a first proof when a first proof generation condition is satisfied, the first proof generation condition including receiving a first proof generation request for the declaration initiated by the proving party, and verifying that a relationship between the privacy data and the judgment condition matches a first judgment result provided by the proving party, the first proof being for indicating to the verifying party that the relationship between the ciphertext data and the judgment condition matches the first judgment result under verification of a zero knowledge proof algorithm;
And the second generation unit is used for generating a second certificate under the condition that a second certificate generation condition is met, wherein the second certificate generation condition comprises a second certificate generation request for the statement initiated by the verifier, and the second certificate is used for indicating that the relation between the ciphertext data and the judgment condition is matched with a second judgment result provided by the verifier under the verification of a zero-knowledge proof algorithm.
According to a third aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:
A processor;
A memory for storing processor-executable instructions;
wherein the processor implements the method of the first aspect by executing the executable instructions.
According to a fourth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method as described in the first aspect.
Drawings
Fig. 1 is a flow chart of a method of generating a proof provided in 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 issuing a verifiable claim provided by an example embodiment.
Fig. 4 is a flow chart of another method of credential generation provided by an exemplary embodiment.
Fig. 5 is an interaction diagram of a proof of verification party provided by an example embodiment.
Fig. 6 is a schematic diagram of an apparatus according to an exemplary embodiment.
Fig. 7 is a block diagram of a proof generating apparatus provided by an exemplary embodiment.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.
It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.
Referring to fig. 1, fig. 1 is a flowchart of a method for generating a proof according to an exemplary embodiment. As shown in fig. 1, the method applied to the proof generating platform may include the following steps:
Step 102, obtaining privacy data of a proving party and judging conditions aiming at the privacy data, wherein the declaration of the proving party comprises ciphertext data obtained by encrypting the privacy data.
In this embodiment, the user can log in his own user account as a prover on the client used, so that the client acts as a prover, and the concepts of the verifier and issuer are similar. The prover may request the issuer to issue a statement that records the prover's authentic private information, the issuer first performing an authenticity check on the private information, whereby the prover is issued the statement after the authenticity check passes. In other words, the issuer is used as a trusted platform to endorse the proving party, and the issuing statement is used for indicating that the privacy information of the proving party is true and reliable. Taking VC (Verifiable Claim, verifiable statement) as an example, identities may be created for individual users through DIS (Decentralized IDENTIFIER SERVICE, a de-centralized identity service). The DIS may provide the user with a DID (Decentralized Identifier, off-center avatar identifier) that is not limited by any single registry, identity server, or authentication center, but is fully controlled by the user itself. The DID may be an identity of an entity, and specific information about which rights, capabilities, behaviors, and even assets the entity possesses may be represented by VC. VC is a descriptive statement issued by an issuer endorsing certain attributes of the user's distributed Digital Identity (DID) using its own DID, with the issuer's digital signature appended. Then, the user can prove to other users that the attribute information about itself recorded in the VC is authentic by providing the other users with their own VCs.
The attribute information of the user holding the statement is recorded in the statement, and the attribute information is usually the privacy information of the user, and if the privacy information recorded in the statement is in a plaintext form, the user risks exposing the privacy information when providing the statement of the user to other users. Thus, the privacy information recorded in the claims held by the user employing the distributed digital identity can be protected, making the privacy information "invisible" available.
Specifically, the proving party can request the issuing party to issue the statement that the real privacy information of the proving party is recorded, and when the corresponding statement is issued to the proving party, the issuing party can encrypt the privacy information recorded in the issued statement, so that the privacy protection of the proving party is realized. Meanwhile, on the premise that the privacy information of the record holder in the statement is not revealed, the method can be used for describing the privacy information (proving that the privacy information is truly effective) by combining a zero knowledge proof technology, namely, the privacy information in the statement is made to be 'available and invisible'.
The zero knowledge proof technology comprises an encryption algorithm, a proof generation algorithm and a proof verification algorithm. The encryption algorithm is used for encrypting the private data of the proving party, and because the private data is in a ciphertext form, a proving generation algorithm matched with the encryption algorithm is needed to generate a corresponding proving, the proving can indicate that the private data (in the ciphertext form) of the proving party accords with a judging condition set for the private data (can be understood as a verification passing condition for judging whether the private data passes verification or not), and for the proving, the proving can be verified by a proving verification algorithm matched with the proving generation algorithm, and whether the proving indicated content is correct or not is determined. In short, in the processes of encrypting the privacy data, generating the proof and verifying the proof, the three algorithms included in the zero knowledge proof technology are in a corresponding relation.
For example, the privacy data of the user a includes age information, and the determination condition set for the age is "age over 18 years". Then, the user a may provide the age information of the user a to an issuer of the statement (for example, a trusted authority such as a civil government office, a public security authority, etc.), and after the issuer performs authenticity verification on the age information and passes the verification, the issuer issues a corresponding statement to the user a, where the age information in the form of ciphertext is recorded. After obtaining the statement, user a may generate a proof for the age information in the statement indicating "18 years old" and provide the statement and proof to a verifier (e.g., a store with age restrictions on the goods sold) to determine whether user a is 18 years old based on the statement and proof by the verifier. Wherein, the user A, the issuer and the verifier negotiate in advance to determine the respective algorithms used, namely the authentication generation algorithm used by the user A, the encryption algorithm used by the issuer and the authentication verification algorithm used by the verifier are matched with each other.
For the zero knowledge proof technology, a promise algorithm (Commitment) with homomorphism characteristics or a homomorphism encryption (Homomorphic Encryption) algorithm can be adopted. For convenience of description, the homomorphic commitment/encryption algorithm is denoted by the symbol HE (), and for plaintext t, its ciphertext form is HE (t). Homomorphic promise/encryption is a special encryption method, which allows ciphertext to be processed to obtain a result which is still encrypted, namely, the ciphertext is directly processed, and the result is the same as the result obtained by encrypting the processing result after plaintext is processed. Taking the addition homomorphism as an example, HE (t 1) +he (t 2) =he (t1+t2). Homomorphic promise algorithms include Pedersen promise and the like, homomorphic encryption algorithms include Paillier algorithm, gentry algorithm, okamoto-Uchiyama homomorphic encryption, boneh-Goh-Nissim homomorphic encryption and the like; of course, the present description does not limit the encryption algorithm employed; for example, a hash algorithm may also be employed. Accordingly, the scope proving technology is a secure proving protocol in the field of cryptography, and can be used for proving that a number is in a certain reasonable interval and does not reveal information such as a specific numerical value of the number. For example, borromean ring signature schemes, bulletproof schemes, zkSNARK, and other zero knowledge proof techniques may be used for scope proofing.
Based on the homomorphic features, taking account transfer as an example, for the purpose of transaction privacy protection, the transaction amount can be protected by homomorphic encryption or homomorphic promise technology, and the transaction amount is ensured to be non-negative and the account balance is sufficiently paid by using range proving technology (by generating range proving for indicating that the transaction amount is non-negative and the account balance is sufficiently paid).
In this embodiment, the attestation generation platform may issue a statement containing ciphertext data to the attestation party as the issuer described above. Also taking VC as an example, the prover uses DID to indicate its identity and instructs the prover generation platform to issue VC by initiating a claim issuance request to the prover generation platform, the claim issuance request containing the prover DID. After receiving the claim issuing request, the proving generation platform verifies the DID of the proving party, and inquires a public key corresponding to the DID contained in the claim issuing request from the blockchain network; a challenge message is then sent to the proving party, the challenge message being used to instruct the proving party to sign challenge data contained in the challenge message using a private key of the proving party. After obtaining challenge data returned by the proving party, the proving generation platform performs signature verification (signature verification) on the challenge data by using a public key queried from the blockchain network, so that under the condition that the signature verification passes, the proving party DID is judged to be the DID held by the proving party, and further a verifiable statement containing ciphertext data and a centralized identifier of the proving party DID is generated, and by recording the proving party DID in the verifiable statement, the proving party DID can indicate that the receiving party of the verifiable statement is the proving party.
The verification generation platform can carry out authenticity verification on the private data of the verification party before generating the verifiable statement, so that the private data is encrypted to obtain ciphertext data under the condition that verification is passed, and the verifiable statement is generated. By verifying the authenticity of the prover's private data, the generated verifiable statement can be ensured to be authentic and reliable.
In this embodiment, when encrypting the plaintext privacy information of the proving party, the randomness of the ciphertext data obtained by encryption can be improved by using the random character string as a mask, thereby preventing the ciphertext data from being hacked. For example, the plaintext privacy information is age, and the adopted encryption algorithm is hash operation, because the numerical range of the age is smaller, if the hash operation is directly carried out on the age, the total amount of generated ciphertext data is correspondingly smaller, and the ciphertext data is easy to be violently cracked, so that the age privacy of the user is revealed. Therefore, a random character string can be generated (generated by the proving party and provided to the proving generation platform or generated by the proving generation platform), the random character string and the plaintext privacy information are spliced to obtain the privacy data, and then the privacy data is encrypted to obtain the ciphertext data. In other words, the privacy data in the present embodiment contains plaintext privacy information of the proving party and a random character string.
Further, the certification generation platform can perform authenticity verification on the plaintext privacy information provided by the certifier before issuing the VC to the certifier, so that an original verifiable statement is generated under the condition that the authenticity verification is passed, and the original verifiable statement contains the plaintext privacy information, the random character string and the ciphertext data. Then, the proving party can acquire the original verifiable statement generated by the proving generation platform under the condition that the verified plaintext privacy information passes, and delete the plaintext privacy information and the random character string in the original verifiable statement to obtain the verifiable statement, wherein the verifiable statement is the verifiable statement which can be subsequently provided to the verifying party for verification. It should be noted that the present specification does not limit the specific manner of the above-described authenticity verification operation.
Wherein, the encryption algorithm based on the zero knowledge proof technology and the corresponding proof generating algorithm and proof verifying algorithm can have a plurality of groups, namely, each group of algorithms comprises the encryption algorithm, the proof generating algorithm and the proof verifying algorithm which are matched with each other. Or the proof generating platform, the proving party and the verifying party do not negotiate in advance what algorithm based on the zero knowledge proof technique. Aiming at the situation, in the process of generating the original verifiable statement, the proving generation platform records the proving generation algorithm matched with the encryption algorithm adopted by the proving generation platform and the algorithm identification of the proving verification algorithm in the original verifiable statement so as to indicate the corresponding user to adopt the algorithm corresponding to the algorithm identification. Specifically, the verifiable statement includes a first algorithm identification of the attestation generation algorithm, the first algorithm identification being used to instruct the attestation party to determine a corresponding attestation generation algorithm based on the first algorithm identification; and/or the verifiable statement comprises a second algorithm identification proving the verification algorithm, the second algorithm identification being used to instruct the verifier to determine the proving verification algorithm based on the second algorithm identification.
In the process of generating the original verifiable statement by the certification generation platform, the certification generation platform may sign first statement content (including the statement certification generation platform, the statement receiving party, the statement expiration time, the statement issuing time, and the like, which will be described in detail below) different from the plain text privacy information and the random character string in the original verifiable statement to obtain a first signature, and record the first signature in the original verifiable statement. In other words, the original verifiable claim includes a first signature of the proof generating platform for the first claim content in the original verifiable claim, and the proof generating platform endorses the proving party through the first signature. Based on the inclusion of the first signature of the attestation generation platform in the original verifiable claim, the verifier determines that the preconditions for verification by the prover include that the attestation corresponding to the verifiable claim passed and that the first signature passed.
In addition, the certification generation platform may sign the second plaintext content (at least including plaintext privacy information and a random string) in the original verifiable claim to obtain a second signature, and record the second signature in the original verifiable claim, that is, the original verifiable claim includes the second signature of the certification generation platform for the second plaintext content in the original verifiable claim. Then, after obtaining the original verifiable claim, the prover may sign-verify a second signature included in the original verifiable claim to generate the verifiable claim if the second signature verifies passed (indicating that the original verifiable claim was generated by the prover generation platform and was not tampered with).
In this embodiment, the certification-generating platform may be further configured to generate a corresponding certificate in response to the certificate-generating request after generating the verifiable claim, so that the proving party may provide relevant data to the certification-generating platform (e.g. recorded in the certificate-generating request, or provided by another request different from the certificate-generating request) to instruct the certification-generating platform to generate a certificate indicating that the privacy data recorded in the claim held by the proving party satisfies a certain condition. Specifically, the certification generation platform may input the privacy data, the judgment conditions (which may be set or provided by the verifier) and the judgment result for indicating that the privacy data meets the judgment conditions into the certification generation algorithm to generate the certification corresponding to the verifiable statement for indicating that the ciphertext data recorded in the verifiable statement meets the judgment conditions.
In the above example, the age of the user a is 25 years, the judgment condition set by the verifier for the age is "age 18 years", and the 25 years >18 years, the judgment result is "yes", that is, the judgment result is that the age of the user a meets the judgment condition "age 18 years". Accordingly, the certification generation platform may input "age 25 years", "age 18 years of user a", and "yes" as a result of the determination into the certification generation algorithm to generate a certification corresponding to the verifiable statement.
Step 104, generating a first proof under the condition that a first proof generating condition is met, wherein the first proof generating condition comprises that a first proof generating request for the declaration initiated by the proving party is received, and the relation between the privacy data and the judging condition is verified to be matched with a first judging result provided by the proving party, and the first proof is used for indicating that the relation between the ciphertext data and the judging condition is matched with the first judging result to a verifying party under the verification of a zero knowledge proving algorithm.
In this embodiment, based on the above manner of generating the verifiable statement and the corresponding proof, the proof party may provide the verifiable statement and the corresponding proof to the verifier, and the verifier determines whether the relationship between the ciphertext data recorded in the verifiable statement and the determination condition matches the determination result, i.e., whether the ciphertext data recorded in the verifiable statement satisfies the determination condition, based on the proof. Therefore, whether the privacy information of the proving party meets a certain condition can be determined through the verifiable statement and the corresponding certificate held by the proving party, namely the verifiable statement and the corresponding certificate embody the information of whether the privacy information of the proving party meets the certain condition, and the information also belongs to the privacy of the proving party, meanwhile, the verifiable statement and the corresponding certificate have the possibility of being forwarded to other users by the proving party, and the other users can acquire the privacy, so that the privacy of the proving party is revealed.
In the following, and by way of example from a user perspective, a prover typically only wants a specified verifier to verify a verifiable claim and corresponding proof, and does not want the verifier to leak the claim and proof. For example, the verifiable statement held by prover a and the corresponding proof collectively indicate that "prover a is older than 18 years old" while prover a only wishes target merchant b to verify that subsequent transactions are being conducted. In this case, after the target merchant b obtains the verifiable statement and the corresponding proof of the prover a, the target merchant b may forward the verifiable statement and the corresponding proof to the merchant c, and the merchant c may also obtain the information of "the age of the prover a is more than 18 years old" through the verifiable statement and the corresponding proof (the information is true and reliable), which means that the target merchant b leaks the privacy of the prover a.
In view of the above-described problem that the verifier has compromised the prover privacy, the present specification further opens, to the verifier, the right to request "falsify" the proof corresponding to the verifiable statement held by the prover, on the basis of the above-described proof generation scheme, and the proof "falsified" for the verifier is similar to the proof that the prover requests to generate, and can also be used to indicate the relationship between ciphertext data (corresponding privacy data) recorded in the corresponding verifiable statement and the judgment condition. Since the verifier also has the authority to instruct the credential generation platform to generate the credential, there is a possibility that the verifier may dislike, i.e., the relationship between ciphertext data and judgment conditions in the verifiable statement indicated by the verifier request to generate the credential and the prover request to generate the credential may be different (of course, may be the same). For example, the proof generated by the proving party request is used for indicating that the relation between the ciphertext data and the judging condition is matched with the first judging result, the proof generated by the verifying party request is used for indicating that the relation between the ciphertext data and the judging condition is matched with the second judging result, and if the second judging result set by the verifying party is inconsistent with the first judging result, the verifying party is proved to forge the proof.
Then, when the verifiable statement and the corresponding certificate are forwarded to other devices by the verification party, the other devices cannot determine the authenticity of the certificate obtained from the verification party (cannot determine whether the certificate is the same as the first certificate provided by the proving party) due to the possibility of forging the certificate by the verification party, and the information of whether the privacy information of the proving party determined according to the verifiable statement provided by the verification party and the corresponding certificate meets the judging condition is not necessarily authentic, namely the authenticity is doubtful. By the way of developing the falsification proof authority to the verifier, the verifier cannot guarantee the authenticity of the proof forwarded to other devices, namely the proof forwarded by the verifier is not credible, so that the risk of privacy leakage of the verifier is reduced.
For convenience of description, the present specification refers to a proof generation request initiated by a proof-direction proof generation platform as a first proof generation request, and refers to a proof generation request initiated by a proof-direction proof generation platform as a second proof generation request. Accordingly, the attestation generated by the attestation generation platform in response to the first attestation generation request is referred to as a first attestation, and the attestation generated by the attestation generation platform in response to the second attestation generation request is referred to as a second attestation. Of course, the above description of "first", "second" is only used to distinguish between the prover and the verifier-initiated prover generation request; for example, the credential generation request initiated by the credential generation platform may also be referred to as a second credential generation request, and the credential generation request initiated by the credential generation platform may be referred to as a first credential generation request, which is not limited in this specification.
It should be noted that the first proof generation request is initiated by the proving party and is used for instructing the proving generation platform to generate the correct proof, so that after the proving generation platform receives the first proof generation request, it needs to verify whether the relationship between the privacy data and the judgment condition matches the first judgment result provided by the proving party, so as to generate the first proof when the relationship between the privacy data and the judgment condition matches the first judgment result. And for the second proof generating request initiated by the verifier, as the right of forging the proof corresponding to the verifiable statement held by the verifier is opened to the verifier, whether the relation between the verification ciphertext data and the judging condition is matched with the second judging result provided by the verifier is not required. Therefore, the certification generation platform only needs to directly generate the second certification when receiving the second certification generation request initiated by the verifier.
And step 106, generating a second proof under the condition that a second proof generating condition is met, wherein the second proof generating condition comprises that a second proof generating request for the statement initiated by the verifier is received, and the second proof is used for indicating that the relation between the ciphertext data and the judging condition is matched with a second judging result provided by the verifier under the verification of a zero knowledge proof algorithm.
In this embodiment, after generating the second certificate, the certificate generation platform may return the second certificate to the verifier in response to the second certificate generation request, so that the verifier holds the certificate that itself requested to be generated.
In this embodiment, the authority of the "fake" proof is only opened to the verifier, so that the proof generating platform needs to perform identity verification on the requester of the second proof generating request when receiving the second proof generating request. Wherein the identity of the verifier may be confirmed by an asymmetric key of the verifier. For example, in the case where the public key of the verifier is configured in advance in the credential generation platform, in the case where the second credential generation request is received, a private key provided by the requester of the second credential generation request (for example, included in the second credential generation request or provided by another request) may be obtained, and a corresponding public key is generated according to the private key, so that in the case where the generated public key is the same as the public key of the verifier, the requester is determined to be the verifier.
In this embodiment, the credential generation platform may return the first credential to the proving party to be provided by the proving party to the verifying party, and the verifying party may complete the verification process based on the verifiable claim of the proving party and the first credential. Or the certification generation platform can acquire the receiving address of the verifier provided by the certifier and send the first certification to the receiving address so that the verifier obtains the first certification and further completes the verification process according to the verifiable statement of the certifier and the first certification.
In this embodiment, in order to make the user of the other device than the verifier sufficiently aware that the verifier has the authority to "forge" the certificate, thereby to question the authenticity of the certificate provided by the verifier, the information of the above-described second certificate generation condition may be recorded in the declaration of the verifier, or the second certificate generation condition may be set as public information. For example, an identification of the second attestation generation condition may be recorded in the declaration of the prover, and then the other device may query the second attestation generation condition for viewing by the user through the identification; or directly record the content of the second proof generating condition in the declaration of the proving party. For another example, the content of the second proof-of-production condition may be published in an official website for public viewing. Of course, the present specification does not limit how the specific implementation of the second proof generating condition is published.
For easy understanding, the technical solutions of the present specification are described in detail below with reference to fig. 2 to 5.
Fig. 2 is an interaction diagram for creating a DID provided by an exemplary embodiment. As shown in fig. 2, the interaction process may include the steps of:
step 202, the proving party creates a DID, a key pair corresponding to the DID, and a corresponding DID document.
In this embodiment, the user may log in his own user account on the client used as a prover, so that the client acts as a prover. Wherein identities may be created for individual users through DIS (Decentralized IDENTIFIER SERVICE, decentralised identity service), which may provide the user with DID (Decentralized Identifier, decentralised identity identifier) that is fully controlled by the user himself, without any restrictions of a single registry, identity facilitator or authentication center. Taking the example of creating the DID for the proving party, the key pair corresponding to the proving party DID includes a public key and a private key, the public key needs to be issued to the blockchain for certification, and the private key corresponding to the proving party DID is stored by the proving party, for example, stored locally on the client.
In the DIS system, a DID (Decentralized Identifier, decentralised avatar identifier) corresponds to an entity (e.g., user such as issuer, prover, verifier, etc. of VC), and for a specific use of the DID, it is described by a DID Document (DID Document) corresponding to the DID. The DID document is used to describe how to use the corresponding DID, and contains at least the public key of the corresponding DID; in addition, information such as encryption mode, certification purpose, verification method and server can be recorded. Wherein the certification objective is combined with a verification method to provide a mechanism to certify things. For example, the DID document may specify a particular authentication method, such as a cryptographic public key or a pseudonym biometric protocol, that may be used to authenticate the method created for the purpose. The service endpoint supports trusted interactions with the DID controller. The DID and DID documents may be registered directly on the blockchain or other distributed network without requiring application from a centralized registration authority, and by taking advantage of the non-tamperable, hashed encryption, etc. characteristics of the blockchain or other distributed network technology, it is possible to make the digital identity truly owned and governed by the user, without any intermediary (even the DID technology provider) touching and holding the identity and data of the controlling user.
In step 204, the proving party creates a transaction for the certification of the DID and the DID document.
Step 206, proving to submit the transaction for certification of the DID and DID documents to the blockchain network.
Step 208, the blockchain network verifies the DID and the DID document on the blockchain.
Step 210, prove that the receipt for which the DID creation was successful is acquired by the direction blockchain network.
In this embodiment, the blockchain network may generate an event for logging the success of the DID and DID documents after the DID and DID documents are authenticated, and store the event in the blockchain log. Then the prover may obtain the event through a blockchain callback mechanism to determine that the DID and DID documents are stored on the blockchain, i.e., the prover succeeded in creating the DID. Or may also generate a corresponding hint message for the prover to view to tell the prover that the DID creation on the chain was successful.
FIG. 3 is an interaction diagram for issuing a verifiable claim provided by an example embodiment. As shown in fig. 3, the interaction process may include the steps of:
Step 302, the prover creates a claims issuance request (containing the prover DID, plain text privacy information, and identity information of the prover).
Step 304, the certificate sends a claim issuance request to the issuer.
Step 306, the issuer reads the prover DID contained in the claims issuance request.
The issuing party initiates a query transaction for the prover DID to the blockchain network, step 308.
In step 310, the blockchain network queries the DID document corresponding to the prover DID in response to the query transaction.
Step 312, the blockchain network returns the queried DID document to the issuer.
In step 314, the issuer sends a DID authentication challenge message (containing challenge data) to the prover.
In this embodiment, as is known from the process of creating the DID in fig. 2 described above, a public key corresponding to the prover DID is recorded in the DID document of the prover DID, and then the public key can be used to verify whether the prover DID in the claims issuing request is the DID actually held by the prover, that is, whether the prover is the legitimate wner of the prover DID in the claims issuing request.
The issuer may randomly generate a challenge data (e.g., a string) and send the challenge data to the prover via a DID authentication challenge message (DID auth challenge) to instruct the prover to sign it with its own private key (i.e., the private key corresponding to the prover DID) and return the challenge data and signature. Then, the issuer may verify the signature using the public key in the DID document, and further, in case the signature verification passes, confirm that the prover is a legitimate wner declaring the prover DID recorded in the issue request.
In step 316, the proving party signs the challenge data with a private key corresponding to the proving party DID.
Step 318, the certification returns challenge data to the issuer.
Step 320, the issuer uses the public key in the DID document for signature verification.
In the present embodiment, in addition to the above-described manner of transmitting the DID authentication challenge message, a manner of adding a signature to the claim issuance request may be employed. Specifically, the prover adds a signature for the content in the declaration issuing request in the created declaration issuing request, and after the issuer obtains the DID document, the issuer can verify the signature in the declaration issuing request by using the public key recorded in the DID document, thereby confirming that the prover is the legal wner of the prover DID recorded in the declaration issuing request.
Step 322, the issuer performs authenticity verification on the plaintext privacy information if the signature verification passes.
In this embodiment, when creating the claim issuing request, the identity information of the prover may be recorded in the claim issuing request as a basis for the issuer to perform authenticity verification on the plaintext privacy information. Then, after the verification of the identifier DID is completed, the authenticity of the plaintext privacy information may be further verified according to the identity information of the prover recorded in the claim issuing request. For example, the identity information of the prover may include an identification number, native place, year and month of birth, house information, etc. of the prover, and then an issuer (such as a civil office or public security authority) may perform authenticity verification on the age of the prover based on the identity information.
In step 324, the issuer encrypts the plaintext privacy information and the random string to obtain ciphertext data by using an encryption algorithm under the condition that the verification is passed, and generates an original verifiable statement for the ciphertext data.
In this embodiment, the DID is an identity of an entity, and specific information about which rights, capabilities, behaviors, and assets the entity possesses is expressed through VC. It should be noted that a DID may possess one or more VCs. For example, the following fields may be included in the VC:
issuer: statement issuer (issuer);
the subject is: declaring the DID of the recipient (issuing object);
expire: declaring an expiration time;
issuance date: declaring an issuance time;
claim: declaring content;
proof: validity proof (proof different from the proof generated by the above-mentioned proving party).
The issuer can generate a random character string (or generated by the proving party and provided to the issuer) and then splice with the plaintext privacy information to encrypt the spliced character string by adopting an encryption algorithm to obtain ciphertext data. Where the issuer may record its own DID (i.e., issuer DID) in issuer, the prover DID in didsubject, the assertion expiration time in expire, the time of issuance of VC in issuance date, and the plaintext privacy information, random string, and ciphertext data in claim. Specifically, the claim field may be extended to further include plaintext, random and commitment. plaintext is used for recording plaintext privacy information, such as an 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 one hand, the issuer may use its own private key to sign the other declaration contents (i.e., the first declaration content, including ciphertext data) except for the plaintext privacy information and the random string in the VC to obtain a 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 may sign the declaration content (i.e., the second declaration content) including at least the plaintext privacy information and the random string with its own private key to obtain a second signature, and record the second signature in proof, for example, in signaturevalue fields of proof.
For example, the contents of the original verifiable claim are as follows:
In addition, there may be multiple sets of encryption algorithms based on zero knowledge proof techniques and corresponding proof generating algorithms and proof verifying algorithms, i.e. each set of algorithms comprises an encryption algorithm, a proof generating algorithm and a proof verifying algorithm that are matched to each other. Or the issuer, prover, and verifier do not negotiate in advance what algorithm based on zero knowledge proof technique. In view of the above, in the process of generating the original verifiable statement, the issuer may record, in the original verifiable statement, an algorithm identifier of the attestation generation algorithm and the attestation verification algorithm that are matched with the encryption algorithm adopted by the issuer, so as to instruct the corresponding user to adopt an algorithm corresponding to the algorithm identifier. Of course, if an issuer, a prover and a verifier negotiate in advance what algorithm based on the zero knowledge proof technique is adopted, the above algorithm identification does not need to be recorded.
It should be noted that the above description of the fields included in the VC is merely an example, and may be flexibly adjusted according to practical situations in practical applications.
In step 326, the issuing party returns the original verifiable statement to the proving party.
In this embodiment, after the proving party obtains the original verifiable statement, the proving party may perform signature verification on the first signature and the second signature, respectively, so as to perform subsequent steps if the signature verification is passed.
Step 328, the proving party deletes the plaintext privacy information and the random string in the original verifiable claim to obtain the final verifiable claim.
In this embodiment, in order to ensure that the privacy information of the holder recorded in the VC is not revealed, the privacy information may still be described (the privacy information is proved to be truly valid), and the plaintext field and the random field in the VC obtained from the issuer may be deleted (the second signature may also be deleted), so as to obtain the VC that may be finally used.
With the above example, the final verifiable statement is as follows:
/>
Fig. 4 is a flow chart of another method of credential generation provided by an exemplary embodiment. As shown in fig. 4, the method applied to the proof generating platform may include the following steps:
Step 402, a first attestation generation request initiated by an attestation party is received.
In this embodiment, the proving party instructs the proving generation platform to generate the first proof through the first proof generation request; the first proof generation request may include private data of a proof party, a judgment condition for the private data, and a first judgment result. Of course, the privacy data may also be uploaded to the certification generation platform by the certifier through other approaches, and the judgment conditions may also be set by the verifier and uploaded to the certification generation platform. For example, in the case where a verifiable claim is issued by a credential generation platform to a prover, the credential generation platform may obtain private data during the issuing process.
Step 404, if the first determination result passes the verification, go to step 406; otherwise, go to step 412.
In this embodiment, since the first credential generation request is initiated by the credential party and is used to instruct the credential generation platform to generate a correct credential, the credential generation platform needs to verify whether the relationship between the privacy data and the judgment condition matches the first judgment result provided by the credential party after receiving the first credential generation request, so as to generate the first credential if the relationship between the privacy data and the judgment condition matches the first judgment result.
For example, the age (plain privacy information) of the user a is 25 years, the judgment condition set by the verifier for the age is "age 18 years", and since 25 years >18 years, the first judgment result is "yes", that is, the age of the user a is 18 years. After receiving the first proof generation request, the proof generation platform needs to verify whether the relationship between the age 25 years old of the user a and the age 18 years old is matched with the first judgment result of the age 18 years old of the user a.
In step 406, a first attestation is generated.
The private data of the proving party, which is accepted in the embodiment shown in fig. 3, contains plaintext private information and random strings. The proof generating platform can input the plaintext privacy information, the random character string, the judging condition and the first judging result into a proof generating algorithm to generate a proof. For example, the random string is h@ fwehdu, and the certification generation platform may splice the plaintext privacy information "age 25 of user a" and the random string "h@ $ fwehdu", and then input the spliced string, the judgment condition "age full 18 years" and the judgment result "yes" into the certification generation algorithm to generate a first certification corresponding to the verifiable statement, where the first certification may be used to indicate that the age of the ciphertext data record in the verifiable statement (the age of user a) is full 18 years under verification of the certification verification algorithm.
Step 408, if a second proof generation request is received, go to step 410; otherwise, go to step 412.
Step 410, a corresponding public key is generated from the private key of the verifier.
Step 412, the attestation generation operation is ended.
Step 414, if the generated public key is the same as the public key of the verifier, go to step 416; otherwise, go to step 418.
In this embodiment, the certification generation platform opens the right to "forge" the certification corresponding to the verifiable statement held by the certifying party to the verifying party, and then generates the second certification in response to the second certification generation request as long as the verifying party initiates the second certification generation request, without verifying whether the relationship between the ciphertext data and the judgment condition matches the second judgment result provided by the verifying party.
The authority of the fake certification is only opened to the verifier, so that the certification generation platform needs to perform identity verification on the requester of the second certification generation request when receiving the second certification generation request. Wherein the identity of the verifier may be confirmed by an asymmetric key of the verifier. For example, the verifier may first generate its own private key using an asymmetric encryption algorithm, then generate a corresponding public key according to the private key, and provide the public key to the certification generation platform, i.e. configure the public key of the verifier in the certification generation platform in advance. Then, the proof generating platform may obtain a private key provided by the requester of the second proof generating request (for example, included in the second proof generating request or provided by another request) in the case of receiving the second proof generating request, and generate a corresponding public key according to the private key, so as to determine that the requester is the verifier in the case that the generated public key is the same as the public key of the verifier. Among them, an asymmetric encryption algorithm such as KDF (Key derivation function ) algorithm, RSA algorithm, ECC (elliptic curve cryptography (elliptic curve cryptography, elliptic curve cryptography), DSA (Digital Signature Algorithm ) and the like can be used, and of course, this description is not limited thereto.
For another example, the public key of the verifier may be configured in advance on the credential generation platform, and the requester signs the second credential generation request through its own private key, so that the credential generation platform may adopt the public key of the verifier to sign the signature of the second credential generation request when receiving the second credential generation request, so as to determine that the requester is the verifier when the sign passes. Of course, any other means for authentication may be used, and this is not a limitation of the present specification.
At step 416, a second attestation is generated.
Aiming at the problem that the privacy of the proving party is revealed by the verifying party, the proving generation platform opens the authority for requesting the verifying party to 'forge' the proving corresponding to the verifiable statement held by the proving party, and the proving for the verifying party 'forge' is similar to the proving requested to be generated by the proving party, and can be used for indicating the relation between the ciphertext data (corresponding privacy data) recorded in the corresponding verifiable statement and the judging condition. Since the verifier also has the authority to instruct the credential generation platform to generate the credential, there is a possibility that the verifier may dislike, i.e., the relationship between ciphertext data and judgment conditions in the verifiable statement indicated by the verifier request to generate the credential and the prover request to generate the credential may be different (of course, may be the same).
In the above example, the second determination result provided by the verifier is "no", i.e. less than 18 years old. Further, the attestation generation platform may generate a second attestation corresponding to the verifiable claim that may be used to indicate that the age of the ciphertext data record in the verifiable claim (the age of user a) is less than 18 years under verification by the attestation verification algorithm, whereas the age of the ciphertext data record in the verifiable claim is in fact 18 years old, i.e., the verifying party "counterfeits" the attestation.
Then, when the verifiable statement and the corresponding certificate are forwarded to other devices by the verification party, the other devices cannot determine the authenticity of the certificate obtained from the verification party (cannot determine whether the certificate is the same as the first certificate provided by the proving party) due to the possibility of forging the certificate by the verification party, and the information of whether the privacy information of the proving party determined according to the verifiable statement provided by the verification party and the corresponding certificate meets the judging condition is not necessarily authentic, namely the authenticity is doubtful. By the way of developing the falsification proof authority to the verifier, the certificate forwarded by the verifier is not trusted, so that even if the verifier forwards the certificate to other equipment, the other equipment can question the certificate forwarded by the verifier and can not use the information of whether the privacy information of the verifier meets the judgment condition or not determined according to the verifiable statement and the certificate as trusted privacy information, thereby reducing the risk of revealing privacy by the verifier.
Step 418, outputting an authentication failure message.
Fig. 5 is an interaction diagram of a proof of verification party provided by an example embodiment. As shown in fig. 5, the interaction process may include the steps of:
Step 502, the prover creates a verification request (containing the prover DID).
Step 505, the attestation sends an authentication request to the verifier.
Step 506, the verifier verifies the proving party DID.
Based on the proving party representing its own identity by the DID, the proving party needs to provide the proving party DID to the verifying party to verify the proving party DID by the verifying party, i.e. to verify that the proving party is the legitimate wner of the provided proving party DID. The process of verifying the proving party DID may refer to steps 308-320 in fig. 3, which are not described herein.
At step 508, the attestation sends the verifiable statement and the corresponding attestation (first attestation) to the verifying party.
In this embodiment, the proving party needs to prove to the verifying party that the private information of the proving party meets the judging condition set by the verifying party, and then needs to provide to the verifying party the VC and the corresponding certificate (first certificate) obtained in the embodiment shown in fig. 3.
Step 510, the verifier verifies the verifiable claim.
In this embodiment, the verifier may verify the first signature in the verifiable claim by signing it with the public key of the issuer, thereby verifying the data integrity of the verifiable claim (whether tampered with) and whether issued by the issuer. Wherein, since the issuer DID is recorded in the issuer field of the verifiable statement, the issuer public key can be queried from the blockchain network according to the issuer DID, and the specific process is similar to the above steps 306-312, and will not be repeated here.
Step 512, the verifier verifies the proof.
In this embodiment, the verifier may verify the ciphertext data in the verifiable statement by proving the verification algorithm and the proof, and determine whether the ciphertext data meets the judgment condition. Because the first proof is a correct proof, the verifier can determine that the relation between the ciphertext data and the judgment condition is matched with the first judgment result under the verification of the proof verification algorithm. Wherein, in the case that the proof verification passes and the first signature verification passes, it can be determined that the proof party verification passes.
Step 514, the verifier determines that the prover verification is passed, and performs related business operations for the prover.
Step 516, the verification direction proving party returns the execution result of the business operation.
Taking the internet bar as an example to verify whether the user a is over 18 years old, after the user a is determined to pass the verification, the verifier of the internet bar can generate a payment order for the user a and return the information of the payment order to the client of the user a.
Corresponding to the above method embodiments, the present specification also provides an embodiment of a proof generating device.
Fig. 6 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 6, at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile storage 610, although other hardware required by other services is possible. The processor 602 reads a corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs to form the credential generating device at a logic level. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.
Referring to fig. 7, in a software implementation, the credential generating device may include:
An acquisition unit 71 that acquires private data of a proving party and a judgment condition for the private data, the declaration of the proving party including ciphertext data obtained by encrypting the private data;
A first generation unit 72 that generates a first proof in the case where a first proof generation condition is satisfied, the first proof generation condition including receiving a first proof generation request for the declaration initiated by the proving party and verifying that a relationship between the privacy data and the judgment condition matches a first judgment result provided by the proving party, the first proof being for indicating to the verifying party that the relationship between the ciphertext data and the judgment condition matches the first judgment result under verification of a zero knowledge proof algorithm;
And a second generation unit 73 that generates a second proof in the case where a second proof generation condition is satisfied, the second proof generation condition including receipt of a second proof generation request for the declaration initiated by the verifier, the second proof being for indicating that a relationship between the ciphertext data and the judgment condition matches a second judgment result provided by the verifier under verification of a zero-knowledge proof algorithm.
Optionally, the method further comprises:
And a verification unit 74, configured to obtain a private key provided by a requester of the second proof generation request, generate a corresponding public key according to the private key, and determine that the requester is the verifier when the generated public key is the same as the public key of the verifier.
Optionally, the method further comprises:
A first return unit 75 that returns a first certificate to the proving party to provide the first certificate to the verifying party by the proving party; or alternatively
And acquiring a receiving address of the verification party provided by the proving party, and sending a first proving to the receiving address so that the verification party obtains the first proving.
Alternatively to this, the method may comprise,
The statement comprises information of a second proof generating condition; or the second proof generating condition is public information.
Optionally, the claims include verifiable claims; the apparatus further comprises:
An issuing unit 76 that, in response to a declaration issuing request initiated by the prover, inquires the blockchain network of a public key corresponding to a decentralised identifier included in the declaration issuing request;
Sending a challenge message to the proving party, wherein the challenge message is used for instructing the proving party to sign challenge data contained in the challenge message by using a private key of the proving party;
And generating a verifiable statement comprising the ciphertext data and the decentralised identifier, wherein the decentralised identifier is used for indicating that a receiver of the verifiable statement is the proving party under the condition that challenge data returned by the proving party passes verification by using the queried public key.
Optionally, the verification unit 74 is further configured to:
Carrying out authenticity verification on the private data of the proving party;
and encrypting the privacy data to obtain the ciphertext data under the condition that verification is passed so as to generate the verifiable statement.
Optionally, the privacy data includes plaintext privacy information and a random string of the proving party.
Optionally, the method further comprises:
the first return unit 77 returns the second certificate to the verifier in response to the second certificate generation request.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than 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. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or 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 description to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "in response to a determination" depending on the context.
The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims (11)

1. A certification generation method is applied to a certification generation platform and comprises the following steps:
Acquiring privacy data of a proving party and judging conditions aiming at the privacy data;
Generating a first proof under the condition that a first proof generating condition is satisfied, wherein the first proof generating condition comprises that a first proof generating request initiated by the proving party aiming at the proving party is received, and the relation between the privacy data and the judging condition is verified to be matched with a first judging result provided by the proving party, and the first proof is used for indicating that the relation between ciphertext data in the proving and the judging condition is matched with the first judging result to a verifying party under the verification of a zero knowledge proving algorithm; the declaration of the proving party comprises ciphertext data obtained by encrypting the privacy data, wherein the declaration is issued by an issuer according to the request of the proving party and is used for indicating that the privacy data of the proving party is true and reliable;
Generating a second proof under the condition that a second proof generating condition is met, wherein the second proof generating condition comprises receiving a second proof generating request for the statement initiated by the verifier, the second proof is used for indicating that the relation between ciphertext data in the statement and the judging condition is matched with a second judging result provided by the verifier under the verification of a zero knowledge proof algorithm, and the statement and the second proof are used for knowing that the verifier has the authority of forging the certificate to a user of other devices except the verifier.
2. The method of claim 1, further comprising:
acquiring a private key provided by a requester of a second proof generation request, and generating a corresponding public key according to the private key;
and determining that the requesting party is the verifying party under the condition that the generated public key is the same as the public key of the verifying party.
3. The method of claim 1, further comprising:
Returning a first attestation to the proving party to provide the first attestation to the verifying party by the proving party; or alternatively
And acquiring a receiving address of the verification party provided by the proving party, and sending a first proving to the receiving address so that the verification party obtains the first proving.
4. The method according to claim 1,
The statement comprises information of a second proof generating condition; or the second proof generating condition is public information.
5. The method of claim 1, the claims comprising verifiable claims; the method further comprises the steps of:
Responding to a declaration issuing request initiated by the proving party, and inquiring a public key corresponding to a decentralization identifier contained in the declaration issuing request from a blockchain network;
Sending a challenge message to the proving party, wherein the challenge message is used for instructing the proving party to sign challenge data contained in the challenge message by using a private key of the proving party;
And generating a verifiable statement comprising the ciphertext data and the decentralised identifier, wherein the decentralised identifier is used for indicating that a receiver of the verifiable statement is the proving party under the condition that challenge data returned by the proving party passes verification by using the queried public key.
6. The method of claim 5, further comprising:
Carrying out authenticity verification on the private data of the proving party;
and encrypting the privacy data to obtain the ciphertext data under the condition that verification is passed so as to generate the verifiable statement.
7. The method of claim 1, the privacy data comprising plaintext privacy information and a random string of the proving party.
8. The method of claim 1, further comprising:
in response to the second attestation generation request, a second attestation is returned to the verifier.
9. A proof generating device applied to a proof generating platform, comprising:
an acquisition unit that acquires privacy data of a proving party and a judgment condition for the privacy data;
A first generation unit that generates a first proof in a case where a first proof generation condition is satisfied, the first proof generation condition including receiving a first proof generation request for a declaration of the proving party initiated by the proving party, and verifying that a relationship between the privacy data and the judgment condition matches a first judgment result provided by the proving party, the first proof being for indicating to a verifying party that a relationship between ciphertext data in the declaration and the judgment condition matches the first judgment result under verification of a zero-knowledge proof algorithm; the declaration of the proving party comprises ciphertext data obtained by encrypting the privacy data, wherein the declaration is issued by an issuer according to the request of the proving party and is used for indicating that the privacy data of the proving party is true and reliable;
And the second generation unit is used for generating a second certificate under the condition that a second certificate generation condition is met, wherein the second certificate generation condition comprises a second certificate generation request which is initiated by the verifier and aims at the statement, the second certificate is used for indicating that the relation between ciphertext data in the statement and the judgment condition is matched with a second judgment result provided by the verifier under the verification of a zero knowledge proof algorithm, and the statement and the second certificate are used for knowing that the verifier has the authority of forging the certificate to a user of other equipment except the verifier.
10. An electronic device, comprising:
A processor;
A memory for storing processor-executable instructions;
Wherein the processor is configured to implement the method of any of claims 1-8 by executing the executable instructions.
11. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-8.
CN202210179222.9A 2022-02-25 2022-02-25 Method and device for generating certification, electronic equipment and storage medium Active CN114389810B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210179222.9A CN114389810B (en) 2022-02-25 2022-02-25 Method and device for generating certification, electronic equipment and storage medium
PCT/CN2022/135645 WO2023160097A1 (en) 2022-02-25 2022-11-30 Proof generation method and apparatus, electronic device, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210179222.9A CN114389810B (en) 2022-02-25 2022-02-25 Method and device for generating certification, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN114389810A CN114389810A (en) 2022-04-22
CN114389810B true CN114389810B (en) 2024-06-18

Family

ID=81205631

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210179222.9A Active CN114389810B (en) 2022-02-25 2022-02-25 Method and device for generating certification, electronic equipment and storage medium

Country Status (2)

Country Link
CN (1) CN114389810B (en)
WO (1) WO2023160097A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114389810B (en) * 2022-02-25 2024-06-18 蚂蚁区块链科技(上海)有限公司 Method and device for generating certification, electronic equipment and storage medium
CN117454437B (en) * 2023-12-22 2024-03-22 北京天润基业科技发展股份有限公司 Transaction processing method, storage medium and electronic device

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110224837A (en) * 2019-06-06 2019-09-10 西安纸贵互联网科技有限公司 Zero-knowledge proof method and terminal based on distributed identity
CN111898153A (en) * 2020-03-18 2020-11-06 支付宝(杭州)信息技术有限公司 Contract calling method and device

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108830107B (en) * 2018-06-25 2021-10-26 北京奇虎科技有限公司 Method and device for protecting privacy information, electronic equipment and computer readable storage medium
JP2021077941A (en) * 2019-11-05 2021-05-20 ソニー株式会社 Generation device, generation method, and verification device
CN112347516A (en) * 2020-11-27 2021-02-09 网易（杭州）网络有限公司 Asset certification method and device based on block chain
CN112733163B (en) * 2021-01-04 2023-02-03 北京航空航天大学 Monitorable zero-knowledge proof method and device based on discrete logarithm equality proof
CN113364597A (en) * 2021-05-31 2021-09-07 中国工商银行股份有限公司 Privacy information proving method and system based on block chain
CN114389810B (en) * 2022-02-25 2024-06-18 蚂蚁区块链科技(上海)有限公司 Method and device for generating certification, electronic equipment and storage medium

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110224837A (en) * 2019-06-06 2019-09-10 西安纸贵互联网科技有限公司 Zero-knowledge proof method and terminal based on distributed identity
CN111898153A (en) * 2020-03-18 2020-11-06 支付宝(杭州)信息技术有限公司 Contract calling method and device

Also Published As

Publication number Publication date
WO2023160097A1 (en) 2023-08-31
CN114389810A (en) 2022-04-22

Similar Documents

Publication Publication Date Title
US12015716B2 (en) System and method for securely processing an electronic identity
US10673632B2 (en) Method for managing a trusted identity
AU2021206913B2 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
US20220321359A1 (en) Methods and systems for ownership verification using blockchain
JP7181539B2 (en) METHOD AND APPARATUS FOR MANAGING USER IDENTIFICATION AND AUTHENTICATION DATA
US8812851B2 (en) Method for reading an attribute from an ID token
KR20210040078A (en) Systems and methods for safe storage services
CN114389810B (en) Method and device for generating certification, electronic equipment and storage medium
WO2023160090A1 (en) Proof generation method and apparatus, electronic device, and storage medium
US20240187259A1 (en) Method and apparatus for generating, providing and distributing a trusted electronic record or certificate based on an electronic document relating to a user
US7739500B2 (en) Method and system for consistent recognition of ongoing digital relationships
KR102157695B1 (en) Method for Establishing Anonymous Digital Identity
CN116975936B (en) Finance qualification proving method and finance qualification verifying method
EP4210276A1 (en) Method and apparatus for generating certified user data
US20230298015A1 (en) Systems and methods for verification of protected private information
JP2022104875A (en) Repudiable credentials
CN117155553A (en) Certificate storing method, device, medium and equipment
Moniava et al. Extending DigiD to the private sector (DigiD-2)

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant