A system for multi-party zero-knowledge proofs

Abstract

To realize a technique capable of implementing a certification service with higher user convenience or reducing the risk of leakage of privacy information.SOLUTION: A device is one of a plurality of devices participating in a multi-party computation on which a protocol for performing zero-knowledge proof in secret-sharing-based multi-party computation is implemented, and includes acquisition means for acquiring a share of data relating to a matter to be proved, and output means for outputting an output share obtained as a result of performing calculation according to a protocol with the acquired share as an input. It is possible to verification in zero-knowledge proof by output shares collected from a plurality of devices participating in a multi-party computation.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an apparatus and system for zero-knowledge proofs performed in multi-party computing. [Background technology]

[0002] In recent years, technologies related to zero-knowledge proofs have become well known. Zero-knowledge proofs (ZKPs) are a technology for proving to another party that one knows a secret (a secret), or that the secret possesses certain properties or satisfies certain conditions, without disclosing the secret to the other party. However, ZKPs must have the following three properties: completeness (the property that the prover can always convince the verifier if the proposition he or she is attempting to prove is true), soundness (the property that the prover's attempt to convince the verifier will fail with a high probability if the proposition he or she is attempting to prove is false), and zero-knowledge (the property that the verifier can gain no knowledge from the result of the prover's proof of a proposition other than that the proposition is true. In other words, the property that the verifier can simulate the validity of the proof even if he or she does not have the knowledge). Standardization of ZKP terminology and the characteristics of each method is currently underway, and this document follows this standard in principle (see Non-Patent Document 1).

[0003] On the other hand, multi-party computation (MPC) is a cryptographic technique that can derive a computation result while keeping input values ​​secret. In particular, a computation method using k-out-of-n threshold secret sharing (n≧k≧2) in which a secret input value is secretly shared among multiple shares, and the parties holding each share perform a predetermined procedure (protocol) to derive a computation result is called secret sharing-based multi-party computation. This computation method can provide functional completeness, and examples of implementations of various protocols using two-party computation are described in Non-Patent Document 2. In recent years, as calls for the digitalization of social infrastructure have grown and privacy protection has become an urgent issue, ZKP and MPC have been attracting attention as effective countermeasures. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] ZKProof Community Reference, Version 0.2, December 31, 2019, URL: https: / / docs.zkproof.org / pages / reference / reference.pdf [Non-patent document 2] Sander Siim, A Comprehensive Protocol Suite for Secure Two-Party Computation, 2016, URL:https: / / cyber.ee / research / theses / sander_siim_msc.pdf Summary of the Invention [Problem to be solved by the invention]

[0005] There are many situations where an individual or organization is required to attest to an external verifier. Modern attestation is often accomplished through a certificate issued by a third party or by the disclosure of information held by the individual or organization to the verifier.

[0006] However, in the process of proving, the information provided to the verifier often contains unnecessary information in both quantity and quality. For example, when purchasing alcohol, proving that "the person is an adult" may be achieved by presenting the verifier's driver's license and informing the verifier's alcohol seller of his or her date of birth. In this example, in addition to the fact that "the person is an adult," unnecessary information is included in both quantity (actual age) and quality (address, etc.). In other words, there is a growing demand for a means of proof that limits the leakage of unnecessary private information (information beyond the conclusion of the proposition that needs to be proven) as described above, does not impair convenience, and is sufficiently persuasive to the verifier.

[0007] The above problem can be solved, under certain conditions, by using known zero-knowledge proofs. However, the person who calculates the Prove using a zero-knowledge proof is required to handle private information (knowledge of the plaintext) and perform the calculation. Therefore, if the proof is entrusted to another party, the private information must be revealed to the entrustee. As a typical example, when performing a proof based on the private information of two people, the proof is entrusted to one of the two people or a third party, and it is assumed that the private information of at least one of the two people will be known to someone other than the person himself / herself. This becomes a problem when someone who does not want to leak unnecessary private information is asked to perform a proof based on that private information.

[0008] The present invention has been made in view of the above-mentioned problems, and its purpose is to realize a certification service that is more convenient for users or to realize a technology that can reduce the risk of leakage of private information. [Means for solving the problem]

[0009] One aspect of the present invention is system Regarding this system is a method for performing zero-knowledge proofs in secret sharing-based multi-party computation. 、 Multiple devices participating in multi-party computation System including verifier terminal And, The plurality Equipment Each of , Distributed by secret sharing-based multi-party computation, A means for acquiring a share of data related to the matter to be certified; If you receive a request for testimony, you must provide the data related to the matter you wish to prove. With shares as input, The proposition function of the data related to the matter to be proved Output the output share 1st An output means; a second output means for, when receiving a request for verification using the zero-knowledge proof, inputting a share of data related to an item to be proven and outputting a share of a proof of the zero-knowledge proof; Equipped with , the verifier terminal Collected from multiple devices participating in multi-party computation The propositional function Output share Reconstructing the multi-party computation, obtaining testimonials related to the matter to be proved, requesting verification by the zero-knowledge proof, and Zero-knowledge proofs Reconstruct the share of Proof, obtain Proof, and testify to the Proof Verification can be performed by Another aspect of the present invention is a method for producing a semiconductor device comprising: Device This Device teeth, This is one of the devices participating in multi-party computation in a system that includes multiple devices participating in multi-party computation and a verifier terminal for performing zero-knowledge proofs in secret sharing-based multi-party computation. .

[0010] In addition, any combination of the above components, or mutual substitution of the components or expressions of the present invention between devices, methods, systems, computer programs, recording media storing computer programs, etc., are also valid aspects of the present invention. [Effects of the Invention]

[0011] According to the present invention, it is possible to realize a certification service that is more convenient for users, or to reduce the risk of leakage of private information. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is a schematic diagram showing the configuration of an MPC-ZKP system according to an embodiment; [Figure 2] This is a schematic diagram to explain confidentiality, which is a benefit of using the MPC-ZKP system in Figure 1. [Figure 3] This is a schematic diagram to explain the transparency of logic, which is an advantage of using the MPC-ZKP system in Figure 1. [Figure 4] FIG. 1 is a table showing the characteristics of the proof modes implemented in the MPC-ZKP system. [Figure 5] FIG. 2 is a hardware configuration diagram of an MPC participating party (also called an MPC participating server) of the MPC participating party of FIG. [Figure 6] 2 is a block diagram showing an example of a functional configuration of an MPC participating party of FIG. 1. FIG. [Figure 7] 2 is a block diagram showing an example of the functional configuration of a management server operated by a service provider to manage the MPC participating parties in FIG. 1. FIG. [Figure 8] FIG. 8 is a data structure diagram showing an example of a verification logic formula DB of FIG. 7. [Figure 9] FIG. 8 is a data structure diagram showing an example of a data subject DB of FIG. 7. [Figure 10] FIG. 8 is a data structure diagram showing an example of a data class DB shown in FIG. 7. [Figure 11] FIG. 8 is a data structure diagram showing an example of a verifier DB of FIG. 7. [Figure 12] 8 is a data structure diagram showing an example of an individual policy DB of FIG. 7. FIG. [Figure 13] FIG. 8 is a data structure diagram showing an example of a verification history DB of FIG. 7. [Figure 14] 2 is a block diagram showing an example of a functional configuration of the data subject terminal of FIG. 1; [Figure 15] 2 is a block diagram showing an example of a functional configuration of a data generator terminal which is a terminal of a data generator. FIG. [Figure 16] 2 is a block diagram showing an example of a functional configuration of a verifier terminal shown in FIG. 1; [Figure 17] 10 is a data structure diagram showing an example of a verification logic formula DB of the verifier terminal 16. FIG. [Figure 18] 1 is a chart showing the flow of a proof sequence in an MPC-ZKP system. [Figure 19] This is a schematic diagram showing the configuration of an MPC-ZKP system when the data generator has already obtained agreement on third-party provision. [Figure 20] This is a chart showing the sequence flow of a proof (testimony) by a propositional function in an MPC-ZKP system. [Figure 21] FIG. 10 is a representative screen diagram of an output privacy breach notification screen displayed on the display of the data subject terminal of the data subject; [Figure 22] 10 is a data structure diagram showing an example of an input value DB in an MPC participating party 9. FIG. [Figure 23] 10 is a data structure diagram showing an example of an additional information DB in an MPC participating party 9. FIG. [Figure 24] 10 is a data structure diagram showing an example of a share DB in a share holding unit of an MPC participating party 9. FIG. [Figure 25]10 is a flowchart showing a series of operations performed by an MPC participating party 9. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the invention as claimed, and not all combinations of features described in the embodiments are necessarily essential to the invention. Two or more of the features described in the embodiments may be arbitrarily combined. Furthermore, the same reference numerals are used for the same or similar components, and redundant explanations will be omitted.

[0014] (Embodiment) The embodiment relates to an MPC-ZKP system that realizes a privacy-protecting entrusted attribute prover by combining secret sharing-based multi-party computation, which is one type of secure computation, with ZKP.

[0015] By combining MPC and ZKP, the MPC-ZKP system according to this embodiment can eliminate unnecessary privacy exposure for data that has left the hands of the data subject, from storing the data, to performing calculations based on the data, outputting the results of the calculations, and verifying the results. In other words, MPC and ZKP can protect input privacy, and query auditing can limit the leakage of output privacy.

[0016] The main features of the MPC-ZKP system according to this embodiment (but not limited to these) are as follows. 1. Privacy protection during certification In the MPC-ZKP system according to this embodiment, there is no need to hand over data containing privacy in an understandable state to the certification contractor or verifier. In the MPC-ZKP system, privacy is protected by the following two mechanisms. Each will be described in detail later. ● Input privacy protection function (secure computation, ZKP) ●Output privacy protection function (query audit method) 2.Transparency of verification logic The MPC-ZKP system according to this embodiment makes it possible to show the conclusion of the verification while making the verification logic unique and transparent. Furthermore, by managing data as a pair of a digital signature and a message, and using these as witnesses, and then including in the ZKP verification logic (Relation) that "the integrity of the message can be verified using the signature and public key," the source of the data (data generator) can be made clear. 3. Standardization of verification In the MPC-ZKP system according to this embodiment, verifications with the same purpose are standardized, and the data required for verification (Witness and Instance) are classified, which makes it possible to promote once-only verification and to perform multiple verifications on the same data (Witness and Instance). Note that a Witness is private information used for verification, whereas an Instance is public information used for verification. 4. Offline Certification As will be described later, depending on the ZKP scheme, the calculation result of a single proof can persuade not only the original verifier but also multiple subsequent verifiers (it is transferable). Utilizing this property, the proof result can be stored only on a portable device (removed from the proof consignee), allowing the device owner (user) to prove it to the verifier in person or over a dedicated line. 5. Entrustment of certification and proxy certification In the MPC-ZKP system according to this embodiment, even if the person (data subject) who wants to keep data secret is unable to prove for some reason, or does not know the proof method (e.g., how to calculate a ZKP), the verifier can perform the verification required by simply preparing the data, sharing it, and providing it to the verification contractor (the provider of the MPC-ZKP system) in a secret distribution manner. The advantage of being able to prove on behalf of someone is that, for example, the person is absent (or dies or goes missing), there is a temporary loss of authority due to the loss of a terminal, there is a lack of information technology literacy, or an inquiry from the authorities. In this way, privacy protection is achieved as described above even when proof is performed on behalf of someone else. 6. Strengthening the persuasive power of simple testimony (propositional function) Even if a proof trustee can calculate a propositional function using MPC for a certain proposition and output a verification result (testimony) while preserving the privacy of the underlying data, simply providing the testimony does not necessarily convince the verifier. This is because there is a possibility that the trustee (the person who performed the propositional function using MPC) and the trustor (such as the data subject) may collude to deceive the verifier, that the data subject may submit false evidence to the verifier, or that the prover's incompetence (errors in the proof calculation, bugs) may lead to an incorrect verification result. In other words, in naive proxy proof, submitting only the output of the propositional function lacks persuasive power. For example, providing the result of executing a propositional function using MPC constitutes such a simple testimony. The MPC-ZKP system of this embodiment provides a function that allows the verifier to, at his or her discretion or randomly, output a ZKP proof for a proposition that is identical to the proposition function previously executed. In other words, it provides a function that allows for spot checks of the correctness of the conclusion and the validity of the verification logic procedures adopted for the simple testimony described above. This effect acts as a check that makes it difficult for the party entrusted with the proof to make fraudulent testimony. The mechanism described above creates a strong incentive for the proving party not to commit false statements, as false statements would be significantly damaged. From a game-theoretic perspective, incorporating a mechanism that makes it difficult to falsify into the proof system makes simple statements (the results of propositional functions) more persuasive. As a result, while reducing the number of computationally expensive ZKP calculations, simple statements—i.e., the output results of propositional functions generated by MPC—can be made to be comparable in persuasiveness to ZKPs. As an application of this, when an arbitrary computational program f(x) based on secret x is subjected to MPC and the output result is y, it becomes possible to prove the proposition that "the result of f(x) is y," providing a strong incentive not to output an incorrect calculation result for f(x). 7. Eliminating combinatorial explosion of provers and verifiers in Interactive ZK When calculating an interactive ZK, the prover and verifier must be able to interact (they must be online) from the start of the proof to its completion. In particular, when a data subject performs proof on their own device, the "verifier: prover" combinations become a "many:many" relationship, resulting in a so-called combinatorial explosion. The MPC-ZKP system of this embodiment can consolidate the role of prover for multiple data subjects by entrusting it to an MPC participating party while still protecting privacy. As a result, the "verifier: prover" combinations are converted into a "many:1" relationship. 8. Attestation with Witnesses of Two or More Data Subjects In conventional ZKPs that use plaintext witnesses, when you want to prove something based on the secrets (witnesses) of multiple data subjects, you have to take one of the following measures: (1) Collect the witnesses of each data subject in a trusted third party environment and have them calculate the ZKP there. In this case, you must give up privacy protection from the trusted third party environment (TTP). (2) Each data subject calculates proof based only on their own witness. However, in this case, it becomes difficult to prove based on the combined (e.g., sum) information of two parties, and the proof increases with the number of data subjects, which may leak the output privacy of each data subject. On the other hand, in an MPC-ZKP system, the Witness of each data subject is privacy-protected (secret sharing) from everyone except the data subject himself, making it possible to calculate proofs based on the Witnesses of multiple data subjects while protecting the Witnesses of all data subjects.

[0017] FIG. 1 is a schematic diagram showing the configuration of an MPC-ZKP system 2 according to an embodiment. This example assumes a situation in which a patient is examined by a doctor and the results of the examination are reported to a border or prefectural border authority. The MPC-ZKP system 2 includes a data subject terminal 12 owned by a data subject 4 such as a patient; a data generator database (DB) 14 that stores data generated by a data generator 6 such as a doctor or hospital and its share; an MPC participant group 10 consisting of multiple MPC participant parties 9 participating in the MPC; an administration server 22 that manages administration information for a certain MPC participant group 10; and a verifier terminal 16 owned by a verifier 8 such as a border or prefectural border authority. Each MPC participant party (sometimes referred to as an MPC participant server) included in the MPC participant group 10 implements a protocol for performing ZKP in the MPC. The components of the MPC-ZKP system 2 (the data subject terminal 12, the data generator DB 14, each MPC participant party in the MPC participant group 10, and the verifier terminal 16) are connected to each other so that they can communicate with each other via a network such as the Internet. In this embodiment, the data subject terminal 12 and the data creator DB 14 are configured as separate entities. However, the data subject terminal 12 may include the data creator DB 14 .

[0018] This section explains how ZKP is provided in an MPC-ZKP system. Generally, the calculation process of ZKP can be divided into three procedures: Setup, Prove, and Verify. In this embodiment, Prove is performed by MPC. That is, the Witness is secret shared using a k-out-of-n threshold secret sharing scheme (n≧k≧2) and is made a private value. The Prove procedure, which takes the Witness as an input value, is performed using secret sharing-based multi-party computation (MPC). Note that based on the security parameter l, a prime number q, a generator g, i ∈ {0,1,...,n-1}, n is the number of MPC participating parties, and these are public values. Furthermore, the Witness is represented by w, and the shares secret shared from w using the k-out-of-n threshold secret sharing scheme are {w0, w1,... w n-1}. w i MPC Participation Party P i In k-out-of-n threshold secret sharing schemes, reconstruction is possible using shares held by k or more MPC participants out of n, where n≧k≧2. Any ZKP can be realized by an MPC that satisfies Functional Completeness. zk-SNARKs and Groth-Sahai require a trusted setup. Trusted setup is a method of requesting a trusted party to prepare (setup) a zero-knowledge proof for a certain proposition. For example, participating parties conceal a random number and publish this value as a CRS. If this random number becomes known to the prover, it has the weakness of enabling falsification (threating soundness). Therefore, in a trusted setup, multiple parties participate and cooperate, and a CRS is issued by adding up the random numbers of each party using properties such as homomorphism. This makes it possible to prevent falsification if even one party among all participating parties refuses to provide a random number. In particular, some implementations, such as Ligero and Sonic, which are subclasses of zk-SNARKs, are able to reduce the required trust. In the present invention, MPC participants are trusted to hold secret shares, and since there are multiple parties (n≧2), all or some of the MPC participants can also act as trusted parties. As an example, we will show the procedure for zk-SNARKs (1. to 3. below). 1. Calculation of Trusted Setup between MPC participants QAP <- Compile(relation) CRS <- Setup(QAP) Note that relation is a verification logic formula corresponding to the verification logic, QAP is a Quadratic Arithmetic Program (or R1CS) corresponding to relation (verification logic formula), CRS is a Common Reference String, CRS = {pk, vk}, pk is a Proving Key, and vk is a Verification Key (hereinafter, CRS may be referred to as additional information). 2. Prove by MPC π i <- Prove(CRS, x, w i ) Note that x is an Instance. MPC Participation Party P i is π i to the verifier. 3. Verify by the verifier π <- Reconstruct(π0, π1, …, π n-1 ) {accept, reject} <- Verify(CRS, x, π) Note that accept means acceptance of the proof, and reject means rejection of the proof.

[0019] In this example, the data subject 4 is a patient, who is the owner of the data to be provided, or the person who has the right to privacy. The data subject 4 is not limited to an individual, but may also be an organization.

[0020] The data generator 6 is a person whose role is to observe events and turn them into data. He is also the first data manager to whom the data subject 4 initially entrusts data. In this example, the data generator 6 is a doctor or hospital that examines patients, obtains and analyzes specimens, and turns them into data. In another example, the data generator 6 is a service operator that observes events detected by devices, sensors, etc., and turns them into data.

[0021] The service provider 7 is the operator of a service that uses the MPC-ZKP system 2. The service provider 7 operates the MPC participating parties 10 or outsources the operation to a third party. The service provider 7 can be said to be a second data controller because it receives a share of data from the data generator 6 (first data controller) via the data subject 4. In the third-party provision version described below, the service provider 7 can also be said to be a data processor.

[0022] An MPC participating party 9 is a server that performs secure computation and calculates (data processing) testimony (propositional function) or evidence (ZKP), and is an individual server that makes up the MPC participating party group 10. The MPC participating party group 10 includes multiple MPC participating parties 9, and MPC may be performed between servers under the jurisdiction of the same organization, or between servers (or nodes) under the jurisdiction of multiple different organizations.

[0023] The verifier 8 is a party that uses the evidence / testimony (ZKP, output of a propositional function) created by a second data manager (service provider, MPC participating party), and in this example is a border / prefectural border authority. The verifier 8 is a party that wants to verify the evidence / testimony. The service provider 7 may also be the verifier 8.

[0024] The management server 22 is a server managed by a service provider that uses the scheme of secure computation and zero-knowledge proof in the MPC-ZKP system 2, and has jurisdiction over the MPC participating parties 10. The management server 22 registers and stores verification logic formulas (sometimes called logical and arithmetic operation circuits) generated by the verifier 8, and provides the verification logic formulas to the requesting party in response to requests from the data subject terminal 12, the data generator terminal 24, and the MPC participating parties 9.

[0025] 1, we will explain the process flow from registering verification content in the MPC-ZKP system 2 to generating data to be used for verification, calculating the proof, and verifying it. We will assume that the data subject 4 and the verifier 8 have already completed user registration with the management server 22 of the service provider 7 and have been issued a data subject ID and a verifier ID, respectively. (1) The verifier 8 registers a verification logic formula from the verifier terminal 16 to the management server 22 that has jurisdiction over the MPC participating parties 10. At this time, the management server 22 assigns a verification logic ID to the verification logic formula. (2) The data subject terminal 12 confirms the verification logic ID requested by the verifier 8 and reads the verification logic formula associated with the verification logic ID from the management server 22 that oversees the MPC participating parties 10. The verification logic formula uniquely determines the data, data class (data format and requirements), and calculation method (proposition function, ZKP calculation method) used in the proof. This allows the data subject 4 to identify a data generator 6 (e.g., a doctor, hospital, or public institution) that will observe the event and generate the necessary data. (3) The data subject 4 (patient) communicates the verification logic ID to the data generator 6 (e.g., a doctor, hospital, or public institution) (via the data subject terminal 12). The data generator terminal 24 reads the verification logic formula linked to the verification logic from the management server 22. The data and data class (data format and requirements) used for proof are made unique from the verification logic formula. When the data subject 4 (patient) accepts the observations (e.g., medical examination, testing, identity verification) of the data generator 6 (e.g., a doctor, hospital, or public institution) and performs an evaluation, the evaluation result data is read into the data generator terminal 24. (4) The data generator terminal 24 processes the read data into a data class format and affixes a digital signature using the private key sk of the data generator 6's public key cryptography. The public key pk of the data generator 6 can be obtained, for example, through a PKI. The generated data is represented by w. The digital signature for the data is represented by ws. The pair (w, ws) is called a signed witness. The data generator terminal 24 stores the generated signed witness (w, ws) in the data generator DB 14. (5) The data subject terminal 12 acquires and reads the signed witness (w, ws) from the data generator DB 14. To verify the validity of the received signed witness (w, ws), the data subject terminal 12 confirms that the integrity verification by the digital signature is successful using the public key pk of the data generator acquired from a PKI or the like. The data subject terminal 12 performs k-out-of-n threshold secret sharing of the signed witness (w, ws) (n≧k≧2). The secret sharing shares of w are {w0, w1, ..., w n-1}. Similarly, the secret shared shares of ws are {ws0, ws1, ..., ws n-1}. (w i , ws i ) is called a share of signed witness, where i∈{0,1,…,n}, n is the number of parties in the MPC participant group 10. (6) When the data subject terminal 12 receives an operation indicating that the data subject 4 agrees to the processing content (= verification logic formula, privacy policy) linked to the verification logic ID, the data subject terminal 12 sends a i to,Signed Witness Share(w i , ws i ) to send. (7) The MPC participating party group 10 is composed of each MPC participating party P i The share of signed witnesses in i , ws i ) and the public key pk of the data generator 6 obtained from a PKI, etc., based on the verification logic formula linked to the verification logic ID, the MPC calculates the testimony (proposition function).i is the share of testimony τ i get. (8) The verifier 8 receives a notification of the data subject ID from the data subject 4. The verifier terminal 16 of the verifier 8 receives the data subject ID from each MPC participating party P of the MPC participating party group 10. i , and receives the testimony output shares {τ0, τ1, ..., τ i} (MPC Participating Party P i From τ i ) and Reconstructs (i.e., collects the secretly shared values ​​and restores the original value) to obtain the testimony τ. If the verifier 8 disagrees with the testimony τ, it inputs this to the verifier terminal 16. When the verifier terminal 16 receives input indicating disagreement with the testimony, it requests a proof using a zero-knowledge proof from the MPC participating parties 10. Alternatively, even if the verifier 8 does not disagree with τ, the verifier terminal 16 can randomly request a zero-knowledge proof from the MPC participating parties 10. (9) When a request for proof by zero-knowledge proof (Proof, i.e., the output of the Prove procedure) is received, each MPC participant party P i performs ZKP calculation by MPC based on the verification logic formula associated with the verification logic ID. If the ZKP scheme (type of ZKP) registered in the verification logic formula associated with the verification logic ID is, for example, NIZK (Non-Interactive ZK), the MPC participating party P i is the output share of the proof {π0, π1, ..., π n-1 On the other hand, if the ZKP scheme registered in the verification logic formula associated with the verification logic ID is, for example, Interactive ZK, then the MPC participating party P i (1) sends the commitment to the verifier terminal 16 of the verifier 8, and (2) the verifier terminal 16 of the verifier 8 sends the commitment to each MPC participant P of the MPC participant group 10. i After sending the challenge to (3) MPC Participating Party P iis the output share of the proof {π0, π1, ..., π n-1}, where (2) and (3) may be repeated (Soundness Amplification). (10) The verifier terminal 16 of the verifier 8 is authenticated by the MPC participating parties 10 using credentials or the like, and receives from the MPC participating parties 10 the output shares {π0, π1, ..., π n-1} (MPC Participating Party P i to π i ) and reconstruct to obtain the proof π. Also, according to the ZKP scheme registered in the verification logic formula, CRS (additional information) required for the above-mentioned Verify is obtained from the MPC participating parties 10. Verify is calculated, and the verification terminal 16 of the verifier 8 accepts or rejects the verified content.

[0026] In the MPC-ZKP system 2 in Figure 1, if a group of MPC participating parties 10 can collect data belonging to the same individual that has been created by multiple data generators, it becomes possible to perform multifaceted proofs about the same individual. Conventionally, documents issued by data generators had to be collected and submitted to a verifier for verification. These documents often contain unnecessary information that the verifier does not need to know. In the MPC-ZKP system 2 in Figure 1, the group of MPC participating parties 10 collectively perform the desired proofs while preserving privacy. Furthermore, by collecting data from different people while keeping it secret, the MPC participating parties 10 can create proofs that combine data from different people without compromising privacy. To achieve the same thing with conventional ZKPs, the plaintext had to be placed on the same computer for calculation. This would result in the privacy of at least one of the two people being leaked to someone other than the person involved. In this regard, the MPC-ZKP system 2 in Figure 1 allows the MPC participating parties 10 to collectively perform the desired proofs while protecting the privacy of multiple people. Note that Data Subject 4 may issue a new Data Subject ID in addition to the old Data Subject ID and perform the proof using the latter Data Subject ID. This makes it possible to control the verifier so that it cannot match the contents of past verifications.

[0027] As an example of applying the MPC-ZKP system 2 in Figure 1, consider its application to determining whether to allow travel when the coronavirus is spreading and travel between regions is restricted. When traveling between regions, the control authority wants to allow the travel only after verifying that the individual's probability of infection is extremely low. Since the definition of "extremely low probability of infection" varies, the control authority prepares the following verification logic formula (signed CRS): Verification logic formula: If you take a PCR test at a hospital and it is negative, and you have not been near an area where a cluster has occurred within the past week, the probability of infection is extremely low.

[0028] If you want to move to another area, you can take the following actions in advance: 1. The service provider or MPC participating party that receives the verification logic formula from the management station calculates the verification logic formula (e.g., Rank 1 Constraint System, Quadratic Arithmetic Program) and the CRS (additional information) of the data required to calculate the verification logic. 2. The data subject downloads this validation logic formula and CRS (additional information) to the device, requests the necessary data from the data generator (e.g., visits a hospital, activates location information services), and receives it. 3. The calculation result (Proof) is derived using the downloaded verification logic formula and data. 4. The proof is performed by presenting the calculation result to the management station. At this time, the data subject can obtain the verification logic formula and CRS (additional information) signed by the service provider or MPC participating party, or the management station can receive the verification logic formula and additional information (CRS) from the service provider or MPC participating party in advance, making this proof possible offline (local, closed network).

[0029] The MPC-ZKP system 2 according to this embodiment registers the data in 2 above in a secretly distributed manner among the MPC participating parties 10, and enables entrusted proof, in which the proof is performed by calculation using MPC among those MPC participating parties. Furthermore, by having the service provider or MPC participating party mediate the logic, it is possible to standardize the proof standards and unify the circuit design and setup required for ZKP, thereby avoiding the proliferation of proofs with the same purpose.

[0030] Figure 2 is a schematic diagram specifically illustrating confidentiality, a benefit of using the MPC-ZKP system 2 in Figure 1. The MPC-ZKP system 2 achieves confidentiality, i.e., prevents unnecessary information disclosure. Conventionally, multiple different data generators, such as hospitals and map service providers, observe evaluation targets, such as patients, and generate their own observation results (e.g., xa indicating a negative / positive medical result, xb indicating that the patient has not approached a cluster outbreak area, etc.). These data xa and xb are then collected in one location and used to determine whether or not to allow movement. The problem with this conventional technology is privacy, namely, the need to collect raw data in one location. Evaluation targets often do not want to reveal more information about themselves than necessary to the verifier. Furthermore, data exchange in this conventional technology requires written documents, resulting in redundant administrative procedures.

[0031] In contrast, when using the MPC-ZKP system 2 according to this embodiment, for example, the data generator (or the data subject) shares the data and provides the shares, rather than the raw data, to the MPC-ZKP system 2. For example, xa, which indicates a negative / positive examination result, is divided into two shares, xa1 and xa2, which are each sent to a different server (i.e., the MPC participating parties). Similarly, xb, evidence that the patient has not approached a cluster outbreak area, is divided into two shares, xb1 and xb2, which are each sent to a different server. The MPC-ZKP system 2 (the MPC participating parties 10) accepts the shared data (not the raw data itself) and provides the verification results to the verifier 8 (via the verifier terminal 16). In this way, MPC (sharing) enables verification while protecting privacy.

[0032] Figure 3 is a schematic diagram illustrating the transparency of logic, which is a benefit of using the MPC-ZKP system 2 in Figure 1. The MPC-ZKP system 2 ensures the transparency of logic and eliminates fabrication. Conventionally, an evaluator (witness) such as a doctor or expert observes an evaluation target such as a patient, evaluates the observation data x according to the evaluation logic, and provides the evaluation result, or conclusion y, to a verifier such as a border or prefectural border authority. In most cases, the conclusion is reduced to a Yes / No, such as whether or not the person is infected. This conventional technology has the following two problems. (1) Ability Issues The issue is whether the evaluation logic used by the evaluator to reach a conclusion is valid. Differences in the perspectives of the evaluator and verifier can lead to variations in the standards for "acceptance." (2) The question of intent There is a possibility that the evaluator may tamper with evidence or give false testimony.

[0033] In contrast, when the MPC-ZKP system 2 according to this embodiment is used, the data x is converted into shares (in the example shown in FIG. 3, 2-out-of-2 secret sharing is assumed, and the shares are represented by x1 and x2), thereby maintaining the confidentiality of the data. The verification logic formula is separated from the evaluator, checked and deployed by the verifier, and agreed upon by the evaluation target. This verification logic formula is bound by the CRS, making it impossible to tamper with the verification logic formula. The verification logic formula and shares are provided to the MPC-ZKP system 2, which creates a testimony. The verifier can obtain proof of non-infection by collecting the output shares (e.g., y1, y2) output by the MPC-ZKP system 2 and reconstructing the conclusion y. In this way, objective testimony is possible as long as the data itself is not tampered with. Regarding tampering of the data itself, partial countermeasures against tampering are possible, such as by having the data generator sign the shares.

[0034] In the example of Figure 1, we have explained the case where the data generator 6 does not obtain consent from the data subject 4 to provide (the data share) to a third party, but this is not limited to this, and the data generator 6 may obtain consent from the data subject 4 to provide the data share to a third party. Figure 19 is a schematic diagram showing the configuration of the MPC-ZKP system 2 when the data generator 6 has already obtained consent to provide the data to a third party. The signed witness (w, ws) is shared (w i , ws i ) and provided from the data generator DB 14 to each MPC participating party 9 in the MPC participating party group 10 without going through the data subject terminal 12.

[0035] Next, we will explain the details of the MPC-ZKP system 2. Figure 4 is a diagram in tabular form showing the characteristics of the proof modes implemented in the MPC-ZKP system 2. The MPC-ZKP system 2 has three proof modes: (1) user terminal zero-knowledge proof mode, (2) MPC propositional function attestation mode, and (3) MPC zero-knowledge proof mode. The user (the verifier 8) can use these three modes depending on their requirements. The characteristics of each mode are as shown in Figure 4. As shown in the figure, the MPC propositional function attestation mode does not provide transparency of the verification logic. However, since the verifier can randomly or arbitrarily request a proof in the MPC zero-knowledge proof mode or the user terminal zero-knowledge proof mode, this acts as a deterrent to falsifying the output of the MPC propositional function attestation mode. Because the MPC zero-knowledge proof mode requires a huge amount of computation, reducing the number of times this mode is executed will contribute to shortening the total computation time. Although the MPC propositional function testimony mode does not have transparency in the verification logic, it can output a conclusion (testimony) more quickly than the MPC zero-knowledge proof mode. Therefore, by allowing the verifier to execute the proof in the MPC zero-knowledge proof mode at their discretion or randomly, it is possible to reduce the computational load and prevent falsification of the testimony (the result of the propositional function) in the MPC propositional function testimony mode.

[0036] Next, we will explain the configuration of the verifier terminal 16 in Fig. 1. The hardware configuration of the verifier terminal 16 may be similar to the hardware configuration shown in Fig. 5, as will be described later with reference to Fig. 5. An example of the functional configuration of the verifier terminal 16 will be described with reference to Fig. 16. Note that each block shown in this figure and in the block diagrams described below can be realized in hardware terms by elements and mechanical devices such as a computer CPU, and in software terms by a computer program, etc., but here we depict functional blocks realized by the cooperation of these. Therefore, those skilled in the art who have read this specification will understand that these functional blocks can be realized in various ways by combining hardware and software. The verifier terminal 16 includes a verification logic formula acquisition unit 162, a verification logic formula deployment unit 164, a testimony request unit 165, a verification logic formula DB 166, an evidence request unit 168, and a verification unit 170. The verifier terminal 16 makes it possible to verify propositions using ZKP or testimony using the output shares collected from each MPC participating party 9 in the MPC participating party group 10.

[0037] The verification logic formula acquisition unit 162 reads input data classes that can be used for the verification logic formula from the management server 22, and acquires (1) the relational formula of the object to be proven and (2) the ZKP scheme to be applied in the verification logic formula according to input by the verifier 8. The verification logic formula acquisition unit 162 registers the acquired verification logic formula in the verification logic formula DB 166. The verification logic formula deployment unit 164 deploys the verification logic formula registered in the verification logic formula DB 166 to the management server 22. Specifically, the verification logic formula deployment unit 164 registers the verification logic formula (formula representing Relation) and the ZKP scheme in the management server 22 of the service provider 7, and acquires a verification logic ID associated with the deployed verification logic formula. The verification logic formula acquisition unit 162 associates the verification logic formula with the verification logic ID and registers them in the verification logic formula DB 166.

[0038] The verification logic formula DB 166 manages verification logic formulas. FIG. 17 shows data stored in the verification logic formula DB 166. The data stored in the verification logic formula DB 166 includes, for example, a verification logic ID, a verification logic formula, and a ZKP scheme. The verification logic formula DB 166 may further be associated with the verifier ID that performed the registration, or may have the same format as the data in the verification logic formula DB 118 provided in the management server 22, which will be described later. The verifier 8 can view the data in the verification logic formula DB 166 at any time.

[0039] The testimony request unit 165 (in response to an operation by the verifier 8) sends a testimony request to each MPC participating party 9 in the MPC participating party group 10 to request testimony (proposition function) regarding the verification logic ID and the data subject ID correspondence value (details will be described later). Note that in this embodiment, an example is described in which a testimony request is sent to an MPC participating party 9, but the testimony request may also be sent to the management server 22, and the management server 22 may request testimony from each MPC participating party 9. The proof request unit 168 first requests additional information linked to the verification logic ID and the data subject ID corresponding value from the MPC participating party 9. Then, the proof request unit 168 requests the MPC participating party 9 to provide the proof (output share (π i)). For example, the evidence request unit 168 generates an evidence request based on a request made by operation of the verifier 8 or a predetermined determination made by the evidence request unit 168, and sends it to the MPC participating party 9. The evidence request unit 168 may make the predetermined determination as follows. For example, immediately after acquiring the output share of the proposition function, the evidence request unit 168 takes a locally generated random number, or a transaction hash at a certain block height in the public chain (using a predetermined blockchain algorithm) after the share acquisition, as a random number, and determines whether this number exceeds a predetermined threshold. If the random number or transaction hash exceeds the predetermined threshold, the evidence request unit 168 generates an evidence request (without waiting for a request made by operation of the verifier 8). Note that this embodiment has been described taking as an example a case where a request for additional information and an evidence request are sent to the MPC participating party 9, but it is also possible to send the evidence request to the management server 22, and have the management server 22 request additional information and evidence from each MPC participating party 9.

[0040] The verification unit 170 acquires the output share of the testimony (proposition function) output from the MPC participating party 9, reconstructs it, and acquires the testimony τ. In addition, when the verification unit 170 requests evidence, it receives the output share (π i ), and additional information linked to the verification logic formula. The verification unit 170 recovers the ZKP (Proof) by collecting the acquired output shares. For example, the verification unit 170 authenticates the signed output shares, the verification logic formula, and (when Trusted Setup is used) the CRS (especially the Verification Key) using the public key of the management server 22. Furthermore, the verification unit 170 performs verification using the recovered ZKP (Proof), the verification logic formula, and (when Trusted Setup is used) the Verification Key of the authenticated CRS. The verification unit 170 outputs, for example, either Accept or Reject as the verification result. 16, the verifier terminal 16 may further include a verifier registration unit for registering verifiers 8 and obtaining a verifier ID that uniquely identifies each verifier. For example, by providing the verifier ID to the data subject 4, the data subject 8 can realize desired access control for the verifier (when implementing individual policies regarding data handling). Here, we will explain the above-mentioned data subject ID corresponding value. The data subject ID corresponding value is data that makes it possible to replace the personal data in the verification logic formula, and to reuse the verification logic formula to prove different combinations of individuals. For example, consider the case where the following is used as the verification logic formula: Note that the SigVerify function in the following verification logic formula represents a function that uses the public key of the first argument to verify the integrity of the value of the second argument with the digital signature of the third argument. --<Validation logic expression>-- DC008[0] + DC008[1] > 10000000 && SigVerify(DC012, DC008[0], DC013[0]] == true && SigVerify(DC012, DC008[1], DC013[1]] == true -------------- In this validation logic expression, DCxxx represents a data class, DC008 represents annual income, DC012 represents the city hall's public key, and DC013 represents the city hall's signature on annual income. "[0],[1],.." are subscripts that identify the specific target of each data class. For example, DC008[0] is Person A's annual income, and DC008[1] refers to Person B's annual income. This can be implemented by extracting subscripts from variables in the ASTs (Abstract Syntax Trees) of the validation logic expression. However, the brackets ([]) surrounding the subscripts may be expressed differently. For example, if the expressions of an existing programming language (such as C) are used as the grammar for validation logic expressions, they may conflict with array expressions, so different symbols and different layouts may be used to create different expressions. The data subject ID correspondence value is a mechanism that allows you to specify the target of a data class by substitution. For example, if you specify the data subject ID correspondence value in the array format of [DS003, DS004], the data subjects of DC008[0] and DC008[1] will be DC008[0] = DS003, and DC008[1] = DS004 can be assigned as follows. In this case, the above validation logic formula means "Is the total annual income of two data subjects who received signatures from the same city hall greater than 10 million yen?" In this way, by changing the order (array subscripts) of the data subject IDs arranged in the data subject ID correspondence value or specifying other IDs, it becomes possible to reuse the created validation logic formula to certify different combinations of individuals. Note that if the validation logic formula is a certification for a single data subject, the above subscripts can be omitted, and a single data subject ID can be specified as the data subject ID correspondence value.

[0041] Next, the configuration of the MPC participating party 9 (also referred to as the MPC participating server) will be described. FIG. 5 is an example of a hardware configuration diagram of the MPC participating party 9 of FIG. 1. The other MPC participating parties, the verifier terminal 16, the data subject terminal 12, and the data generator terminal 24 may also have a hardware configuration similar to the hardware configuration shown in FIG. 5. The MPC participating party 9 includes a memory 130, a processor 132, a communication interface 134, a display 136, and an input interface 138. Each of these elements is connected to a bus 140 and communicates with each other via the bus 140.

[0042] The memory 130 is a storage area for storing data and programs. The data and programs may be stored in the memory 130 permanently or temporarily. The processor 132 executes the programs stored in the memory 130 to realize various functions of the MPC participating party 9. The communication interface 134 is an interface for sending and receiving data to and from the outside of the MPC participating party 9. For example, the communication interface 134 includes an interface for accessing a network, and sends and receives data to and from other MPC participating servers, the data subject terminal 12, and the verifier terminal 16 via the network. The display 136 is a device for displaying various information, such as a liquid crystal display or an organic EL (electroluminescence) display. The input interface 138 is a device for receiving input from a user. The input interface 138 includes, for example, a mouse, a keyboard, and a touch panel provided on the display 138.

[0043] FIG. 6 is a block diagram showing an example of the functional configuration of the MPC participating parties 9 in FIG. 1. i ) includes an input data acquisition unit 102, an instance holding unit 103, a calculation unit 104, a data provision unit 106, a share deletion unit 108, and a share holding unit 109.

[0044] The input data acquisition unit 102 acquires data related to the matter to be proven. There are two types of data: an Instance and a share of a signed witness (a Witness share). The share acquisition unit 102 receives the Instance and the secretly shared share of a signed witness (a Witness share) from the data subject terminal 12 or the data generator terminal 24 via the network. i , ws i ) is acquired. Various shares are i , w i , ws i , v i , τ i , π i |i∈{0,1,...,n-1}}, where n is the number of MPC participating parties 9 in the MPC participating party group 10, i.e., the number of parties participating in the MPC, and i makes each MPC participating party 9 unique (P i ) When the Instance is passed by reference, the input data acquisition unit 102 further acquires the entity (for example, the public key of the data generator 6) via the network.

[0045] The input data acquisition unit 102 communicates with the MPC participating parties 9 of the MPC participating party group 10, and performs MPC processing of the digital signature integrity verification algorithm using the signed witness share (Witness share) as input. Then, the resulting output share (v i ) is shared among the MPC participating parties 9, and the verification result (v) is reconstructed. When the input data acquisition unit 102 confirms that the verification is successful, it registers the share of the signed witness in the share holding unit 109. Furthermore, the input data acquisition unit 102 registers the instance in the instance holding unit 103. The share data holding unit 109 and the instance holding unit 103 hold this data in the format shown in FIG. 22 (for example, a set of data subject ID, data class ID, and value).

[0046] The calculation unit 104 calculates a proposition function in response to receiving a testimony request from the verifier terminal 16, and also calculates a ZKP in response to receiving an evidence request from the verifier terminal 16. (1) A case where a testimony request is received from the verifier terminal 16 will be described. The calculation unit 104 receives a testimony request regarding a data subject ID correspondence value and a verification logic ID from the verifier terminal 16. When the calculation unit 104 receives the testimony request, it starts processing for executing a proposition function based on the data subject ID correspondence value and the verification logic ID. The calculation unit 104 first obtains a verification logic formula and a verification logic ID from the management server 22. Furthermore, it determines whether the protection range indicated in the data of the individual policy DB is satisfied for all individual policies of the data subject IDs included in the data subject ID correspondence value (obtained from the management server 22). If it determines that the protection range is satisfied for all data subject IDs, the calculation unit 104 calculates a proposition function that conforms to the verification logic formula based on the share of the data class included in the verification logic formula and the value of Instance. The calculation unit 104 can transmit data related to the data subject ID corresponding value used in the calculation (i.e., the leaked privacy of the data subject ID) to the management server 22 and have it registered in the verification history DB 142. In other words, the calculation unit 104 makes the management server 22 manage what data related to the data subject ID corresponding value was used in the proposition calculation, thereby realizing the necessary privacy control. (2) Next, we will explain the case where a ZKP is calculated upon receiving a request for evidence from the verifier terminal 16. In this case, the calculation unit 104 first receives a request for additional information related to the data subject ID correspondence value and the verification logic ID from the verifier terminal 16, and acquires the additional information associated with the data subject ID correspondence value and the verification logic ID. The calculation unit 104 then transmits the acquired or calculated additional information to the verifier terminal 16. The verifier terminal 16 sends a proof request in response to receiving the additional information, so the calculation unit 104 accepts the proof request from the verifier terminal 16. If the ZKP scheme of the ZKP requested by the verifier terminal 16 is an interactive ZK, the calculation unit 104 receives challenge information from the verifier terminal 16 in addition to the data subject ID corresponding value and the verification logic ID. Upon accepting the proof request (or the proof request and the challenge information), the calculation unit 104 starts processing for ZKP execution based on the data subject ID corresponding value and the verification logic ID. The calculation unit 104 first obtains the verification logic formula and verification logic ID from the management server 22. The calculation unit 104 also reads out the additional information sent to the verifier terminal 16. Here, the calculation unit 104 determines whether the protection range indicated in the data of the individual policy DB of the management server 22 is satisfied for all individual policies of the data subject IDs included in the data subject ID correspondence value (obtained from the management server 22). If the calculation unit 104 determines that the protection range is satisfied for all data subject IDs, it calculates a ZKP that conforms to the verification logic formula based on the share of the data class included in the verification logic formula, the value of Instance, and the additional information. Thereafter, the calculation unit 104 calculates the output share (the share of π, which is the Proof, π) obtained after calculating the ZKP. i ) is stored in the share holding unit 109. The additional information may be stored in an additional information DB (not shown), for example, in the data format shown in FIG. 23, or may be stored in memory for a predetermined period of time. For example, as shown in FIG. 23, the additional information data may be associated with a verification logic ID and a data subject ID correspondence value. The additional information may include a CRS and a commitment. The additional information varies depending on the ZKP scheme. If the ZKP scheme belongs to an interactive ZK, such as Schnorr's Protocol or Sigma Protocol, the additional information may include, for example, a commitment. If the ZKP scheme belongs to a non-interactive ZK (NIZK) that requires trust from a specific party, such as zk-SNARKs or Groth Sahai, the additional information may include, for example, a common reference string (CRS). If the ZKP scheme belongs to an NIZK that does not require trust from a specific party, such as zk-STARKs under the RO assumption, the additional information may include, for example, a commitment (Merkle Tree, Merkle Tree Root). Furthermore, the output shares obtained by the proposition function or ZKP may be stored in the share holding unit 109 in the data format shown in Fig. 24. In the data format shown in Fig. 24, for example, the output shares of the proposition function and ZKP associated with the data subject ID corresponding value, the verification logic ID, and the calculation start date and time are stored.

[0047] When the calculation unit 104 executes a proposition function, the data providing unit 106 outputs the output share obtained as a result of the calculation to the verifier terminal 16. When the calculation unit 104 executes a ZKP, the data providing unit 106 outputs the output share obtained as a result of the calculation and additional information used by the calculation unit 104 to the verifier terminal 16. At this time, the data providing unit 106 may determine whether the protection range indicated in the data in the individual policy DB is satisfied for all individual policies for data subject IDs included in the data subject ID correspondence value (obtained from the management server 22), and may output the output share (and additional information in the case of a ZKP) if it is determined that the protection range is satisfied for all data subject IDs.

[0048] When the share deletion unit 108 receives a deletion request from the data subject terminal 12 used by the data subject 4 and / or the data creator terminal 24 used by the data creator 6, it deletes the target share from the share holding unit 109.

[0049] Fig. 7 is a block diagram showing an example of the functional configuration of the management server 22 operated by the service provider 7 to manage the MPC participating party group 10 of Fig. 1. The management server 22 includes a management information control unit 110, a setup unit 112, a verification request acquisition unit 114, a determination unit 116, a verification logic formula DB 118, a data class DB 120, a data subject DB 122, a verifier DB 124, an individual policy DB 128, and a verification history DB 142.

[0050] The management information control unit 110 issues an ID that uniquely identifies data (e.g., data subject, verifier, verification logic formula, data class, etc.) registered in various DBs of the management server 22. The data subject ID is information that uniquely identifies a data subject, and the management information control unit 110 issues this ID when registering the data subject. Note that the data subject is not limited to an individual, but may also be an organization. The verifier ID is information that uniquely identifies a verifier, and the management information control unit 110 issues this ID when registering the verifier. Note that a service provider may also be registered as a verifier. The verification logic ID includes a verification logic formula and a ZKP scheme (type of ZKP). The verification logic ID uniquely identifies the combination of a verification logic formula and a ZKP type. In this embodiment, both propositional functions and ZKPs can be calculated based on verification logic formulas of the same format. A data class ID is information that uniquely identifies a data class, and the data class includes the data class name (e.g., "age") and the data type (e.g., Boolean type or number of bits), and when a data class ID is specified, the data class and whether it is public or private (i.e., witness or instance) are uniquely identified. The data class ID is issued by management information control unit 110 when a data class is registered. The management information control unit 110 also transmits and receives data to and from the verifier terminal 16, the data subject terminal 12, or the MPC participating party 9 in the system 2, and controls the writing and reading of data to and from various DBs. The registration of various data by the management information control unit 110 will be described below. (1) Control of registration of data subject information When data subject information is registered in the data subject terminal 12, the management information control unit 110 acquires from the data subject terminal 12 the data subject's identity information, such as the name and address, and a signature for the identity information from a certification authority, and registers the data in the data subject DB 122. At this time, the management information control unit 110 issues a data subject ID to the new data subject and transmits it to the data subject terminal 12. The data subject DB 122 records data that associates a data subject ID that identifies a data subject, a data class ID that identifies a data class, and data that is publicly available to the data subject, as shown in FIG. 9 . The ID information recorded in the data subject DB 122 may be made public, and if made public, is treated as an instance. The data subject information recorded in the data subject DB 122 is recorded as a share in each MPC party 9 and kept confidential. If a data subject acquires multiple data subject IDs and uses the information of the data subject IDs for different purposes, the information is decentralized, and it is possible to prevent the entire identity information of a data subject from being ascertained by collecting multiple pieces of information about the data subject. (2) Verifier information registration control When verifier information is registered in the verifier terminal 16, the management information control unit 110 acquires the verifier's identity information from the verifier terminal 16 and registers the data in the verifier DB 124. At this time, the management information control unit 110 issues a verifier ID to the new verifier and sends it to the verifier terminal 16. The verifier DB 124 records data associating the verifier ID, the verifier organization name, and a privilege inquiry flag, as shown in FIG. 11, for example. The privilege inquiry flag indicates a verifier who has the privilege to obtain an output share of testimony or evidence, regardless of the set privacy policy. If the flag is set to "True" (for example, a service provider or an authorized administrative agency), it indicates that the verifier has the privilege. (3) Reference control of data classes When a verifier generates or edits a verification logic formula on the verifier terminal 16, the management information control unit 110 receives a reference to a data class from the verifier terminal 16 and transmits data class information to the verifier terminal 16. Data class information is registered, for example, by a service provider or a data generator 6. When the data class is registered, the management information control unit 110 issues a data class ID and registers the information in the data class DB 120. As shown in FIG. 10 , the data class DB 120 records data that associates a data class ID, a data class name, a data format of the data class, data format details that explain the data format in more detail, and a disclosure category. The data type may be, for example, a Boolean value or the number of bits. Once the data class format is determined, the type (format) of data sharing is also determined. Therefore, it can be said that the data share format is registered in the data class DB 120. A data class whose disclosure category is set to private is a witness, and a data class whose disclosure category is set to public is an instance. (4) Registration and reference control of validation logic formulas When a verification logic formula is transmitted from the verifier terminal 16, the management information control unit 110 registers the verification logic formula in the verification logic formula DB 118. At this time, the management information control unit 110 issues a verification logic ID and transmits the issued verification logic ID to the verifier terminal 16. As shown in FIG. 8, the verification logic formula DB 118 records the verification logic ID that identifies the verification logic formula, the verification logic formula, and the ZKP scheme that identifies which ZKP algorithm (scheme) to use when executing ZKP, in association with each other. The verification logic ID is a hash value of the processing content (calculation formula) and the input data format (json, yaml, toml, etc.), and uniquely identifies the verification logic formula and the signed verification logic formula. The verification logic formula may be pseudocode. Furthermore, the verification logic formula may use a predetermined specific symbol such as "#" as a symbol to identify comments in the pseudocode. When the verifier terminal 16 accesses the verification logic ID and the verification logic formula in order to provide them to the MPC participating party 9, the management information control unit 110 provides the verification logic ID and the verification logic formula to the verifier terminal 16. Alternatively, when the verifier terminal 16 requests that the MPC participating party 9 provide the verification logic ID and the verification logic formula, the management information control unit 110 may provide the verification logic ID and the verification logic formula to the MPC participating party. Furthermore, the management information control unit 110 transmits the verification logic ID and the verification logic formula to the data subject terminal 12 as needed or in response to a request from the data subject terminal 12 . (5) Registration control of individual policies In response to receiving a registration request for a privacy policy for a verifier ID from the data subject terminal 12, the management information control unit 110 registers the privacy policy in the individual policy DB 128. As shown in FIG. 12, the individual policy DB 128 records data in which, for example, a data subject ID for identifying a data subject who has set a privacy policy, a data class ID for identifying a data class related to the privacy policy, a verification logic ID, a verifier ID for identifying a verifier targeted by the privacy policy, an expiration period of the privacy policy, and a protection range of the privacy policy are associated with each other. The expiration period indicates the period during which the privacy policy is applied, and in the example of FIG. 12, it is shown in minutes. After the specified period has elapsed, it will not be protected. The protection range represents a range indicating how much the true value can be narrowed down by the execution of a plurality of proofs. Specifically, the data of the date of birth indicating October 1, 1980 will be used as an example for explanation. For example, when a proof (1) that the data subject's date of birth is after 1975 (> 19741231) and a proof (2) that the date of birth is before 1996 (<1996010>1) are executed, the privacy that the data subject's date of birth is between 1975 and 1996 is leaked. However, for example, if the period during which privacy is leaked is larger than the value specified in the protection range, proofs (1) and (2) are allowed. On the other hand, when further executing a proof that the data subject's date of birth is before 1983 (<1984010>1), if the range in which privacy is leaked becomes smaller than the value specified in the protection range (that is, narrowed down to a narrower range), the execution of the proof is rejected. Note that the scales of values possessed by a data class include a nominal scale (a scale used to distinguish concepts), an ordinal scale (a scale in which the magnitude relationship has meaning), an interval scale (a scale in which the magnitude of the interval, that is, the difference in notification, has meaning), a ratio scale (a scale in which the ratio of numerical values also has meaning in addition to the difference in numerical values), and the like. The above-mentioned protection range can be set for ordinal deletion, interval scale, and ratio scale among these scales. (6) Registration / Reference Control of Verification History When the MPC participating party 9 executes a proposition function or a ZKP, data in the verification history DB is referenced to determine whether the MPC participating party 9's execution of a proof violates an individual policy. At this time, the management information control unit 110 transmits corresponding verification history DB data to the MPC participating party 9 in response to a reference request from the MPC participating party 9. After the MPC participating party 9 executes a proposition function or a ZKP, the management information control unit 110 also accepts registration of a verification history from the MPC participating party 9. Specifically, for each data class (associated with the data subject ID corresponding value) included in the verification logic formula used by the MPC participating party 9 to execute the proposition function or ZKP, the MPC participating party 9 transmits to the management server 22 a request to register the upper and lower limit values ​​that can be used for the data. In this case, the management information control unit 110 registers the history information in the verification history DB 142. For example, as shown in FIG. 13 , the verification history DB 142 records data in which, for example, a data subject ID, a data class ID, a verifier ID, a lower limit value, an upper limit value, and the respective last certification dates and times are associated with each other. By recording the comparison (proof) with the instance in the verification logic as a record of the lower and upper bounds, it is possible to determine whether or not proof can be executed using an individual policy. Note that when executing ZKP using NIZK, the item related to the last proof date and time may be filled with a predetermined value (e.g., 99999999) to treat the last proof date and time as a value in the future from the time of proof execution. As described above, the order of processing such as registration and reference by the management information control unit 110 may be controlled purely in the following order: registration control of data subject information, registration control of verifier information, reference control of data classes, registration and reference control of verification logic formulas, registration control of individual policies, and registration and reference control of verification history. Alternatively, the management information control unit 110 may control the registration of individual policies at any timing, or may control the registration of individual policies in response to receiving a notification from the MPC participating party 9 that a request for certification by the verifier has been received.

[0051] The setup unit 112 generates an algorithm and a signed CRS. When a verification logic formula is deployed, the setup unit 112 generates a protocol for the MPC that allows the MPC to calculate a ZKP corresponding to the verification logic formula. The setup unit 112 also calculates the CRS. When the ZKP scheme requires Trusted Setup, collusion can be made more difficult by cooperation not only from the management server 22 but also from all MPC participating parties 9. The setup unit 112 digitally signs the generated CRS. The setup unit 112 distributes the generated protocol and signed CRS to each MPC participating party 9.

[0052] 7, the verification request acquisition unit 114 acquires a testimony request or an evidence request from the verifier terminal 16 of the verifier 8 via the network. The testimony request and the evidence request include, for example, a data subject ID corresponding value and a verification logic ID of the proof logic formula required by the verifier 8.

[0053] The determination unit 116 determines whether to reject the verification request from the viewpoint of protecting output privacy in response to the acquired verification request. The determination by the determination unit 116 as to whether to reject the verification request is realized by using data stored in the individual policy DB 128 and the verification history DB 142.

[0054] We will now explain more specifically the aspect of output privacy protection (using the query auditing method described above). Generally, propositional functions or ZKPs do not directly reveal the original data to the verifier. However, if there are no restrictions on the verifier's verification of data from the same data class (as shown in the individual policy registration control), repeated verifications may result in the original data being leaked. For example, dealing with chosen plaintexts can be problematic, especially for calculations using classes with a narrow range of possible values.

[0055] For example, regarding age, ●Are you over 50? → False ●Are you over 25 years old? → True ●Are you over 37 years old? → False ●Are you over 31? → True ●Are you over 34 years old? → True ●Are you over 35? → False By repeating the verification process in this way, the exact age cannot be determined from each verification result, but by combining the results of multiple verifications, it is possible to narrow down the range of possible actual ages and identify the data subject as 34 years old.

[0056] In protecting output privacy according to this embodiment, the MPC participating party 9 or service provider 7 plays the role of a circuit breaker in order to maximize the protection of privacy (output privacy) that cannot be fully protected by MPC-ZKP. The MPC participating party 9 or service provider 7 rejects any propositional function or ZKP calculation that significantly compromises privacy according to the verification logic requested by the verifier 8. In that sense, the MPC participating party 9 or service provider 7 plays the role of a circuit breaker in protecting output privacy. Note that the criteria for compromise may be determined based on the nature of the service and agreement with the consumer.

[0057] The output privacy protection function realized by the management server 22 determines the privacy category that the data subject 4 may have known to the verifier 8 using the individual policy DB 128, and protects the data subject 4 from threats to output privacy for data on an ordinal scale or higher using the determination unit 116. The determination unit 116 determines whether to reject the verification request based on the content of the verification request acquired by the verification request acquisition unit 114, the privacy policy held in the individual policy DB 128, and the verification history held in the verification history DB 142.

[0058] More specifically, if a propositional function or ZKP that violates the privacy policy is requested by the verifier 8, the determination unit 116 rejects the calculation (or the determination unit 116 causes the MPC participating party 9 to reject the calculation). Specific examples of privacy policies that can be stored in the individual policy DB 128 are as follows: ●Policy 1: Avoid leaking more than a certain amount of privacy information to a specific verifier within a certain period of time (e.g., within two years). ●Policy 2: Avoid leaking more than a certain amount of privacy information to a specific verifier. ●Policy 3: Avoid leaking more than a certain amount of privacy to all verifiers within a certain period of time. ●Policy 4: Avoid leaking more than a certain amount of privacy to all verifiers.

[0059] The "certain level of privacy" described in the above privacy policy explanation can be set individually for each data subject. For example, it can be determined by conditions such as "I don't want my age to be identified with an error of 10 years (e.g., under 40 and over 30)" or "I don't want my savings to be identified with an error of 1 million yen."

[0060] Such privacy policies are managed for each data subject and type of data (data class) (e.g., age, income, etc.) in the individual policy DB 128. If a propositional function or ZKP contrary to this is requested, the determination unit 116 rejects the verification request to protect the data subject 4 from threats to output privacy.

[0061] If the determination unit 116 approves the verification request, it causes each MPC participating party 9 in the MPC participating party group 10 to execute the proposition function or ZKP and provide the resulting output share to the verifier terminal 16. Alternatively, if the determination unit 116 approves the verification request, it provides the corresponding output share held in the verifier DB 124 to the verifier terminal 16.

[0062] 21 is a representative screen diagram of an output privacy leak notification screen 900 displayed on the display of the data subject terminal 12 of the data subject 4. The output privacy leak notification screen 900 is generated by referring to the verification history DB 142, and presents the data subject 4 with the privacy range leaked by the proposition function or ZKP. In the example shown in FIG. 21, the range of age used for the verification judgment is indicated by diagonal lines. Note that while FIG. 21 uses a one-dimensional display, a two-dimensional display such as a Venn diagram may also be used.

[0063] Fig. 14 is a block diagram showing an example of the functional configuration of the data subject terminal 12 in Fig. 1. The data subject terminal 12 includes a management information request unit 144, a data acquisition unit 146, a data provision unit 148, an individual policy unit 150, and a data deletion request unit 145.

[0064] The management information requesting unit 144 requests management information (particularly a verification logic formula) from the management server 22 of the service provider 7. The management information requesting unit 144 acquires the management information associated with the verification logic ID and displays it on a display. The data subject 4 can view and check the verification logic formula requested by the verifier 8, and can request the data generator 6 to generate the necessary data (for example, to receive a medical examination at a hospital).

[0065] When a signed witness (w, ws) is stored in the data generator DB 14 of the data generator 6 (by the data generator 6 or the data generator terminal 24), the data acquisition unit 146 acquires the signed witness from the data generator DB 14 and registers it in the cache holding unit 152. In addition, the data acquisition unit 146 acquires a necessary instance (e.g., the public key of the data generator 6) from outside and registers it in the cache holding unit 152.

[0066] The data provider 148 converts the signed witnesses (w, ws) stored in the cache holder 152 into shares, and calculates the share (w i , ws i) (i=0 to number of MPC participating parties-1) is provided to each MPC participating party 9 in the MPC participating party group 10 (i.e., secret sharing). The data providing unit 148 provides each MPC participating party 9 with an instance in addition to the share of the signed witness.

[0067] The individual policy setting unit 150 reads data classes from the management server 22 and sets a privacy policy for each data class. For example, in accordance with an operation by the data subject 4, a privacy policy is set for each data class, and the privacy policy is set for the management server. Furthermore, in accordance with an operation by the data subject 4, the individual policy setting unit 150 can set which verifier (verifier ID) is to be given certification permission. The data deletion request unit 145 can request the deletion of shares held by the MPC participating parties 9 of the MPC participating parties 10 . 14, the data subject terminal 12 may further include a data subject registration unit for registering the data subject (the name and address of the data subject) and obtaining a data subject ID that uniquely identifies each verifier. At this time, a signature for the data subject ID information (e.g., information that can confirm authentication by a public institution) may be provided.

[0068] 15 is a block diagram showing an example of the functional configuration of the data generator terminal 24. The data generator terminal 24 includes a verification logic acquisition unit 156, a data observation unit 154, a digital signature unit 158, a data providing unit 160, a share providing unit 161, and a data generator DB 14.

[0069] The verification logic acquisition unit 156 reads the verification logic from the management server 22 and displays it on a display, for example, so that the data creator 8 can confirm and understand the required data and its format. The data observation unit 154 generates data related to the matter to be certified. In an example where the data generator 6 is a doctor or hospital, the generated data may be examination results, specimen analysis results, etc. The data observation unit 154 registers the generated data (for example, witnesses (confidential information) among the generated data) in the data generator DB 14. Note that instances (public information) among the generated data may also be stored in the data generator DB 14. The data observation unit 154 may further register a data subject ID and a data class ID for each piece of data.

[0070] The digital signature unit 158 ​​generates a signed witness by applying a digital signature (for example, a signature with the private key of the data generator) to the data (witness) generated by the data observing unit 154, and registers the signed witness in the data generator DB 14. The digital signature unit 158 ​​may also generate a signature for an instance and register the signature in the data generator DB 14.

[0071] The share providing unit 161 generates signatures and shares of data by sharing the signed witnesses generated by the digital signature unit 158, and also signs each share. The share providing unit 161 can provide the generated signed shares to the MPC participating party 9. Note that the share providing unit 161 may be disabled when shares are provided from the data subject terminal 12 to the MPC participating party 9. On the other hand, as shown in FIG. 19 , the share providing unit 161 is enabled in a configuration in which shares are provided to the MPC participating party 9 from the data generator terminal 24 and data generator DB 14.

[0072] In response to a request from the data subject terminal 12, the data providing unit 160 provides the data of the data subject 4 and the corresponding signed share to the data subject terminal 12. If there is prior consent from the data subject 4, the data providing unit 160 can provide the generated data to other parties.

[0073] The operation of the MPC-ZKP system 2 configured as above will now be described. FIG. 18 is a chart showing the flow of the proof sequence in the MPC-ZKP system 2. FIG. 18 explains the case where zk-SNARKs are used as the ZKP algorithm. The sequence in FIG. 18 corresponds to the above-mentioned MPC zero-knowledge proof mode and user terminal zero-knowledge proof mode. The sequence in FIG. 18 includes steps S802, S804, S806, S808, S810, and S812, of which steps S802 and S804 represent the flow of defining the verification logic by the service provider 7 or verifier 8, steps S806, S808, S810, and S812 represent the ZKP flow, and steps S808 and S810 represent the MPC flow. Note that steps S808 and S810 are executed in the MPC zero-knowledge proof mode, but not in the user terminal zero-knowledge proof mode.

[0074] In this sequence, first, the content to be proven (verified) is specified (step S802), and then a verification logic formula for that content is generated (step S804). The verification logic may be prepared by the verifier 8, or may be prepared in advance by the service provider 7 as "content that is frequently verified." The verification logic formula includes a calculation formula (processing content) and the format of the input data (json, yaml, toml, etc.). A ZKP scheme is also associated with the verification logic formula. There are verification logics for proposition functions and ZKP. In this sequence, the ZKP version is assumed; the proposition function version will be described later. Upon receiving the verification logic formula, the management server 22 issues a verification logic ID.

[0075] The verifier terminal 16 of the verifier 8 or the MPC participating party 9 calculates the verification logic formula required to prove the verification logic and (if Trusted Setup is used) the CRS (step S806). The CRS may be calculated using normal calculations by the MPC participating party 9 (it is not necessary to implement MPC using shared values). However, if the ZKP scheme used requires Trusted Setup, the MPC participating party 9 (and the verifier 8) will work together to perform the Setup phase.

[0076] However, when adopting a scheme that relies on the security of hash functions (random oracle assumption), such as zk-STARKs, Trusted Setup is not required.

[0077] In step S808, data necessary for the proof is acquired. <When calculating ZKP by MPC and assuming third-party provision of data> If the signed shares necessary for verification are not registered, MPC participant 9 requests the signed shares from the data generator terminal 24 of data generator 6 at the request of data subject 4 or service provider 7. Alternatively, the following data provision may also be automatically advanced from the data generator terminal 24 of data generator 6.

[0078] The data generator terminal 24 of data generator 6 acquires the verification logic formula from the management server 22 of service provider 7, and prepares, according to the format of the input data, the signed shares of the required data, that is, the values obtained by secretly sharing (sharing) the plaintext, the values obtained by secretly sharing (sharing) the signature on the plaintext, and the values obtained by signing each share. The data generator terminal 24 distributes each signed share one by one to the MPC participation server 20 of MPC participant 9.

[0079] MPC participant 9 acquires the public key of data generator 6 and verifies the integrity of the signature shares and signed shares received respectively.

[0080] <When calculating ZKP by MPC and not assuming third-party provision of data> If the data necessary for verification is not registered, the data subject terminal​​​​​

[0082] The data subject terminal 12 uses the public key of the data creator 6 to verify the integrity of the digital signature.

[0083] The data subject terminal 12 secretly shares (shares) the plaintext and signature data on the plaintext obtained from the data generator terminal 24 to generate signed shares (e.g., signed witness shares), and distributes each signed share one by one to the MPC participating parties 9.

[0084] The MPC participants 9 obtain the public key of the data producer 6 and verify the integrity of the signed shares (e.g., signed witness shares) that they each receive.

[0085] <When calculating the ZKP on the data subject terminal 12 of the data subject 4> Based on the input data ID associated with the verification logic ID, the local data subject terminal 12 checks whether the data is registered (whether it has been saved or not). If it is not registered, the data subject terminal 12 requests the data required for certification from the data generator terminal 24. The data generator terminal 24 prepares the plaintext of the requested data and a signature for the plaintext. The data generator terminal 24 provides all of this to the data subject terminal 12. The data subject terminal 12 uses the public key of the data generator 6 to check that the signature can be correctly authenticated. The data subject terminal 12 registers the data on the local data subject terminal 12.

[0086] In step S810, the prover computes the ZKP. <If the certifier is MPC participant party 9> The MPC participating party 9 calculates the ZKP based on the verification logic formula associated with the target verification logic ID, or based on the CRS when using Trusted Setup. Note that the calculation of the ZKP may be limited to cases where the verification logic formula satisfies the conditions of the privacy policy of the individual privacy, as described above.

[0087] The resulting ZKP remains shared as an output share, and each output share is held by the MPC participating party 9. At this time, the management server 22 may also issue credentials for authentication to obtain the output share, which is a share of the ZKP, and issue and associate a credential ID. In this case, the service provider 7 directly notifies the verifier of the information associated with this credential ID after obtaining the data subject's prior and subsequent consent. Alternatively, the information associated with the credential ID may be notified to the data subject 4, and the information associated with the credential ID may be communicated only to the party (verifier 8) that the data subject 4 wishes to certify, making it possible to provide a proof associated with the data subject's attributes.

[0088] In this way, by using credentials, the data subject 4 associated with the proof ID can control whether or not the verifier 8 can access the evidence (ZKP) after calculating the ZKP by registering or deleting the credential information (they can determine whether to allow or deny access and instruct the system). The MPC participating party 9 provides online shares of the ZKP output only to verifiers 8 authorized by the data subject 4 (online proof). However, in special cases where it would be inconvenient if the data subject were to become aware of the inquiry, such as inquiries related to investigations, the handling is at the discretion of the service provider and does not apply to this case.

[0089] The calculation result may be distributed to the data subject terminal 12 and may be referred to by the data subject 4 to the verifier 8 (offline proof).

[0090] <When the certifier is the data subject 4 (data subject terminal 12)> The data subject terminal 12 requests the MPC participating party 9 or the management server 22 for the verification logic formula associated with the target verification logic ID, or the CRS if Trusted Setup is used.

[0091] The data subject terminal 12 calculates the ZKP based on the acquired verification logic formula or CRS.

[0092] The calculation result is left on the data subject terminal 12 and is made available for the verifier 8 to refer to at their own discretion (offline proof). Alternatively, it may be deposited with the service provider 7 and made verifiable online by the verifier 8 (online proof). When online proof is enabled, the data subject 4 associated with the proof ID can control whether the verifier 8 can access the proof (ZKP) by registering and deleting the information associated with the credential ID (it can judge permission / non - permission and instruct the system). The MPC participating party 9 provides the output share of the ZKP online only to the verifier 8 who has obtained the permission of the data subject 4 (online proof).

[0093] In step S812, the verifier 8 verifies the ZKP. <When the ZKP holder = MPC participating party 9> The verifier terminal 16 of the verifier 8 obtains the proof (output share of the ZKP) from the MPC participating party 9. Note that the output share of the ZKP may be provided only when the verification logic formula satisfies the privacy policy conditions of individual privacy as described above, or when the verifier 8 is permitted to access the output share by the credential. For example, when performing access control by the credential, the service provider directly notifies the verifier of the information associated with the credential ID after obtaining the prior and post - event commitments of the data subject. Alternatively, the data subject 4 provides the information associated with the credential ID to the verifier 8 in advance. The verifier terminal  16 of the verifier 8 obtains the credential associated with the notified credential ID, the proof (output share of the ZKP), the verification logic formula, or the CRS if Trusted Setup is used, after authenticating the verifier ID. The verifier terminal 16 restores the ZKP (Proof) from the output share and obtains the verification result through the verification procedure (Verify) for the restored ZKP.

[0094] <When the ZKP holder = data subject 4 (data subject terminal 12 of)> The data subject 4 provides the verifier 8 with evidence (the output share of the ZKP) and a verified logic formula with a signature, or a CRS with a signature if Trusted Setup is used. The verifier terminal 16 of the verifier 8 verifies the authenticity of the CRS. The verifier terminal 16 restores the ZKP (Proof) from the output share and obtains a verification result through a verification procedure (Verify) for the restored ZKP.

[0095] Figure 20 is a chart showing the flow of a sequence of proofs (testimonies) by propositional functions in the MPC-ZKP system 2. The sequence in Figure 20 corresponds to the propositional function testimony mode by the above-mentioned MPC. The sequence in Figure 20 includes steps S820, S822, S824, and S826, among which steps S820 and S822 show the flow of the definition of verification logic by the service provider 7 or the verifier 8, and steps S824 and S826 show the flow of the MPC.

[0096] In this sequence, first, the content to be proved (verified) is defined (step S820), and the verified logic formula is generated (step S822). The verification logic can be prepared by the verifier 8 or, as "content that is frequently verified", can be prepared in advance by the service provider 7. The verification logic includes a calculation formula (processing content) and the format of the input data (such as json, yaml, toml, etc.). There are verification logics for propositional functions and for ZKPs. In this sequence, the verification logic for propositional functions is assumed. The management server 22 that receives the verification logic issues a verification logic ID. [[ID=X]]

[0097] In step S824, the data required for the proof is obtained. <When calculating with MPC and assuming third-party provision of data> If the data necessary for verification is not registered, the data generator terminal 24 acquires the verification logic from the management server 22 of the service provider 7, and prepares, according to the format of the input data, the signed shares of the required data, that is, the values obtained by secret sharing (sharing) of the plaintext, the shares of the signature on the plaintext, and the signatures on each share (signed shares). The data generator terminal 24 distributes each share to the MPC participating parties 9 one by one.

[0098] The MPC participating parties 9 acquire the public key of the data generator 6 and verify the integrity of the signature shares and signed shares received respectively.

[0099] <When calculating with MPC and not assuming third-party provision of data> If the data necessary for verification is not registered, the data subject terminal 12 acquires the verification logic formula from the management server 22 of the service provider 7, and requests the data generator terminal 24 for the plaintext of the data necessary for proof and the signature on the plaintext according to the format of the input data.

[0100] The data generator terminal 24 prepares the plaintext of the requested data and the signature on the plaintext. The data generator terminal 24 provides these to the data subject terminal 12.

[0101] The data subject terminal 12 uses the public key of the data generator 6 to verify the integrity by digital signature.

[0102] The data subject terminal 12 secret shares (shares) the plaintext and the signature data on the plaintext obtained from the data generator terminal 24 to generate signed shares (for example, shares of signed witnesses), and distributes each signed share to the MPC participating parties 9 one by one.

[0103] The MPC participating parties 9 acquire the public key of the data generator 6 and verify the integrity of the signed shares (for example, shares of signed witnesses) received respectively.

[0104] In step S826, the prover calculates the propositional function and the verifier 8 verifies the result. The MPC participating party 9 performs the MPC based on the verification logic formula associated with the target verification logic ID and obtains a share of the verification result. Note that the MPC may be calculated only when the verification logic formula satisfies the conditions of the individual privacy policy, as described above. Alternatively, the management server 22 may issue a credential for authenticating the acquisition of the share of the verification result and associate it with a credential ID after issuing it. The management server 22 may notify the data subject 4 of information associated with this credential ID, and when the data subject 4 wishes to certify, the management server 22 may inform the verifier 8 of this information, thereby enabling the verifier 8 to provide a certification associated with the principal's attributes.

[0105] When using credentials, the service provider directly notifies the verifier of the information associated with the credential ID after obtaining the prior and subsequent consent of the data subject. Alternatively, the data subject 4 provides the verifier 8 with the information associated with the credential ID in advance. The verifier 8 obtains the verification result (True / False) using the credential.

[0106] In the flowcharts shown in Figures 18 and 20, the operation of the MPC zero-knowledge proof mode and the operation of the MPC propositional function attestation mode in the entire MPC-ZKP system are described separately. However, as described above, the MPC zero-knowledge proof mode can be executed in appropriate combination with the MPC propositional function attestation mode at the MPC participating party 9, thereby preventing falsification in the MPC propositional function attestation mode. Furthermore, by taking privacy policies into consideration when the MPC participating party 9 performs propositional function or ZKP calculations, it becomes possible to appropriately control the leakage of privacy. Below, an example of the operation of the MPC participating party 9 that realizes these functions will be described with reference to Figure 25. Note that the operation of the MPC participating party 9 is realized by a processor executing a program stored in the memory of the MPC participating party 9. In S2501, the processor of the MPC participating party 9 obtains a signed witness share from the data subject terminal 12 or the data generator terminal 24, and then uses the public key of the data generator terminal 24 to verify that the obtained signed witness share has not been partially tampered with. In S2502, the processor of the MPC participating party 9 accepts a verification request, which is either a testimony request or an evidence request, from the verifier terminal 16. At this time, the processor identifies the data subject ID corresponding value and the verification logic ID related to the verification request. Then, in S2503, the processor acquires a verification logic formula (from the management server 22) based on the verification logic ID. In S2504, the processor of the MPC participating party 9 determines whether the execution of the verification logic formula is within the protection range of the privacy policy. Specifically, from the data in the verification history DB and individual policy DB described above, the processor obtains the comparison results associated with the data subject ID corresponding value related to the verification request and information on the protection range of the data class, and determines whether the execution of this verification logic formula will narrow down the data to within the protection range of the data class set as the privacy policy. In S2505, if the processor determines that the verification logic formula is within the protection range, it proceeds to S2506; if not, it terminates this processing. In S2506, the processor of the MPC participating party 9 determines whether the requested verification request is an evidence request (i.e., a request to execute a ZKP). For example, the processor makes the determination in this step depending on whether the verification request received from the verifier terminal 16 is an evidence request or a testimony request. If the verification request is an evidence request, the processor executes the ZKP in S2508, and if the verification request is a testimony request, the processor executes the proposition function in S2507. In S2509, the processor of the MPC participating party 9 provides the output shares obtained as a result of processing the proposition function or ZKP to the verifier terminal 16. The verifier terminal 16 reconstructs the output shares sent from each MPC participating party 9 to restore the result. Once the processor of the MPC participating party 9 provides the output shares to the verifier terminal 16, this series of operations ends. In the above-described embodiments, examples of the storage unit are a hard disk and a semiconductor memory. Furthermore, based on the description in this specification, it will be understood by those skilled in the art that each unit can be realized by a CPU (not shown), an installed application program module, a system program module, a semiconductor memory that temporarily stores the contents of data read from a hard disk, or the like.

[0107] According to the MPC-ZKP system 2 of this embodiment, a privacy-protecting entrusted attribute prover can be realized by combining MPC and ZKP. In particular, even when the data subject is not present, proof based on the data subject's raw data (privacy information) can be performed without disclosing the raw data.

[0108] Proofs calculated on the user's own terminal may lack persuasiveness. In such cases, the MPC-ZKP system 2 according to this embodiment verifies the authenticity of the data using the public key of the data generator (e.g., hospital, government office, etc.), and then provides proof, which is equivalent to testimony by a third party and therefore more persuasive.

[0109] In the MPC-ZKP system 2 according to this embodiment, a data generator 6 creates data and affixes a digital signature to it. There may be multiple data generators 6. For example, consider a case where (1) the hospital that performed the PCR test and (2) the service provider of the location information service are both data generators 6. Only when both the test results and location information (whether the person is near a cluster occurrence location) are verified by ZKP and found to be false (negative and not near a cluster location) can border or prefectural border authorities grant permission for the person to enter the country. In the MPC-ZKP system 2, the data generators 6 who created each piece of information (data) of different natures (test results, location information) individually sign the respective pieces of information, thereby increasing the reliability of the certifications provided by the MPC-ZKP system 2.

[0110] As mentioned above, there are two ways to testify. 1. Only provide the results of propositional functions by MPC (ZKP is not created) It returns True or False in response to a request to execute a function that returns a boolean value (proposition function). Only functions that have been authorized to be executed by the data subject can be executed. In this case, no evidence is created that the calculation process was performed correctly, making it a weak basis. If there are concerns about the high computational cost of performing ZKP using MPC, or a lack of communication bandwidth or storage space, it is suitable for preliminary checking only True / False using the proposition function using MPC. If the result is suspicious or if a ZKP is requested unexpectedly (randomly), it becomes difficult for the prover (service provider, MPC calculator) to easily fabricate a conclusion in response to a request to the proposition function, given the possibility of a contradiction occurring between the conclusion of the proposition function and the ZKP. 2. Provide ZKP calculated by MPC The proof provides a strong basis because it can include the validity of the computational process leading to the conclusion. This acts as a deterrent to fabrication in the testimony of the propositional function mentioned in 1. Furthermore, various conditions can be attached to the proof content of a ZKP, such as whether the signature is authenticated or not.

[0111] The above describes the configuration and operation of the MPC-ZKP system 2 according to the embodiment. This embodiment is an example, and it will be understood by those skilled in the art that various modifications are possible in the combination of each component and each process, and that such modifications are also within the scope of the present invention.

[0112] In the embodiment, the case where the data subject 4 and the data generator 6 are separate has been described, but this is not limiting. For example, the functions of the data generator terminal 24 may be realized by an application that runs on a TEE (Trusted Execution Environment) of the data subject terminal 12.

[0113] If the functions of the data creator terminal 24 are realized by an application that runs locally on the data subject terminal 12, a normal application would allow the data subject 4 to easily tamper with the data. For this reason, an application that runs on the TEE is used here.

[0114] With normal applications, there is a possibility that the programs and data may be accessed by the OS (Operating System). In this case, there is a possibility that the programs and data may be easily tampered with. On the other hand, it is extremely difficult to tamper with the programs and data of applications that run on a TEE. The reason this is difficult is that the TEE is an environment that is hardware-isolated from the OS, and it is difficult for applications that run there to tamper with the programs and data. In other words, the integrity of the code and data is protected. Since the data subject terminal 12 is a local terminal, this is not a perfect defense, but it is safe as long as a side-channel attack is not successful.

[0115] Applications running on this TEE acquire information from external devices (peripherals) that can be operated from the TEE, i.e., sensors (GPS receivers, thermometers, etc.) connected via wireless interfaces, and format, analyze, and interpret this information.

[0116] The application on the TEE shares and signs the results of the acquisition and calculation, and distributes them to the MPC participating parties 9. Just before distributing the shares, the application may ask the user, along with a privacy policy, whether it is OK to distribute them. In this way, the "data generator 6" can be replaced with the "application on the data subject terminal 12." [Explanation of symbols]

[0117] 2 MPC-ZKP system, 4 data subject, 6 data generator, 8 verifier, 10 MPC participating parties, 12 data subject terminal, 14 data generator DB.

Claims

1. A system for performing zero-knowledge proof in secret sharing-based multi-party computation, the system including a plurality of devices participating in the multi-party computation and a verifier terminal, Each of the plurality of devices comprises: An acquisition means for acquiring a share of data related to an item to be proved, the data being distributed by a secret sharing-based multi-party computation method; a first output means for, when receiving a request for testimony, receiving a share of data related to the matter to be proved as an input and outputting an output share of a proposition function of the data related to the matter to be proved; and a second output means for, when receiving a request for verification using the zero-knowledge proof, outputting a share of a proof of the zero-knowledge proof using a share of data related to an item to be proved as an input, The verifier terminal, Reconstructing output shares of the proposition function collected from a plurality of devices participating in the multi-party computation to obtain testimony related to the matter to be proved; A request for verification by the zero-knowledge proof is made, a share of the proofs of the zero-knowledge proof collected from a plurality of devices participating in the multi-party computation is reconstructed, a proof is obtained, and the testimony is verified by the proof. system.

2. The apparatus comprises:

2. The system of claim 1, further comprising means for verifying that the original data of the obtained share has not been tampered with using a digital signature associated with the obtained share.

3. 3. The system of claim 1 or 2, wherein the zero-knowledge proof is of the type that uses a verification logic formula or a Common Reference String (CRS).

4. The system according to claim 3 , wherein the CRS in the case of a trusted setup is generated by a plurality of devices participating in the multi-party computation or the verifier terminal working together.

5. The system according to claim 1 , wherein a request for verification in the zero-knowledge proof is randomly or arbitrarily requested from the verifier terminal.

6. The system according to claim 5, wherein the verification in the zero-knowledge proof is performed after a verifier terminal performs verification by computing a proposition function using output shares collected from multiple devices participating in the multi-party computation.

Images