WO2023160097A1 - 证明生成方法及装置、电子设备、存储介质 - Google Patents

证明生成方法及装置、电子设备、存储介质 Download PDF

Info

Publication number
WO2023160097A1
WO2023160097A1 PCT/CN2022/135645 CN2022135645W WO2023160097A1 WO 2023160097 A1 WO2023160097 A1 WO 2023160097A1 CN 2022135645 W CN2022135645 W CN 2022135645W WO 2023160097 A1 WO2023160097 A1 WO 2023160097A1
Authority
WO
WIPO (PCT)
Prior art keywords
prover
certificate
proof
statement
verifier
Prior art date
Application number
PCT/CN2022/135645
Other languages
English (en)
French (fr)
Inventor
林渝淇
魏长征
Original Assignee
蚂蚁区块链科技(上海)有限公司
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 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2023160097A1 publication Critical patent/WO2023160097A1/zh

Links

Images

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

Definitions

  • 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.
  • 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, thus avoiding the disclosure of the prover's privacy.
  • one or more embodiments of this specification provide a certificate generation method and device, electronic equipment, and a storage medium.
  • a proof generation method including:
  • the statement of the prover includes ciphertext data obtained by encrypting the private data
  • the first certificate generation condition includes receiving the first certificate generation request for the statement initiated by the prover, and verifying the private data and the The relationship between the judgment conditions matches the first judgment result provided by the prover, and the first proof is used to show the verification party the relationship between the ciphertext data and the judgment conditions under the verification of the zero-knowledge proof algorithm The relationship matches the first judgment result;
  • the second certificate is generated when the second certificate generation condition is satisfied, the second certificate generation condition includes receiving a second certificate generation request for the statement initiated by the verifier, and the second certificate is used in the zero-knowledge proof
  • the verification of the algorithm shows that the relationship between the ciphertext data and the judgment condition matches the second judgment result provided by the verifier.
  • a certificate generation device including:
  • An acquisition unit which acquires private data of the prover and judgment conditions for the private data, and the statement of the prover includes ciphertext data obtained by encrypting the private data;
  • the first generation unit generates the first certificate when the first certificate generation condition is satisfied, the first certificate generation condition includes receiving the first certificate generation request for the statement initiated by the prover and verifying all The relationship between the private data and the judgment condition matches the first judgment result provided by the prover, and the first certificate is used to show to the verifier that the ciphertext data and the The relationship between the judging conditions matches the first judging result;
  • the second generation unit generates a second certificate when the second certificate generation condition is satisfied, the second certificate generation condition includes receiving a second certificate generation request for the statement initiated by the verifier, and the second certificate uses Under the verification of the zero-knowledge proof algorithm, it is shown that the relationship between the ciphertext data and the judgment condition matches the second judgment result provided by the verifier.
  • an electronic device including:
  • memory for storing processor-executable instructions
  • the processor implements the method according to the first aspect by running the executable instruction.
  • a computer-readable storage medium 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.
  • 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 issuing verifiable claims provided by an exemplary embodiment.
  • Fig. 4 is a flow chart of another certificate generation method provided by an exemplary embodiment.
  • Fig. 5 is an interaction diagram for verifying a prover provided by an exemplary embodiment.
  • Fig. 6 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • Fig. 7 is a block diagram of a certificate generation device provided by an exemplary embodiment.
  • the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification.
  • the method may include more or less steps than those described in this specification.
  • 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.
  • FIG. 1 is a flow chart of a certificate generation method provided by an exemplary embodiment. As shown in Figure 1, this method is applied to the proof generation platform and may include the following steps:
  • Step 102 obtaining private data of the prover and judgment conditions for the private data, and the statement of the prover includes ciphertext data obtained by encrypting the private data.
  • the user as the certifier can log in his own user account on the client used, so that the client acts as the certifier, and the concepts of the verifier and the issuer are similar.
  • the proving party can request the issuing party to issue a statement that records the authentic private information of the proving party.
  • the issuing party first verifies the authenticity of the private information, and then issues the statement to the proving party after the authenticity verification is passed.
  • the issuing party as a trusted platform, endorses the proving party, and issues a statement to show that the private information of the proving party is true and reliable.
  • the identity 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 specific information such as the authority, capability, behavior and even assets of the entity can be expressed through VC.
  • 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, with the digital signature of the issuer attached. 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.
  • DID distributed digital identity
  • the statement records the attribute information of the user holding the statement, and the attribute information is usually the user's private information. If the private information recorded in the statement is in plain text, the user will expose the private information when providing his own statement to other users. risks of. Therefore, the privacy information recorded in the statements held by users who adopt distributed digital identities can be protected, so that the privacy information is "available and invisible".
  • the certifier can request the issuer to issue a statement that records the real private information of the certifier, and the issuer can encrypt the private information recorded in the issued statement when issuing the corresponding statement to the certifier.
  • the privacy protection of the prover is realized.
  • it can be combined with zero-knowledge proof technology to ensure that the private information recorded in the statement 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 statement "Available and invisible”.
  • Zero-knowledge proof technology includes encryption algorithm, proof generation algorithm and proof verification algorithm.
  • 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) conforms to the judgment conditions set for the private data (it can be understood as the verification pass condition for judging whether the private data passes the verification), and for the proof, the proof verification algorithm that matches the above proof generation algorithm can be used to verify that what the proof says is correct.
  • the above three types of algorithms included in the zero-knowledge proof technology are in a corresponding relationship.
  • the private data of user A includes age information, and the judgment condition set for age is "age at least 18 years old".
  • user A can provide his own age information to the issuer of the statement (for example, trusted institutions such as civil affairs bureaus and public security organs), and the issuer will verify the authenticity of the age information and pass it to user A.
  • a corresponding statement is issued in which the age information is recorded in ciphertext.
  • user A can generate a certificate indicating "18 years of age” for the age information in the statement, and provide the statement and certificate to the verifier (for example, a store with age restrictions on the products sold), so as to It is up to the verifier to judge whether user A is over 18 years old based on the statement and proof.
  • 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.
  • a commitment algorithm (Commitment) or a homomorphic encryption (Homomorphic Encryption) algorithm with homomorphic characteristics
  • the homomorphic commitment/encryption algorithm is denoted by HE()
  • the ciphertext form of plaintext t is HE(t).
  • 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.
  • 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.
  • 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).
  • the certificate generation platform may serve as the above-mentioned issuing party to issue a statement containing ciphertext data to the proving party.
  • the prover uses DID to identify itself, and instructs the proof generation platform to issue VC by initiating a statement issuance request to the proof generation platform, and the statement issuance request includes the prover DID.
  • the proof generation platform After receiving the statement issuance request, the proof generation platform first verifies the DID of the prover, and queries the blockchain network for the public key corresponding to the DID included in the statement issuance request; then, sends a challenge message to the prover, the challenge The message is used to instruct the prover to use the prover's private key to sign the challenge data contained in the challenge message.
  • the proof generation platform uses the public key queried from the blockchain network to perform signature verification (signature verification) on the challenge data, so as to determine that the prover DID is The DID held by the prover can then generate a verifiable statement containing the ciphertext data and the centralized identifier of the prover DID. By recording the prover DID in the verifiable statement, the prover DID can indicate the receipt of the verifiable statement Party is the above certifying party.
  • signature verification signature verification
  • the proof generation platform can first verify the authenticity of the private data of the prover, so that if the verification passes, the private data is encrypted to obtain ciphertext data, and then a verifiable statement is generated. By verifying the authenticity of the private data of the prover, it can ensure that the generated verifiable statement is authentic and reliable.
  • 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.
  • the plaintext private information is age
  • 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.
  • a random string can be generated (generated by the prover and provided to the proof generation platform, or generated by the proof generation platform), and the random string can be spliced with plaintext private information to obtain private data, and then the private data can be Encrypt to get ciphertext data.
  • the private data in this embodiment includes plaintext private information and random character strings of the prover.
  • the certificate generation platform before the certificate generation platform issues VC to the prover, it can verify the authenticity of the plaintext private information provided by the prover, so as to generate the original verifiable statement when the authenticity check passes.
  • the original verifiable statement Contains plaintext private information, random strings and ciphertext data.
  • the prover can obtain the original verifiable statement generated by the proof generation platform 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 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.
  • each set of algorithms includes mutually matching encryption algorithms, proof generation algorithms, and proof verification algorithms.
  • the proof generation platform, the prover and the verifier did not pre-negotiate which algorithm based on the zero-knowledge proof technology.
  • the proof generation platform records the algorithm identification of the proof generation algorithm and the proof verification algorithm that match the encryption algorithm adopted by itself in the original verifiable statement, so as to indicate that the corresponding user The algorithm corresponding to the algorithm ID is adopted.
  • 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.
  • the proof generation platform can distinguish the first statement content (including statement proof generation platform, statement receiver, statement Expiration time, statement issuance time, etc., which will be described in detail below) to sign to obtain the first signature, and record the first signature in the original verifiable statement.
  • the original verifiable statement contains the first signature of the proof generation platform for the content of the first statement in the original verifiable statement, and the proof generation platform endorses the prover through the first signature.
  • the verifier determines that the prerequisites for the verification of the prover include passing the verification of the proof corresponding to the verifiable statement and passing the verification of the first signature.
  • the proof generation platform 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 contains the second signature of the proof generation platform for the content of the second statement in the original verifiable statement. Then, after the prover obtains the original verifiable statement, he 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 is issued by the proof generation platform generated and not tampered with) to generate the above verifiable claim.
  • the certificate generation platform can also be used to generate a corresponding certificate in response to the certificate generation request, so the prover can provide relevant data to the certificate generation platform (such as recorded in the certificate generation request, or Provided by other requests that are different from the certificate generation request), to instruct the certificate generation platform to generate a certificate that indicates that the private data recorded in the statement held by the prover meets certain conditions.
  • the proof generation platform can input private data, judgment conditions (which may be set or provided by the verifier) and judgment results indicating that the private data meets the judgment conditions into the proof generation algorithm to generate a proof corresponding to a verifiable statement, The proof is used to show that the ciphertext data recorded in the verifiable statement meets the judgment conditions.
  • the proof generation platform can input "user A's age is 25 years old", “age over 18 years old” and the judgment result is "yes” into the proof generation algorithm to generate a proof corresponding to the verifiable statement.
  • Step 104 Generate a first certificate when the first certificate generation condition is satisfied, the first certificate generation condition includes receiving a first certificate generation request for the statement initiated by the certifier and verifying the privacy
  • the relationship between the data and the judgment condition matches the first judgment result provided by the prover, and the first proof is used to show the verifier that the ciphertext data and the judgment condition are related to each other under the verification of the zero-knowledge proof algorithm. The relationship between matches the first judgment result.
  • the prover can provide the verifiable statement and the corresponding certificate to the verifier, and the verifier can judge the ciphertext data recorded in the verifiable statement based on the certificate Whether the relationship with the judgment condition matches the judgment result, that is, it is judged whether the ciphertext data recorded in the verifiable statement satisfies the judgment condition. It can be seen that through the verifiable statement held by the prover and the corresponding certificate, it can be determined whether the private information of the prover meets certain conditions, that is, the verifiable statement and the corresponding certificate reflect the fact that "whether the private information of the prover meets certain conditions". This information also belongs to the privacy of the proving party. At the same time, the verifiable statement and the corresponding proof may be forwarded to other users by the verified party, so other users may obtain the privacy, resulting in the disclosure of the proving party's privacy.
  • the prover usually only wants the designated verifier to verify the verifiable statement and the corresponding proof, and does not want the verifier to leak the statement and proof.
  • the verifiable statement held by the certifier a and the corresponding certificate jointly indicate that "the age of the certifier a is greater than 18 years old", and the certifier a only wants the target merchant b to conduct subsequent transactions after the verification is passed.
  • the target merchant b can forward the verifiable statement and the corresponding certificate to the merchant c, then the merchant c can also pass the verifiable statement and the corresponding certificate Obtaining the information that "certifier a is older than 18 years old" (this information is true and reliable) means that target merchant b has leaked the privacy of certifier a.
  • this manual further opens the authority to the verifier to request "forgery" of the certificate corresponding to the verifiable statement held by the prover, and for The proof that the verifier "forges” is similar to the proof that the prover requests to generate, and can also be used to indicate the relationship between the ciphertext data (corresponding private data) recorded in the corresponding verifiable statement and the judgment condition.
  • the verifier Since the verifier also has the authority to instruct the proof generation platform to generate the proof, the verifier has the possibility of doing evil, that is, for the proof generated by the verifier request and the proof requested by the prover, the ciphertext in the verifiable statement indicated by the two
  • the relationship between data and judgment conditions may be different (of course, they may also be the same).
  • the certificate requested by the prover is used to show that the relationship between the ciphertext data and the judgment condition matches the first judgment result
  • the certificate requested by the verifier is used to show that the relationship between the ciphertext data and the judgment condition matches the first judgment result.
  • the two judgment results match, and if the second judgment result set by the verifier is inconsistent with the first judgment result, it means that the verifier has "forged" the certificate.
  • the verifier forwards the verifiable statement and the corresponding certificate to other devices, because the verifier has the possibility of "forging” the certificate, other devices cannot determine the authenticity of the certificate obtained from the verifier (it is impossible to determine whether it is consistent with the certificate or not).
  • the first proof provided by the party is the same), then the information "whether the private information of the prover meets the judgment conditions" determined based on the verifiable statement provided by the verifier and the corresponding certificate is not necessarily true and reliable, that is, the authenticity is doubtful.
  • the verifier cannot guarantee the authenticity of the certificate forwarded to other devices, that is, the certificate forwarded by the verifier is not credible, thereby reducing the risk of the verifier leaking privacy.
  • the certificate generation request initiated by the certificate party to the certificate generation platform is called the first certificate generation request
  • the certificate generation request initiated by the verification party to the certificate generation platform is called the second certificate generation request.
  • the certificate generated by the certificate generation platform in response to the first certificate generation request is called the first certificate
  • the certificate generated by the certificate generation platform in response to the second certificate generation request is called the second certificate.
  • the certificate generation request refers to the certificate generation request initiated by the verification direction certificate generation platform as the first certificate generation request, which is not limited in this specification.
  • the first proof generation request is initiated by the prover to instruct the proof generation platform to generate a correct proof. Therefore, after receiving the first proof generation request, the proof generation platform needs to verify the relationship between the private data and the judgment condition. Whether the relationship matches the first judgment result provided by the proving party, so as to generate the first proof under the condition that the relationship between the private data and the judgment condition matches the first judgment result.
  • the second certificate generation request initiated by the verifier since the verifier is given the authority to "forge" the certificate corresponding to the verifiable statement held by the verifier, there is no need to verify whether the relationship between the ciphertext data and the judgment condition is consistent with The second judgment result provided by the verifier matches. Therefore, the certificate generation platform can directly generate the second certificate upon receiving the second certificate generation request initiated by the verifier.
  • Step 106 Generate a second certificate when the second certificate generation condition is satisfied, the second certificate generation condition includes receiving a second certificate generation request for the statement initiated by the verifier, and the second certificate is used in The verification of the zero-knowledge proof algorithm shows that the relationship between the ciphertext data and the judgment condition matches the second judgment result provided by the verifier.
  • 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 generated upon its own request.
  • the authority to "forge" certificates is only open to the verifier, so when the certificate generation platform receives the second certificate generation request, it needs to perform identity verification on the requester of the second certificate generation request.
  • the identity of the verifier can be confirmed through the asymmetric key of the verifier.
  • the public key of the verifying party is pre-configured on the certificate generation platform, and when the second certificate generation request is received, the private key provided by the requesting party of the second certificate generation request (for example, included in the second certificate generation request) can be obtained. , or provided through other requests), and generate the corresponding public key based on the private key, so that if the generated public key is the same as the public key of the verifier, the requester is determined to be the verifier.
  • the certificate generation platform can return the first certificate to the prover, so that the prover can provide the first certificate to the verifier, and then the verifier can complete the verification process according to the verifiable statement of the prover and the first certificate.
  • the proof generation platform can obtain the receiving address of the verifying party provided by the proving party, and send the first proof to the receiving address, so that the verifying party can obtain the first proof, and then complete the verification process.
  • the above-mentioned The information of the second certificate generation condition, or the second certificate generation condition is set as public information.
  • the identification of the second proof generation condition can be recorded in the statement of the prover, and then other devices can query the second proof generation condition through the identification for users to view; or, directly record the second proof in the statement of the prover.
  • the content of the second certificate generation condition may be published on the official website for public viewing.
  • this specification does not limit how to publish the specific implementation of the second proof generation condition.
  • 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:
  • step 202 the prover creates a DID, a key pair corresponding to the DID and a corresponding DID document.
  • 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.
  • DIS Decentralized Identifier Service, decentralized identity service
  • DIS 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.
  • 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.
  • 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.
  • 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.
  • 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 successfully created 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 issuing verifiable claims provided by an exemplary embodiment. As shown in Figure 3, the interaction process may include the following steps:
  • 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.
  • 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.
  • 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.
  • 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.
  • a challenge data for example, a character string
  • DID auth challenge a DID authentication challenge message
  • 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.
  • a method of adding a signature to the statement issuing request may also be used.
  • 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.
  • step 322 the issuer verifies the authenticity of the plaintext private information if the signature verification is passed.
  • the identity information of the certifier when creating a statement issuance request, 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.
  • 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.
  • 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.
  • 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, VC can contain the following fields:
  • issuer statement issuer (issuer);
  • proof of validity (different from the proof generated by the above-mentioned prover).
  • the issuer can generate a random character string (or generate it by the prover and provide it to the issuer), and then splice it with the plaintext private information, and use an encryption algorithm to encrypt the spliced string to obtain ciphertext data.
  • the issuer can record its own DID (that is, the issuer DID) in the issuer, record the DID of the certifier 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.
  • 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.
  • 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
  • the second signature is recorded in the proof, for example, in the signaturevalue field of the proof.
  • each set of algorithms includes matching encryption algorithms, proof generation algorithms, and proof verification algorithms.
  • the issuer, prover, and verifier did not pre-negotiate which algorithm based on zero-knowledge proof technology.
  • the issuer 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.
  • 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.
  • Step 326 the issuer returns the original verifiable statement to the prover.
  • 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.
  • step 328 the prover deletes the plaintext private information and random strings in the original verifiable statement to obtain the final verifiable statement.
  • 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.
  • Fig. 4 is a flow chart of another certificate generation method provided by an exemplary embodiment. As shown in Figure 4, this method is applied to the proof generation platform and may include the following steps:
  • Step 402 receiving a first certificate generation request initiated by the prover.
  • the prover instructs the proof generation platform to generate the first certificate through the first certificate generation request; wherein, the first certificate generation request may include the private data of the prover, the judgment conditions for the private data and the first judgment result .
  • the private data can also be uploaded to the certificate generation platform by the prover through other means, and the judgment conditions can also be set by the verifier and uploaded to the certificate generation platform.
  • the proof generation platform can obtain private data during the issuance process.
  • Step 404 if the first judgment result is verified, go to step 406; otherwise, go to step 412.
  • the certificate generation platform since the first certificate generation request is initiated by the prover to instruct the certificate generation platform to generate a correct certificate, the certificate generation platform needs to verify the privacy data and the judgment condition after receiving the first certificate generation request. Whether the relationship among them matches the first judgment result provided by the prover, so as to generate the first proof when the relationship between the private data and the judgment condition matches the first judgment result.
  • the age of user A (private information in plain text) is 25 years old, and the age judgment condition set by the verification party is "18 years of age”. Since 25 years old > 18 years old, the first judgment result is "Yes", That is, user A is over 18 years old.
  • the certificate generation platform After receiving the first certificate generation request, the certificate generation platform needs to verify whether the relationship between "user A's age is 25 years old” and "age over 18 years old” matches the first judgment result "user A's age is over 18 years old” .
  • Step 406 generating a first certificate.
  • the private data of the prover includes plaintext private information and random character strings.
  • the proof generation platform can input plaintext private information, random character strings, judgment conditions and first judgment results into the proof generation algorithm to generate a proof.
  • the proof generation platform 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, judge The condition "age over 18 years old” and the judgment result "yes” are input into the proof generation algorithm to generate the first proof corresponding to the verifiable statement, and the first proof can be used to show that the verifiable statement in the proof verification algorithm
  • the age of the ciphertext data record (user A's age) is over 18 years old.
  • step 408 if a second certificate generation request is received, go to step 410; otherwise, go to step 412.
  • Step 410 generating a corresponding public key according to the private key of the verifier.
  • Step 412 end the certificate generating operation.
  • Step 414 if the generated public key is the same as that of the verifier, then go to step 416; otherwise, go to step 418.
  • the certificate generation platform has opened the right to the verifier to "forge" the certificate corresponding to the verifiable statement held by the verifier, so as long as the verifier initiates a second certificate generation request, it will respond to the second certificate
  • the request is generated to generate the second certificate without verifying whether the relationship between the ciphertext data and the judgment condition matches the second judgment result provided by the verifier.
  • the authority to "forge” the certificate is only open to the verifier, so when the certificate generation platform receives the second certificate generation request, it needs to authenticate the requester of the second certificate generation request.
  • the identity of the verifier can be confirmed through the asymmetric key of the verifier.
  • the verifier can first use an asymmetric encryption algorithm to generate its own private key, then generate the corresponding public key based on the private key, and provide the public key to the certificate generation platform, that is, configure the verifier's public key on the certificate generation platform in advance.
  • the certificate generation platform when it receives the second certificate generation request, it can obtain the private key provided by the requester of the second certificate generation request (for example, included in the second certificate generation request, or provided by other requests), and A corresponding public key is generated according to the private key, so that if the generated public key is the same as that of the verifier, it is determined that the requester is the verifier.
  • asymmetric encryption such as KDF (Key derivation function, key derivation function) algorithm, RSA algorithm, ECC (elliptic curve cryptography, elliptic curve encryption) and DSA (Digital Signature Algorithm, digital signature algorithm) can be used. algorithm; of course, this description does not limit it.
  • the public key of the verifying party can be configured on the proof generation platform in advance, and the requesting party can sign the second proof generation request with its own private key. Then, when the proof generation platform receives the second proof generation request, it can use The verifier's public key verifies the signature of the second certificate generation request, so as to determine that the requester is the verifier if the signature verification is passed.
  • identity verification any other manners for identity verification may also be used, which is not limited in this description.
  • Step 416 generate a second certificate.
  • the proof generation platform is open to the verifier to request the authority to "forge” the certificate corresponding to the verifiable statement held by the prover, and for the verifier to "forge” the certificate and the prover
  • the certificate generated by the request is similar, and can also be used to indicate the relationship between the ciphertext data (corresponding private data) recorded in the corresponding verifiable statement and the judgment condition.
  • the verifier Since the verifier also has the authority to instruct the proof generation platform to generate the proof, the verifier has the possibility of doing evil, that is, for the proof generated by the verifier request and the proof requested by the prover, the ciphertext in the verifiable statement indicated by the two
  • the relationship between data and judgment conditions may be different (of course, they may also be the same).
  • the second judgment result provided by the verifier is "no", that is, under the age of 18.
  • the certificate generation platform can generate a second certificate corresponding to the verifiable statement, and the second certificate can be used to indicate the age of the ciphertext data record in the verifiable statement (the age of user A) under the verification of the certificate verification algorithm Under the age of 18, but the age of the ciphertext data record in the verifiable statement is actually over 18, that is, the verifier "forged" the certificate.
  • the verifier forwards the verifiable statement and the corresponding certificate to other devices, because the verifier has the possibility of "forging” the certificate, other devices cannot determine the authenticity of the certificate obtained from the verifier (it is impossible to determine whether it is consistent with the certificate or not).
  • the first proof provided by the party is the same), then the information "whether the private information of the prover meets the judgment conditions" determined based on the verifiable statement provided by the verifier and the corresponding certificate is not necessarily true and reliable, that is, the authenticity is doubtful.
  • the proof forwarded by the verifier is not credible, then even if the verifier forwards the proof to other devices, other devices will have doubts about the proof forwarded by the verifier, and cannot pass the verifiable statement
  • the information of "whether the private information of the proving party satisfies the judgment conditions" determined by the proof is used as credible private information, thereby reducing the risk of the verifier leaking privacy.
  • Step 418 outputting an authentication failure message.
  • Fig. 5 is an interaction diagram for verifying a prover provided by an exemplary embodiment. As shown in Figure 5, the interaction process may include the following steps:
  • Step 502 the prover creates a verification request (including the prover DID).
  • Step 505 the prover sends a verification request to the verifier.
  • step 506 the verifier verifies the DID of the prover.
  • 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.
  • the verifier 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 508 the prover sends the verifiable statement and the corresponding proof (first proof) to the verifier.
  • the prover needs to prove to the verifier that his private information conforms to the judgment conditions set by the verifier, then he needs to provide the verifier with the VC obtained in the above-mentioned embodiment shown in Figure 3 and the corresponding proof (section a certificate).
  • Step 510 the verifier verifies the verifiable statement.
  • 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.
  • the issuer DID 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 512 the verifier verifies the certificate.
  • 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 judgment condition. Since the first certificate is a correct certificate, the verifier can determine that the relationship between the ciphertext data and the judgment condition matches the first judgment result under the verification of the certificate verification algorithm. 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 514 the verifier determines that the prover passes the verification, and executes relevant business operations for the prover.
  • Step 516 the verifier returns the execution result of the business operation to the prover.
  • the Internet cafe verifier can generate a payment order for user A and return the payment order information to user A's client.
  • this specification also provides an embodiment of a certificate generation device.
  • Fig. 6 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • the device includes a processor 602 , an internal bus 604 , a network interface 606 , a memory 608 and a non-volatile memory 610 , and of course it may also include hardware required by other services.
  • the processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs it, forming a certificate generation device on a logical level.
  • 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.
  • the certificate generation device may include:
  • the acquisition unit 71 is configured to acquire private data of the prover and judgment conditions for the private data, and the statement of the prover includes ciphertext data obtained by encrypting the private data;
  • the first generation unit 72 generates the first certificate when the first certificate generation condition is satisfied, and the first certificate generation condition includes receiving the first certificate generation request for the statement initiated by the certifier and having verified
  • the relationship between the privacy data and the judgment condition matches the first judgment result provided by the prover, and the first certificate is used to show to the verifier that the ciphertext data is consistent with the verifier under the verification of the zero-knowledge proof algorithm.
  • the relationship between the above judgment conditions matches the first judgment result;
  • the second generation unit 73 generates a second certificate when the second certificate generation condition is satisfied, the second certificate generation condition includes receiving a second certificate generation request for the statement initiated by the verifier, and the second certificate It is used to indicate that the relationship between the ciphertext data and the judgment condition matches the second judgment result provided by the verifier under the verification of the zero-knowledge proof algorithm.
  • the verification unit 74 obtains the private key provided by the requesting party of the second certificate generation request, generates a corresponding public key according to the private key, and determines that the The requesting party is the authenticating party.
  • the first return unit 75 returns the first certificate to the prover, so that the prover provides the first certificate to the verifier; or,
  • the statement includes the information of the second certificate generation condition; or, the second certificate generation condition is public information.
  • the statement includes a verifiable statement; the device further includes:
  • the issuing unit 76 in response to the statement issuance request initiated by the certifier, queries the blockchain network for the public key corresponding to the decentralized identifier contained in the statement issuance request;
  • the verification unit 74 is also used for:
  • the private data is encrypted to obtain the ciphertext data, so as to generate the verifiable statement.
  • the privacy data includes plaintext privacy information and random character strings of the prover.
  • the first returning unit 77 returns the second certificate to the verifier in response to the second certificate generation request.
  • 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.
  • a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • 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.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • 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.”

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

本说明书提供一种证明生成方法，包括：获取证明方的隐私数据和判断条件，所述证明方的声明中包含对所述隐私数据进行加密得到的密文数据；在第一证明生成条件被满足的情况下生成第一证明，第一证明生成条件包括接收到所述证明方发起的针对所述声明的第一证明生成请求、且验证过所述隐私数据和所述判断条件之间的关系匹配于所述证明方提供的第一判断结果，第一证明用于表明所述密文数据与所述判断条件之间的关系与第一判断结果相匹配；在接收到所述验证方发起的针对所述声明的第二证明生成请求的情况下生成第二证明，第二证明用于表明所述密文数据与所述判断条件之间的关系与所述验证方提供的第二判断结果相匹配。

Description

证明生成方法及装置、电子设备、存储介质
本申请要求于2022年02月25日提交中国专利局、申请号为202210179222.9、发明名称为“证明生成方法及装置、电子设备、存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本说明书一个或多个实施例涉及数据处理技术领域，尤其涉及一种证明生成方法及装置、电子设备、存储介质。
背景技术
出于对隐私保护的考虑，用户在使用自身隐私数据的同时，也希望隐私数据不被泄露。零知识证明(Zero-Knowledge Proof)或零知识协议包括两部分：宣称某一命题为真的证明者(prover)和确认该命题确实为真的验证者(verifier)；其中，证明者能够在不向验证者提供任何有用的信息的情况下，使验证者相信某个论断是正确的。
零知识证明实质上是一种涉及两方或更多方的协议，即两方或更多方完成一项任务所需采取的一系列步骤。证明者向验证者证明并使其相信自己知道或拥有某一消息，但证明过程不能向验证者泄漏任何关于被证明消息的信息，从而避免了泄露证明者的隐私。
发明内容
有鉴于此，本说明书一个或多个实施例提供一种证明生成方法及装置、电子设备、存储介质。
为实现上述目的，本说明书一个或多个实施例提供技术方案如下：
根据本说明书一个或多个实施例的第一方面，提出了一种证明生成方法，包括：
获取证明方的隐私数据和针对所述隐私数据的判断条件，所述证明方的声明中包含对所述隐私数据进行加密得到的密文数据；
在第一证明生成条件被满足的情况下生成第一证明，第一证明生成条件包括接收到所述证明方发起的针对所述声明的第一证明生成请求、且验证过所述隐私数据和所述判断条件之间的关系匹配于所述证明方提供的第一判断结果，第一证明用于在零知识证明算法的验证下向验证方表明所述密文数据与所述判断条件之间的关系与第一判断结果相匹配；
在第二证明生成条件被满足的情况下生成第二证明，第二证明生成条件包括接收到所述验证方发起的针对所述声明的第二证明生成请求，第二证明用于在零知识证明算法的验证下表明所述密文数据与所述判断条件之间的关系与所述验证方提供的第二判断结果相匹配。
根据本说明书一个或多个实施例的第二方面，提出了一种证明生成装置，包括：
获取单元，获取证明方的隐私数据和针对所述隐私数据的判断条件，所述证明方的声明中包含对所述隐私数据进行加密得到的密文数据；
第一生成单元，在第一证明生成条件被满足的情况下生成第一证明，第一证明生成条件包括接收到所述证明方发起的针对所述声明的第一证明生成请求、且验证过所述隐私数据和所述判断条件之间的关系匹配于所述证明方提供的第一判断结果，第一证明用于在零知识证明算法的验证下向验证方表明所述密文数据与所述判断条件之间的关系与第一判断结果相匹配；
第二生成单元，在第二证明生成条件被满足的情况下生成第二证明，第二证明生成条件包括接收到所述验证方发起的针对所述声明的第二证明生成请求，第二证明用于在零知识证明算法的验证下表明所述密文数据与所述判断条件之间的关系与所述验证方提供的第二判断结果相匹配。
根据本说明书一个或多个实施例的第三方面，提出了一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器通过运行所述可执行指令以实现如第一方面所述的方法。
根据本说明书一个或多个实施例的第四方面，提出了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如第一方面所述方法的步骤。
附图说明
图1是一示例性实施例提供的一种证明生成方法的流程图。
图2是一示例性实施例提供的创建DID的交互图。
图3是一示例性实施例提供的颁发可验证声明的交互图。
图4是一示例性实施例提供的另一种证明生成方法的流程图。
图5是一示例性实施例提供的验证证明方的交互图。
图6是一示例性实施例提供的一种设备的结构示意图。
图7是一示例性实施例提供的一种证明生成装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
请参见图1，图1是一示例性实施例提供的一种证明生成方法的流程图。如图1所示，该方法应用于证明生成平台，可以包括以下步骤：
步骤102，获取证明方的隐私数据和针对所述隐私数据的判断条件，所述证明方的声明中包含对所述隐私数据进行加密得到的密文数据。
在本实施例中，用户作为证明者可在所使用的客户端上登录自身的用户账号，从而使得该客户端作为证明方，验证方和颁发方的概念与此类似。证明方可向颁发方请求颁发记录有证明方真实的隐私信息的声明，颁发方首先对隐私信息进行真实性校验，从而在真实性校验通过后向证明方颁发该声明。换言之，由颁发方作为可信平台为证明方背书，通过颁发声明以表明证明方的隐私信息真实可靠。以VC(Verifiable Claim，可验证声明)为例，可通过DIS(Decentralized Identifier Service，去中心化的身份服务)来为各个用户创建身份。DIS可为用户提供不受任何单一注册中心、身份服务商或者认证中心限制的，完全由用户自身控制的DID(Decentralized Identifier，去中心化身份标识符)。DID可作为一个实体的标识，而对于该实体拥有哪些权限、能力、行为甚至资产等具体信息，则可通过VC来表示。VC是颁发方使用自身的分布式数字身份(DID)给用户的DID的某些属性做背书而签发的描述性声明，并附 加有颁发方的数字签名。那么，用户可通过向其他用户提供自身的VC，从而向该其他用户证明VC中记录的关于自身的属性信息为真实可靠的。
声明中记录有持有该声明的用户的属性信息，而属性信息通常为用户的隐私信息，若声明中记录的隐私信息为明文形式，则用户在向其他用户提供自身的声明时存在暴露隐私信息的风险。因此，可对采用分布式数字身份的用户所持有声明中记录的隐私信息进行保护，从而使得隐私信息“可用不可见”。
具体而言，证明方可向颁发方请求颁发记录有证明方真实的隐私信息的声明，颁发方在向证明方颁发相应的声明时，可对所颁发的声明中记录的隐私信息进行加密处理，从而实现对证明方的隐私保护。同时，可结合零知识证明技术来保证声明中所记录持有者的隐私信息不被泄露的前提下，仍然可用于描述该隐私信息(证明该隐私信息真实有效)，即使得声明中的隐私信息“可用不可见”。
零知识证明技术中包含加密算法、证明生成算法和证明验证算法。其中，加密算法用于对证明方的隐私数据进行加密，由于隐私数据为密文形式，需要采用与该加密算法相匹配的证明生成算法来生成相应的证明，该证明可表明证明方的隐私数据(密文形式)符合针对该隐私数据设定的判断条件(可理解为判断隐私数据是否通过验证的验证通过条件)，而对于该证明，则可通过与上述证明生成算法相匹配的证明验证算法来进行验证，确定该证明表明的内容是否正确。简而言之，在加密隐私数据、生成证明、验证证明的过程中，零知识证明技术包含的上述三类算法之间为相互对应的关系。
举例而言，用户A的隐私数据包含年龄信息，而针对年龄设定的判断条件为“年龄满18周岁”。那么，用户A可向声明的颁发者(比如，民政局、公安机关等可信机构)提供自身的年龄信息，由颁发者在对年龄信息进行真实性校验并校验通过后，向用户A颁发相应的声明，该声明中记录有密文形式的年龄信息。用户A在获取声明后，可针对声明中的年龄信息生成用于表明“年龄满18周岁”的证明，并向验证者(比如，对于所出售商品具有年龄限制的商店)提供声明和证明，以由验证者基于声明和证明来判断用户A是否年满18周岁。其中，用户A、颁发者和验证者之间预先协商确定了各自使用的算法，即用户A使用的证明生成算法、颁发者使用的加密算法和验证者使用的证明验证算法之间互相匹配。
而对于零知识证明技术，可采用同态特性的承诺算法(Commitment)或者同态加密(Homomorphic Encryption)算法等。为了方便描述，以记号HE()表示同态承诺/加密算法，对于明文t，其密文形式为HE(t)。同态承诺/加密是一种特殊的加密方法，允许对密文进行处理得到仍然是加密的结果，即对密文直接进行处理，与对明文进行处理后再对处理结果加密得到的结果相同。以加法同态为例，HE(t1)+HE(t2)＝HE(t1+t2)。同态承诺算法包括Pedersen承诺等，同态加密算法包括Paillier算法、Gentry算法、Okamoto–Uchiyama同态加密和Boneh-Goh-Nissim同态加密等等；当然，本说明书并不对所采用的加密算法进行限制；比如，还可采用哈希算法。相应的，范围证明技术是密码学领域的一种安全的证明协议，可用于证明一个数字在某一合理区间并且不泄露该数字的具体数值等信息。例如，Borromean环签名方案、Bulletproof方案、zkSNARK等零知识证明技术均可用于范围证明。
基于上述同态的特点，以转账为例，出于交易隐私保护的目的，可以通过同态加密或同态承诺技术对交易金额进行保护，以及利用范围证明技术保证交易额非负且账户余额足够支付(通过生成用于表明交易额非负且账户余额足够支付的范围证明)。
在本实施例中，证明生成平台可作为上述颁发方来向证明方颁发包含密文数据的声明。同样以VC为例，证明方采用DID来表明自身的身份，并通过向证明生成平台发起声明颁发请求来指示证明生成平台颁发VC，该声明颁发请求中包含证明方DID。证明生成平台在接收到声明颁发请求后，先对证明方DID进行验证，向区块链网络查询与声明颁发请求包含的DID对应的公钥；然后，向所述证明方发送挑战消息，该挑战消息用于指示证明方使用证明方的私钥对挑战消息中包含的挑战数据进行签名。证明生成平台在获取证明方返回的挑战数据后，使用从区块链网络查询到的公钥对该挑战数据进行签名验证(验签)，以在验签通过的情况下，判定证明方DID为证明方所持有的DID，进而生成包含密文数据和证明方DID中心化标识符的可验证声明，通过在可验证声明中记录证明方DID，使得该证明方DID可表明可验证声明的接收方为上述证明方。
其中，证明生成平台在生成可验证声明之前，可先对证明方的隐私数据进行真实性校验，从而在校 验通过的情况下对隐私数据进行加密得到密文数据，进而生成可验证声明。通过对证明方的隐私数据进行真实性校验，可确保生成的可验证声明真实可靠。
在本实施例中，在对证明方的明文隐私信息进行加密时，可将随机字符串作为掩码来提高加密得到的密文数据的随机性，从而防止密文数据被暴力破解。比如，明文隐私信息为年龄，采用的加密算法为哈希运算，由于年龄的数值范围较小，若直接对年龄进行哈希运算，则生成的密文数据的总数量则相应较少，那么容易被暴力破解，从而泄露用户的年龄隐私。因此，可(由证明方生成并提供至证明生成平台，或者由证明生成平台生成)生成一随机字符串，将该随机字符串与明文隐私信息进行拼接得到隐私数据，然后再对该隐私数据进行加密得到密文数据。换言之，本实施例中的隐私数据包含证明方的明文隐私信息和随机字符串。
进一步的，证明生成平台在向证明方颁发VC之前，可对证明方提供的明文隐私信息进行真实性校验，从而在真实性校验通过的情况下生成原始可验证声明，该原始可验证声明中包含明文隐私信息、随机字符串和密文数据。然后，证明方可获取证明生成平台在验证明文隐私信息通过的情况下生成的原始可验证声明，并删除原始可验证声明中的明文隐私信息和随机字符串以得到可验证声明，该可验证声明则是后续可提供至验证方进行验证的可验证声明。需要说明的是，本说明书并不对上述真实性校验操作的具体方式进行限制。
其中，基于零知识证明技术的加密算法以及相应的证明生成算法和证明验证算法可存在多组，即每组算法包括相互匹配的加密算法、证明生成算法和证明验证算法。或者，证明生成平台、证明方和验证方并未预先协商何种基于零知识证明技术的算法。针对上述情况，证明生成平台在生成原始可验证声明的过程中，在原始可验证声明中记录与自身所采用的加密算法相匹配的证明生成算法和证明验证算法的算法标识，以指示相应的用户采用与算法标识对应的算法。具体而言，可验证声明包含证明生成算法的第一算法标识，第一算法标识用于指示证明方根据第一算法标识确定出相应的证明生成算法；和/或，可验证声明包含证明验证算法的第二算法标识，第二算法标识用于指示验证方根据第二算法标识确定出证明验证算法。
而在证明生成平台生成原始可验证声明的过程中，证明生成平台可对原始可验证声明中区别于明文隐私信息和随机字符串的第一声明内容(包含声明证明生成平台、声明接收方、声明过期时间、声明颁发时间等，下文将详细进行说明)进行签名得到第一签名，并将第一签名记录在原始可验证声明中。换言之，原始可验证声明中包含证明生成平台针对原始可验证声明中第一声明内容的第一签名，证明生成平台通过第一签名为证明方背书。基于原始可验证声明中包含证明生成平台的第一签名，那么验证方判定证明方验证通过的前提条件包括与可验证声明对应的证明验证通过且第一签名验证通过。
除此之外，证明生成平台可对原始可验证声明中的第二声明内容(至少包括明文隐私信息和随机字符串)进行签名得到第二签名，并将第二签名记录在原始可验证声明中，即原始可验证声明中包含证明生成平台针对原始可验证声明中第二声明内容的第二签名。那么，证明方在获取到原始可验证声明后，可对原始可验证声明中包含的第二签名进行签名验证，以在第二签名验证通过的情况下(表明该原始可验证声明由证明生成平台生成并且未被篡改)生成上述可验证声明。
在本实施例中，证明生成平台在生成可验证声明后，还可用于响应证明生成请求来生成相应的证明，因此证明方可向证明生成平台提供相关数据(比如记录于证明生成请求中，或者通过区别于证明生成请求的其他请求来提供)，以指示证明生成平台生成用于表明证明方所持有声明中记录的隐私数据满足一定条件的证明。具体而言，证明生成平台可将隐私数据、判断条件(可由验证方设定或提供)以及用于表明该隐私数据符合判断条件的判断结果输入证明生成算法以生成对应于可验证声明的证明，该证明用于表明该可验证声明中记录的密文数据符合判断条件。
承接于上述举例，用户A的年龄为25岁，验证方针对年龄设定的判断条件为“年龄满18周岁”，由于25岁>18岁，判断结果为“是”，即判断结果为用户A的年龄符合判断条件“年龄满18周岁”。因此，证明生成平台可将“用户A的年龄25岁”、“年龄满18周岁”以及判断结果为“是”输入证明生成算法，以生成对应于可验证声明的证明。
步骤104，在第一证明生成条件被满足的情况下生成第一证明，第一证明生成条件包括接收到所述证明方发起的针对所述声明的第一证明生成请求、且验证过所述隐私数据和所述判断条件之间的关系匹配于所述证明方提供的第一判断结果，第一证明用于在零知识证明算法的验证下向验证方表明所述密文数据与所述判断条件之间的关系与第一判断结果相匹配。
在本实施例中，基于上述生成可验证声明和相应证明的方式，证明方可向验证方提供可验证声明和相应的证明，由验证方根据该证明来判断可验证声明中记录的密文数据与判断条件之间的关系是否与判断结果相匹配，即判断可验证声明中记录的密文数据是否满足判断条件。可见，通过证明方持有的可验证声明和相应的证明可以确定出证明方的隐私信息是否满足一定条件，即可验证声明和相应的证明体现了“证明方的隐私信息是否满足一定条件”这一信息，而该信息同样属于证明方的隐私，同时可验证声明和相应的证明存在被验证方转发至其他用户的可能，那么其他用户也就可能获取该隐私，导致证明方的隐私泄露。
下面以用户的角度进行举例说明，证明者通常只希望指定的验证者来验证可验证声明和相应的证明，而不希望该验证者将声明和证明泄漏。比如，证明者a持有的可验证声明和相应的证明共同表明“证明者a的年龄大于18周岁”，同时证明者a只希望目标商户b验证通过后进行后续交易。在该情况下，当目标商户b获取证明者a的可验证声明和相应证明后，目标商户b可以将可验证声明和相应证明转发至商户c，那么商户c通过可验证声明和相应证明也可以获取“证明者a的年龄大于18周岁”这一信息(该信息真实可靠)，也就意味着目标商户b泄露了证明者a的隐私。
针对上述验证方存在泄露证明方隐私的问题，本说明书在上述证明生成方案的基础上，进一步向验证方开放可请求“伪造”与证明方持有的可验证声明对应的证明的权限，并且为验证方“伪造”的证明与证明方请求生成的证明类似，同样可用于表明相应的可验证声明中记录的密文数据(对应的隐私数据)与判断条件之间的关系。由于验证方也具备指示证明生成平台生成证明的权限，那么，验证方存在作恶的可能，即对于验证方请求生成的证明与证明方请求生成的证明，两者所表明的可验证声明中密文数据与判断条件之间的关系可能不同(当然，也可能相同)。比如，证明方请求生成的证明用于表明密文数据与判断条件之间的关系与第一判断结果相匹配，验证方请求生成的证明用于表明密文数据与判断条件之间的关系与第二判断结果相匹配，若验证方设定的第二判断结果与第一判断结果不一致，则说明验证方“伪造”了证明。
那么，当验证方向其他设备转发可验证声明和相应的证明时，由于验证方具备“伪造”证明的可能，导致其他设备无法确定从验证方处获取到的证明的真实性(无法确定是否与证明方提供的第一证明相同)，那么根据验证方提供的可验证声明和相应证明确定出的“证明方的隐私信息是否满足判断条件”这一信息也就不一定真实可靠，即真实性存疑。通过上述向验证方开发伪造证明权限的方式，使得验证方无法保证转发至其他设备的证明的真实性，即验证方转发的证明不可信，从而降低了验证方泄露隐私的风险。
为了便于描述，本说明书将证明方向证明生成平台发起的证明生成请求称为第一证明生成请求，将验证方向证明生成平台发起的证明生成请求称为第二证明生成请求。相应的，证明生成平台响应于第一证明生成请求而生成的证明称为第一证明，证明生成平台响应于第二证明生成请求而生成的证明称为第二证明。当然，上述“第一”、“第二”的描述仅用于将证明方和验证方发起的证明生成请求区分开；比如，还可将证明方向证明生成平台发起的证明生成请求称为第二证明生成请求，将验证方向证明生成平台发起的证明生成请求称为第一证明生成请求，本说明书并不对此进行限制。
需要注意的是，第一证明生成请求由证明方发起，用于指示证明生成平台生成正确的证明，因此证明生成平台在接收到第一证明生成请求后，需验证隐私数据和判断条件之间的关系是否匹配于证明方提供的第一判断结果，以在隐私数据和判断条件之间的关系匹配于第一判断结果的情况下生成第一证明。而对于验证方发起的第二证明生成请求，由于向验证方开放了“伪造”与证明方持有的可验证声明对应的证明的权限，无需验证密文数据与判断条件之间的关系是否与验证方提供的第二判断结果相匹配。因此，证明生成平台在接收到验证方发起的第二证明生成请求的情况下，直接生成第二证明即可。
步骤106，在第二证明生成条件被满足的情况下生成第二证明，第二证明生成条件包括接收到所述验证方发起的针对所述声明的第二证明生成请求，第二证明用于在零知识证明算法的验证下表明所述密文数据与所述判断条件之间的关系与所述验证方提供的第二判断结果相匹配。
在本实施例中，证明生成平台在生成第二证明之后，可响应于第二证明生成请求，向验证方返回第二证明，使得验证方持有自身请求生成的证明。
在本实施例中，“伪造”证明的权限仅对验证方开放，因此证明生成平台在接收到第二证明生成请求时，需对第二证明生成请求的请求方进行身份验证。其中，可通过验证方的非对称密钥来确认验证方的身份。比如，预先在证明生成平台配置验证方的公钥，在接收到第二证明生成请求的情况下，可获取第二证明生成请求的请求方提供的私钥(比如，包含于第二证明生成请求，或者通过其他请求提供)，并根据该私钥生成相应的公钥，从而在生成的公钥与验证方的公钥相同的情况下，确定请求方为验证方。
在本实施例中，证明生成平台可向证明方返回第一证明，以由证明方将第一证明提供至验证方，那么验证方可根据证明方的可验证声明和第一证明完成验证过程。或者，证明生成平台可获取证明方提供的验证方的接收地址，并将第一证明发送至该接收地址，以使验证方获得第一证明，进而根据证明方的可验证声明和第一证明完成验证过程。
在本实施例中，为了使得除验证方以外的其他设备的使用者充分知悉验证方具备“伪造”证明的权限，从而质疑验证方所提供证明的真实性，可在证明方的声明中记录上述第二证明生成条件的信息，或者将第二证明生成条件设定为公开信息。比如，可在证明方的声明中记录第二证明生成条件的标识，那么其他设备可通过该标识查询第二证明生成条件以供使用者进行查看；或者，直接在证明方的声明中记录第二证明生成条件的内容。又如，可将第二证明生成条件的内容公布在官方网站中以供公众查看。当然，本说明书并不对如何公布第二证明生成条件的具体实现方式进行限制。
为了便于理解，下面结合附图2-5对本说明书的技术方案进行详细说明。
图2是一示例性实施例提供的创建DID的交互图。如图2所示，该交互过程可以包括以下步骤：
步骤202，证明方创建DID、对应于DID的密钥对和相应的DID文档。
在本实施例中，用户作为证明者可在所使用的客户端上登录自身的用户账号，从而使得该客户端作为证明方。其中，可通过DIS(Decentralized Identifier Service，去中心化的身份服务)来为各个用户创建身份，DIS可为用户提供不受任何单一注册中心、身份服务商或者认证中心限制的，完全由用户自身控制的DID(Decentralized Identifier，去中心化身份标识符)。以为证明方创建DID为例，与证明方DID对应的密钥对包括公钥和私钥，公钥需发布至区块链进行存证，而与证明方DID对应的私钥则由证明方保管，比如保存于上述客户端本地。
在DIS系统中，一个DID(Decentralized Identifier，去中心化身份标识符)对应一个实体(比如，VC的颁发者、证明者、验证者等用户)，而针对该DID的具体使用方式，则由与该DID对应的DID文档(DID Document)描述。DID文档用于描述如何使用相应的DID，至少包含相应DID的公钥；除此之外，还可记录加密方式、证明目的、验证方法和服务端等信息。其中，证明目的与验证方法相结合，以提供证明事物的机制。例如，DID文档可以指定特定的验证方法，例如密码公钥或化名生物特征协议，可以用于验证为目的而创建的方法。服务端点支持与DID控制器的可信交互。DID和DID文档可直接登记在区块链或其他分布式网络上，而无需向中心化注册机构申请，通过利用区块链等分布式网络技术的不可篡改、哈希加密等特性，可实现让数字身份真正为用户所拥有并支配，而不再有任何中间人(即使是DID技术供应商)接触拥有控制用户的身份和数据。
步骤204，证明方创建一笔用于存证DID和DID文档的交易。
步骤206，证明方向区块链网络提交该用于存证DID和DID文档的交易。
步骤208，区块链网络在区块链上存证DID和DID文档。
步骤210，证明方向区块链网络获取创建DID成功的回执。
在本实施例中，区块链网络在存证DID和DID文档之后，可生成用于记存证DID和DID文档成功的事件，并存储到区块链日志中。那么，证明方可通过区块链的回调机制来获取该事件，从而确定出在 区块链上已存证DID和DID文档，也即证明方创建DID成功。或者，还可生成相应的提示消息以供证明方查看，以告知证明方链上创建DID成功。
图3是一示例性实施例提供的颁发可验证声明的交互图。如图3所示，该交互过程可以包括以下步骤：
步骤302，证明方创建声明颁发请求(包含证明方DID、明文隐私信息和证明者的身份信息)。
步骤304，证明方向颁发方发送声明颁发请求。
步骤306，颁发方读取声明颁发请求中包含的证明方DID。
步骤308，颁发方向区块链网络发起针对证明方DID的查询交易。
步骤310，区块链网络响应于查询交易，查询与证明方DID对应的DID文档。
步骤312，区块链网络向颁发方返回查询到的DID文档。
步骤314，颁发方向证明方发送DID认证挑战消息(包含挑战数据)。
在本实施例中，由上述图2创建DID的过程可知，证明方DID的DID文档中记录有与证明方DID对应的公钥，那么可利用该公钥来验证声明颁发请求中的证明方DID是否为证明方实际持有的DID，也即验证证明方是否为声明颁发请求中证明方DID的合法owner。
颁发方可随机生成一挑战数据(比如为字符串)，并将该挑战数据通过DID认证挑战消息(DID auth challenge)发送至证明方，以指示证明方通过自身的私钥(即与证明方DID对应的私钥)对其进行签名，并返回挑战数据和签名。那么，颁发方可采用DID文档中的公钥对签名进行签名验证，进而在签名验证通过的情况下，确认证明方为声明颁发请求中记录的证明方DID的合法owner。
步骤316，证明方通过与证明方DID对应的私钥对挑战数据进行签名。
步骤318，证明方向颁发方返回挑战数据。
步骤320，颁发方采用DID文档中的公钥进行签名验证。
在本实施例中，除上述通过发送DID认证挑战消息的方式以外，还可采用在声明颁发请求中添加签名的方式。具体而言，证明方在创建的声明颁发请求中添加针对声明颁发请求中内容的签名，颁发方可在获取到DID文档后，采用DID文档中记录的公钥对声明颁发请求中的签名进行签名验证，从而确认证明方为声明颁发请求中记录的证明方DID的合法owner。
步骤322，颁发方在签名验证通过的情况下对明文隐私信息进行真实性校验。
在本实施例中，在创建声明颁发请求时，可在声明颁发请求中记录证明者的身份信息以作为颁发方对明文隐私信息进行真实性校验的依据。那么，在完成对证明方DID的验证后，可进一步根据声明颁发请求中记录的证明者的身份信息，对明文隐私信息进行真实性校验。例如，证明者的身份信息可包括证明者的身份证号码、籍贯、出生年月、户口信息等，那么颁发方(比如民政局或者公安机关)可根据上述身份信息对证明者的年龄进行真实性校验。
步骤324，颁发方在校验通过的情况下，采用加密算法对明文隐私信息和随机字符串加密得到密文数据，生成针对密文数据的原始可验证声明。
在本实施例中，DID是一个实体的标识，而该实体拥有哪些权限、能力、行为和资产等具体信息，则通过VC来表达。需要注意的是，一个DID可以拥有一个或多个VC。比如，VC中可包含以下字段：
issuer：声明颁发者(颁发方)；
subject：声明接收者(颁发对象)的DID；
expire：声明过期时间；
issuance date：声明颁发时间；
claim：声明内容；
proof：有效性证明(区别于上述证明方生成的证明)。
颁发方可生成一随机字符串(或者由证明方生成并提供至颁发方)，然后与明文隐私信息进行拼接，以采用加密算法对拼接后的字符串进行加密得到密文数据。其中，颁发方可在issuer中记录自身的DID(即颁发方DID)，在didsubject中记录证明方DID，在expire中记录声明过期时间，在issuance date 中记录颁发VC的时刻，在claim中记录明文隐私信息、随机字符串和密文数据。具体而言，可将claim字段扩展为进一步包含plaintext、random和commitment。plaintext用于记录明文隐私信息，比如age；random用于记录随机字符串，commitment用于记录密文数据。
而为了证明VC是由颁发方所颁发的，一方面，颁发方可采用自身的私钥对该VC中除明文隐私信息和随机字符串以外的其他声明内容(即第一声明内容，包含密文数据)进行签名得到第一签名，并将第一签名记录在proof中，比如记录于proof的zkpsignaturevalue字段中；另一方面，颁发方可采用自身的私钥对至少包括明文隐私信息和随机字符串的声明内容(即第二声明内容)进行签名得到第二签名，并将第二签名记录在proof中，比如记录于proof的signaturevalue字段中。
举例而言，原始可验证声明的内容如下：
Figure PCTCN2022135645-appb-000001
除此之外，基于零知识证明技术的加密算法以及相应的证明生成算法和证明验证算法可存在多组，即每组算法包括相互匹配的加密算法、证明生成算法和证明验证算法。或者，颁发方、证明方和验证方并未预先协商何种基于零知识证明技术的算法。针对上述情况，颁发方在生成原始可验证声明的过程中，可在原始可验证声明中记录与自身所采用的加密算法相匹配的证明生成算法和证明验证算法的算法标识，以指示相应的用户采用与算法标识对应的算法。当然，若颁发方、证明方和验证方之间预先协商了采用何种基于零知识证明技术的算法，在无需记录上述算法标识。
需要说明的是，上述针对VC中所包含字段的描述，仅仅为一举例，在实际应用中可根据实际情况灵活调整。
步骤326，颁发方向证明方返回原始可验证声明。
在本实施例中，证明方在获取原始可验证声明后，可分别对第一签名和第二签名进行签名验证，从而在签名验证均通过的情况下执行后续步骤。
步骤328，证明方删除原始可验证声明中的明文隐私信息和随机字符串，得到最终的可验证声明。
在本实施例中，为了保证VC中所记录持有者的隐私信息不被泄露的前提下，仍然可用于描述该隐私信息(证明该隐私信息真实有效)，可将从颁发方处获取到的VC中的plaintext字段和random字段删除(也可将第二签名删除)，从而得到最终可使用的VC。
承接于上述举例，最终的可验证声明的内容如下：
Figure PCTCN2022135645-appb-000002
图4是一示例性实施例提供的另一种证明生成方法的流程图。如图4所示，该方法应用于证明生成平台，可以包括以下步骤：
步骤402，接收证明方发起的第一证明生成请求。
在本实施例中，证明方通过第一证明生成请求指示证明生成平台生成第一证明；其中，第一证明生成请求中可包含证明方的隐私数据、针对隐私数据的判断条件和第一判断结果。当然，隐私数据还可由证明方通过其他途径上传至证明生成平台，判断条件还可由验证方设定并上传至证明生成平台。比如，在由证明生成平台向证明方颁发可验证声明的情况下，在颁发过程中证明生成平台可获取到隐私数据。
步骤404，若第一判断结果验证通过，则转入步骤406；否则，转入步骤412。
在本实施例中，由于第一证明生成请求由证明方发起，用于指示证明生成平台生成正确的证明，因此证明生成平台在接收到第一证明生成请求后，需验证隐私数据和判断条件之间的关系是否匹配于证明方提供的第一判断结果，以在隐私数据和判断条件之间的关系匹配于第一判断结果的情况下生成第一证明。
举例而言，用户A的年龄(明文隐私信息)为25岁，验证方针对年龄设定的判断条件为“年龄满18周岁”，由于25岁>18岁，第一判断结果为“是”，即用户A的年龄满18周岁。证明生成平台在接收到第一证明生成请求后，需验证“用户A的年龄25岁”和“年龄满18周岁”之间的关系是否匹配于第一判断结果“用户A的年龄满18周岁”。
步骤406，生成第一证明。
承接于上述图3示出的实施例，证明方的隐私数据包含明文隐私信息和随机字符串。证明生成平台可将明文隐私信息、随机字符串、判断条件和第一判断结果输入证明生成算法生成证明。例如，随机字 符串为h@$fwehdu，证明生成平台可先将明文隐私信息“用户A的年龄25岁”和随机字符串“h@$fwehdu”进行拼接，再将拼接得到的字符串、判断条件“年龄满18周岁”以及判断结果“是”输入证明生成算法，以生成对应于可验证声明的第一证明，该第一证明可用于在证明验证算法的验证下表明该可验证声明中的密文数据记录的年龄(用户A的年龄)满18周岁。
步骤408，若接收到第二证明生成请求，则转入步骤410；否则，转入步骤412。
步骤410，根据验证方的私钥生成相应的公钥。
步骤412，结束证明生成操作。
步骤414，若生成的公钥与验证方的公钥相同，则转入步骤416；否则，转入步骤418。
在本实施例中，证明生成平台向验证方开放了“伪造”与证明方持有的可验证声明对应的证明的权限，那么只要验证方发起第二证明生成请求，就响应于该第二证明生成请求而生成第二证明，无需验证密文数据与判断条件之间的关系是否与验证方提供的第二判断结果相匹配。
“伪造”证明的权限仅对验证方开放，因此证明生成平台在接收到第二证明生成请求时，需对第二证明生成请求的请求方进行身份验证。其中，可通过验证方的非对称密钥来确认验证方的身份。比如，验证方可先采用非对称加密算法生成自身的私钥，然后根据私钥生成相应的公钥，并向证明生成平台提供该公钥，即预先在证明生成平台配置验证方的公钥。那么，证明生成平台在接收到第二证明生成请求的情况下，可获取第二证明生成请求的请求方提供的私钥(比如，包含于第二证明生成请求，或者通过其他请求提供)，并根据该私钥生成相应的公钥，从而在生成的公钥与验证方的公钥相同的情况下，确定请求方为验证方。其中，可采用KDF(Key derivation function，密钥推导函数)算法、RSA算法、ECC(椭圆曲线密码学(elliptic curve cryptography，椭圆曲线加密)和DSA(Digital Signature Algorithm，数字签名算法)等非对称加密算法；当然，本说明书并不对此进行限制。
又如，可预先在证明生成平台配置验证方的公钥，请求方通过自身的私钥对第二证明生成请求进行签名，那么证明生成平台在接收到第二证明生成请求的情况下，可采用验证方的公钥对第二证明生成请求的签名进行验签，以在验签通过的情况下确定请求方为验证方。当然，还可采用其他任意用于身份验证的方式，本说明书并不对此进行限制。
步骤416，生成第二证明。
针对验证方存在泄露证明方隐私的问题，证明生成平台向验证方开放可请求“伪造”与证明方持有的可验证声明对应的证明的权限，并且为验证方“伪造”的证明与证明方请求生成的证明类似，同样可用于表明相应的可验证声明中记录的密文数据(对应的隐私数据)与判断条件之间的关系。由于验证方也具备指示证明生成平台生成证明的权限，那么，验证方存在作恶的可能，即对于验证方请求生成的证明与证明方请求生成的证明，两者所表明的可验证声明中密文数据与判断条件之间的关系可能不同(当然，也可能相同)。
承接于上述举例，验证方提供的第二判断结果为“否”，即未满18周岁。进一步的，证明生成平台可生成对应于可验证声明的第二证明，该第二证明可用于在证明验证算法的验证下表明该可验证声明中的密文数据记录的年龄(用户A的年龄)未满18周岁，而实际上可验证声明中的密文数据记录的年龄满18周岁，即验证方“伪造”了证明。
那么，当验证方向其他设备转发可验证声明和相应的证明时，由于验证方具备“伪造”证明的可能，导致其他设备无法确定从验证方处获取到的证明的真实性(无法确定是否与证明方提供的第一证明相同)，那么根据验证方提供的可验证声明和相应证明确定出的“证明方的隐私信息是否满足判断条件”这一信息也就不一定真实可靠，即真实性存疑。通过上述向验证方开发伪造证明权限的方式，使得验证方转发的证明不可信，那么即便验证方将证明转发至其他设备，其他设备也对验证方转发的证明存在质疑，无法将根据可验证声明和该证明确定出的“证明方的隐私信息是否满足判断条件”这一信息作为可信的隐私信息来使用，从而降低了验证方泄露隐私的风险。
步骤418，输出身份验证失败消息。
图5是一示例性实施例提供的验证证明方的交互图。如图5所示，该交互过程可以包括以下步骤：
步骤502，证明方创建验证请求(包含证明方DID)。
步骤505，证明方向验证方发送验证请求。
步骤506，验证方验证证明方DID。
基于证明方通过DID来表示自身的身份标识，证明方需要向验证方提供证明方DID，以由验证方验证证明方DID，即验证证明方为所提供的证明方DID的合法owner。其中，验证证明方DID的过程可参考上述图3中的步骤308-320，在此不再赘述。
步骤508，证明方向验证方发送可验证声明和相应的证明(第一证明)。
在本实施例中，证明方需要向验证方证明自身的隐私信息符合验证方设定的判断条件，那么需要向验证方提供上述图3示出实施例中获取到的VC和相应的证明(第一证明)。
步骤510，验证方验证可验证声明。
在本实施例中，验证方可通过颁发方的公钥来对可验证声明中的第一签名进行签名验证，从而验证可验证声明的数据完整性(是否被篡改)以及是否由颁发方颁发。其中，由于可验证声明的issuer字段中记录有颁发方DID，可根据颁发方DID向区块链网络查询颁发方公钥，具体过程与上述步骤306-312类似，在此不再赘述。
步骤512，验证方验证证明。
在本实施例中，验证方可通过证明验证算法和证明来对可验证声明中的密文数据进行验证，确定该密文数据是否符合判断条件。由于第一证明为正确的证明，那么验证方可在证明验证算法的验证下确定出该密文数据与判断条件之间的关系与第一判断结果相匹配。其中，在证明验证通过且第一签名验证通过的情况下，可判定证明方验证通过。
步骤514，验证方判定证明方验证通过，执行针对证明方的相关业务操作。
步骤516，验证方向证明方返回业务操作的执行结果。
以网吧验证用户A是否年满18周岁为例，在判定用户A验证通过后，网吧的验证方可为用户A生成支付订单，并向用户A的客户端返回支付订单的信息。
与上述方法实施例相对应，本说明书还提供了一种证明生成装置的实施例。
图6是一示例性实施例提供的一种设备的示意结构图。请参考图6，在硬件层面，该设备包括处理器602、内部总线604、网络接口606、内存608以及非易失性存储器610，当然还可能包括其他业务所需要的硬件。处理器602从非易失性存储器610中读取对应的计算机程序到内存608中然后运行，在逻辑层面上形成证明生成装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图7，在一软件实施方式中，该证明生成装置可以包括：
获取单元71，获取证明方的隐私数据和针对所述隐私数据的判断条件，所述证明方的声明中包含对所述隐私数据进行加密得到的密文数据；
第一生成单元72，在第一证明生成条件被满足的情况下生成第一证明，第一证明生成条件包括接收到所述证明方发起的针对所述声明的第一证明生成请求、且验证过所述隐私数据和所述判断条件之间的关系匹配于所述证明方提供的第一判断结果，第一证明用于在零知识证明算法的验证下向验证方表明所述密文数据与所述判断条件之间的关系与第一判断结果相匹配；
第二生成单元73，在第二证明生成条件被满足的情况下生成第二证明，第二证明生成条件包括接收到所述验证方发起的针对所述声明的第二证明生成请求，第二证明用于在零知识证明算法的验证下表明所述密文数据与所述判断条件之间的关系与所述验证方提供的第二判断结果相匹配。
可选的，还包括：
校验单元74，获取第二证明生成请求的请求方提供的私钥，并根据所述私钥生成相应的公钥，在生成的公钥与验证方的公钥相同的情况下，确定所述请求方为所述验证方。
可选的，还包括：
第一返回单元75，向所述证明方返回第一证明，以由所述证明方将第一证明提供至所述验证方；或者，
获取所述证明方提供的所述验证方的接收地址，并将第一证明发送至所述接收地址，以使所述验证方获得第一证明。
可选的，
所述声明中包含第二证明生成条件的信息；或者，第二证明生成条件为公开信息。
可选的，所述声明包括可验证声明；所述装置还包括：
颁发单元76，响应于所述证明方发起的声明颁发请求，向区块链网络查询与所述声明颁发请求包含的去中心化标识符对应的公钥；
向所述证明方发送挑战消息，所述挑战消息用于指示所述证明方使用所述证明方的私钥对所述挑战消息中包含的挑战数据进行签名；
在使用查询到的公钥对所述证明方返回的挑战数据验签通过的情况下，生成包含所述密文数据和所述去中心化标识符的可验证声明，所述去中心化标识符用于表明所述可验证声明的接收方为所述证明方。
可选的，校验单元74还用于：
对所述证明方的隐私数据进行真实性校验；
在校验通过的情况下对所述隐私数据进行加密得到所述密文数据，以生成所述可验证声明。
可选的，所述隐私数据包含所述证明方的明文隐私信息和随机字符串。
可选的，还包括：
第一返回单元77，响应于第二证明生成请求，向所述验证方返回第二证明。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明 书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (11)

  1. 一种证明生成方法，包括：
    获取证明方的隐私数据和针对所述隐私数据的判断条件，所述证明方的声明中包含对所述隐私数据进行加密得到的密文数据；
    在第一证明生成条件被满足的情况下生成第一证明，第一证明生成条件包括接收到所述证明方发起的针对所述声明的第一证明生成请求、且验证过所述隐私数据和所述判断条件之间的关系匹配于所述证明方提供的第一判断结果，第一证明用于在零知识证明算法的验证下向验证方表明所述密文数据与所述判断条件之间的关系与第一判断结果相匹配；
    在第二证明生成条件被满足的情况下生成第二证明，第二证明生成条件包括接收到所述验证方发起的针对所述声明的第二证明生成请求，第二证明用于在零知识证明算法的验证下表明所述密文数据与所述判断条件之间的关系与所述验证方提供的第二判断结果相匹配。
  2. 根据权利要求1所述的方法，还包括：
    获取第二证明生成请求的请求方提供的私钥，并根据所述私钥生成相应的公钥；
    在生成的公钥与验证方的公钥相同的情况下，确定所述请求方为所述验证方。
  3. 根据权利要求1所述的方法，还包括：
    向所述证明方返回第一证明，以由所述证明方将第一证明提供至所述验证方；或者，
    获取所述证明方提供的所述验证方的接收地址，并将第一证明发送至所述接收地址，以使所述验证方获得第一证明。
  4. 根据权利要求1所述的方法，
    所述声明中包含第二证明生成条件的信息；或者，第二证明生成条件为公开信息。
  5. 根据权利要求1所述的方法，所述声明包括可验证声明；所述方法还包括：
    响应于所述证明方发起的声明颁发请求，向区块链网络查询与所述声明颁发请求包含的去中心化标识符对应的公钥；
    向所述证明方发送挑战消息，所述挑战消息用于指示所述证明方使用所述证明方的私钥对所述挑战消息中包含的挑战数据进行签名；
    在使用查询到的公钥对所述证明方返回的挑战数据验签通过的情况下，生成包含所述密文数据和所述去中心化标识符的可验证声明，所述去中心化标识符用于表明所述可验证声明的接收方为所述证明方。
  6. 根据权利要求5所述的方法，还包括：
    对所述证明方的隐私数据进行真实性校验；
    在校验通过的情况下对所述隐私数据进行加密得到所述密文数据，以生成所述可验证声明。
  7. 根据权利要求1所述的方法，所述隐私数据包含所述证明方的明文隐私信息和随机字符串。
  8. 根据权利要求1所述的方法，还包括：
    响应于第二证明生成请求，向所述验证方返回第二证明。
  9. 一种证明生成装置，包括：
    获取单元，获取证明方的隐私数据和针对所述隐私数据的判断条件，所述证明方的声明中包含对所 述隐私数据进行加密得到的密文数据；
    第一生成单元，在第一证明生成条件被满足的情况下生成第一证明，第一证明生成条件包括接收到所述证明方发起的针对所述声明的第一证明生成请求、且验证过所述隐私数据和所述判断条件之间的关系匹配于所述证明方提供的第一判断结果，第一证明用于在零知识证明算法的验证下向验证方表明所述密文数据与所述判断条件之间的关系与第一判断结果相匹配；
    第二生成单元，在第二证明生成条件被满足的情况下生成第二证明，第二证明生成条件包括接收到所述验证方发起的针对所述声明的第二证明生成请求，第二证明用于在零知识证明算法的验证下表明所述密文数据与所述判断条件之间的关系与所述验证方提供的第二判断结果相匹配。
  10. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-8中任一项所述的方法。
  11. 一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求1-8中任一项所述方法的步骤。
PCT/CN2022/135645 2022-02-25 2022-11-30 证明生成方法及装置、电子设备、存储介质 WO2023160097A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210179222.9 2022-02-25
CN202210179222.9A CN114389810A (zh) 2022-02-25 2022-02-25 证明生成方法及装置、电子设备、存储介质

Publications (1)

Publication Number Publication Date
WO2023160097A1 true WO2023160097A1 (zh) 2023-08-31

Family

ID=81205631

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135645 WO2023160097A1 (zh) 2022-02-25 2022-11-30 证明生成方法及装置、电子设备、存储介质

Country Status (2)

Country Link
CN (1) CN114389810A (zh)
WO (1) WO2023160097A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117454437A (zh) * 2023-12-22 2024-01-26 北京天润基业科技发展股份有限公司 交易处理方法、存储介质及电子设备

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114389810A (zh) * 2022-02-25 2022-04-22 蚂蚁区块链科技(上海)有限公司 证明生成方法及装置、电子设备、存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108830107A (zh) * 2018-06-25 2018-11-16 北京奇虎科技有限公司 保护隐私信息的方法、装置、电子设备及计算机可读存储介质
CN110224837A (zh) * 2019-06-06 2019-09-10 西安纸贵互联网科技有限公司 基于分布式身份标识的零知识证明方法及终端
CN112347516A (zh) * 2020-11-27 2021-02-09 网易（杭州）网络有限公司 基于区块链的资产证明方法及装置
WO2021090764A1 (ja) * 2019-11-05 2021-05-14 ソニー株式会社 生成装置、生成方法、及び検証装置
CN114389810A (zh) * 2022-02-25 2022-04-22 蚂蚁区块链科技(上海)有限公司 证明生成方法及装置、电子设备、存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111898153B (zh) * 2020-03-18 2024-05-03 支付宝(杭州)信息技术有限公司 调用合约的方法及装置
CN112733163B (zh) * 2021-01-04 2023-02-03 北京航空航天大学 基于离散对数相等性证明的可监管零知识证明方法及装置
CN113364597A (zh) * 2021-05-31 2021-09-07 中国工商银行股份有限公司 一种基于区块链的隐私信息证明方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108830107A (zh) * 2018-06-25 2018-11-16 北京奇虎科技有限公司 保护隐私信息的方法、装置、电子设备及计算机可读存储介质
CN110224837A (zh) * 2019-06-06 2019-09-10 西安纸贵互联网科技有限公司 基于分布式身份标识的零知识证明方法及终端
WO2021090764A1 (ja) * 2019-11-05 2021-05-14 ソニー株式会社 生成装置、生成方法、及び検証装置
CN112347516A (zh) * 2020-11-27 2021-02-09 网易（杭州）网络有限公司 基于区块链的资产证明方法及装置
CN114389810A (zh) * 2022-02-25 2022-04-22 蚂蚁区块链科技(上海)有限公司 证明生成方法及装置、电子设备、存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117454437A (zh) * 2023-12-22 2024-01-26 北京天润基业科技发展股份有限公司 交易处理方法、存储介质及电子设备
CN117454437B (zh) * 2023-12-22 2024-03-22 北京天润基业科技发展股份有限公司 交易处理方法、存储介质及电子设备

Also Published As

Publication number Publication date
CN114389810A (zh) 2022-04-22

Similar Documents

Publication Publication Date Title
JP7181539B2 (ja) 利用者識別認証データを管理する方法および装置
US20210351931A1 (en) System and method for securely processing an electronic identity
CN109359974B (zh) 区块链交易方法及装置、电子设备
TWI786282B (zh) 區塊鏈交易方法及裝置、電子設備
US10079682B2 (en) Method for managing a trusted identity
TWI719435B (zh) 安全多方計算協定的輸入獲取方法和裝置
CN109559224B (zh) 征信评估方法及装置、电子设备
US10505741B1 (en) Cryptographically provable data certification and provenance
WO2020119258A1 (zh) 一种数据处理方法和装置
WO2023160097A1 (zh) 证明生成方法及装置、电子设备、存储介质
AU2017225928A1 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
WO2023160090A1 (zh) 证明生成方法及装置、电子设备、存储介质
CN111768304A (zh) 区块链交易方法及装置、电子设备
KR20210040078A (ko) 안전한 보관 서비스를 위한 시스템 및 방법
US20230269093A1 (en) System and method for providing a verified privacy-preserving attestation of web service data properties
WO2020211481A1 (zh) 用于生成区块链授权信息的方法、装置及系统
WO2022006291A1 (en) Systems/protocol for creating an interconnected web of strong identities
JP2023087665A (ja) システム、方法、およびコンピュータプログラム製品（許可型ブロックチェーンのためのマルチ発行者匿名クレデンシャル）
US20230298015A1 (en) Systems and methods for verification of protected private information
WO2023131147A1 (en) Method and apparatus for generating certified user data
CN116975936B (zh) 金融资质证明方法、金融资质验证方法
US20240031341A1 (en) Methods, devices and system related to a distributed ledger and user identity attribute
JP2022104875A (ja) 否認可能な証明書
Moniava et al. Extending DigiD to the private sector (DigiD-2)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22928357

Country of ref document: EP

Kind code of ref document: A1