Apparatus and system for zero - knowledge proofs for multiparty computation

Abstract

The present invention provides a device and a system for zero-knowledge proof implemented by multi-party computation, which implement a proof service with higher user convenience and a technology capable of reducing the risk of leakage of private information. The device of the present invention is one of a plurality of devices participating in multi-party computation, which is installed with a protocol for zero-knowledge proof implemented by multi-party computation based on secret sharing, and includes: an acquisition unit that acquires shares of data on a matter to be proved; and an output unit that outputs an output share obtained as a result of calculating according to the protocol with the acquired shares as inputs. Verification in zero-knowledge proof can be performed based on the output shares collected from a plurality of devices participating in multi-party computation.

Description

Technical Field

[0001] The present invention relates to an apparatus and a system for zero - knowledge proofs for execution with multi - party computation. Background Art

[0002] In recent years, techniques related to zero - knowledge proofs have been known. A zero - knowledge proof (ZKP) is a technique for proving to a counterpart that one knows a piece of knowledge (secret) or that the knowledge (secret) has a certain property or satisfies a condition without disclosing the knowledge (secret) one has to the counterpart. However, ZKP must have the following three properties: completeness (if the proposition that the prover attempts to prove is true, then the property that the verifier can necessarily be convinced), soundness (if the proposition that the prover attempts to prove is false, then the property that the persuasion will fail with a high probability), and zero - knowledge (the knowledge obtained by the verifier from the result of the prover's proof of a certain proposition is only the property that the proposition is true. That is, the property that the verifier can simulate the validity of the proof even without having the knowledge). Standardization of terms related to ZKP and the characteristics of each method is in progress, and this article basically follows this standard (refer to Non - Patent Document 1).

[0003] On the other hand, multi - party computation (MPC) is an encryption technique that can derive a computation result while keeping the input values confidential. In particular, a computational method in which an input value equivalent to a secret is secretly shared into multiple shares using a k - out - of - n threshold secret sharing method (n≥k≥2), and the participating parties holding each share execute a prescribed procedure (protocol) to derive the computation result is called multi - party computation based on secret sharing. This computational method can have Functional Completeness, and implementation examples of various two - party computation protocols are described in Non - Patent Document 2.

[0004] Currently, with the call for the digitization of social infrastructure, privacy protection has become an urgent issue, and ZKP and MPC have received attention as effective countermeasure solutions.

[0005] Prior Art Documents

[0006] Non - Patent Documents

[0007] Non - Patent Document 1: ZKProof Community Reference, Version 0.2, December 31, 2019, URL: https: / / docs.zkproof.org / pages / reference / reference.pdf

[0008] 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

[0009] Problems to be Solved by the Invention

[0010] There are numerous cases where an individual or an organization requests a proof to an external verifier. Most modern proof acts are completed by disclosing a certificate issued by a third-party institution or information possessed by the individual (organization) itself to the verifier.

[0011] However, in the process of the proof act, there are numerous cases where the information given to the verifier includes unnecessary content both in quantity and quality. For example, as a means of proving that "I am an adult" when purchasing alcohol, it may be completed by presenting the driver's license of the prover, that is, oneself, and notifying the date of birth to the seller of alcohol, who is the verifier. In this example, in addition to the fact that "I am an adult", it includes redundant information both in quantity (actual age) and quality (address, etc.).

[0012] That is, there is a need for a proof method that requests to limit the leakage of the above unnecessary privacy information (information beyond the conclusion of the proposition to be proven) and has sufficient persuasiveness for the verifier without sacrificing convenience.

[0013] The above problems can be conditionally solved by known zero-knowledge proofs. However, the person who requests the zero-knowledge proof calculation Prove processes privacy information (knowledge of plaintext) and calculates. Therefore, in the case of entrusting a proof act to another person, it is necessary to disclose privacy information to the entrusted party. As a typical example, in the case of proving based on the privacy information of two people, when entrusting a proof act to one of the two people or a third party, it is a premise that the privacy information of at least one of the two people is known to someone other than the person himself. Problems occur when a person who does not want to disclose unnecessary privacy information receives a request for a proof based on that privacy information.

[0014] The present invention has been made in view of the above problems. Its object is to realize a proof service with higher user convenience or a technology capable of reducing the risk of leakage of privacy information.

[0015] Technical Solution for Solving the Problems

[0016] One aspect of the present invention relates to a device. The device is one of a plurality of devices participating in multiparty computation, which is installed with a protocol for performing zero-knowledge proof using multiparty computation based on secret sharing, and includes: an acquisition unit that acquires a share of data on a matter to be proved; and an output unit that outputs an output share obtained as a result of calculating the acquired share as an input according to the protocol. Based on the output shares collected from the plurality of devices participating in multiparty computation, verification in zero-knowledge proof can be performed.

[0017] Another aspect of the present invention is a system. The system is a system for performing zero-knowledge proof, and includes: a policy storage unit that stores a privacy policy; a history storage unit that stores a history of verification; a unit that acquires a verification request from a verifier; and a unit that determines whether to reject the verification request based on the content of the acquired verification request, the privacy policy stored in the policy storage unit, and the history of verification stored in the history storage unit.

[0018] In addition, any combination of the above components and the result obtained by mutually replacing the components of the present invention with those expressed in devices, methods, systems, computer programs, recording media storing computer programs, etc. are also effective as aspects of the present invention.

[0019] Effects of the Invention

[0020] According to the present invention, a proof service with higher user convenience can be realized, or the risk of leakage of privacy information can be reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a schematic diagram showing the structure of the MPC-ZKP system of the embodiment.

[0022] Figure 2 It is for explaining Figure 1 the confidentiality of the advantages of the MPC-ZKP system used.

[0023] Figure 3 It is for explaining Figure 1 the logical transparency of the advantages of the MPC-ZKP system used.

[0024] Figure 4 It is a diagram showing the characteristics of the proof modes implemented in the MPC-ZKP system in tabular form.

[0025] Figure 5 It is Figure 1 the hardware structure diagram of the MPC participant (also called the MPC participant server) of

[0026] Figure 6 It is showing Figure 1Block diagram of the functional structure example of the MPC participants of the MPC participants.

[0027] Figure 7 It represents for the purpose of management Figure 1 Block diagram of the functional structure example of the management server used by the service provider for the MPC participant group.

[0028] Figure 8 It represents Figure 7 Data structure diagram of an example of the verification logic expression DB.

[0029] Figure 9 It represents Figure 7 Data structure diagram of an example of the data subject DB.

[0030] Figure 10 It represents Figure 7 Data structure diagram of an example of the data class DB.

[0031] Figure 11 It represents Figure 7 Data structure diagram of an example of the verifier DB.

[0032] Figure 12 It represents Figure 7 Data structure diagram of an example of the individual policy DB.

[0033] Figure 13 It represents Figure 7 Data structure diagram of an example of the verification history DB.

[0034] Figure 14 It represents Figure 1 Block diagram of the functional structure example of the data subject terminal.

[0035] Figure 15 Block diagram of the functional structure example of the terminal of the data producer, that is, the data producer terminal.

[0036] Figure 16 It represents Figure 1 Block diagram of the functional structure example of the verifier terminal.

[0037] Figure 17 Data structure diagram of an example of the verification logic expression DB of the verifier terminal 16.

[0038] Figure 18 Diagram showing the process of the sequence of proofs in the MPC-ZKP system.

[0039] Figure 19 Schematic diagram showing the structure of the MPC-ZKP system in the case where the data producer provides consent to a third party.

[0040] Figure 20 This is a diagram showing the process of a sequence of proofs (testimonies) using propositional functions in the MPC-ZKP system.

[0041] Figure 21 This is a representative screen diagram of an output privacy leakage notification screen displayed on the monitor of the data subject's data subject terminal.

[0042] Figure 22 This is a data structure diagram showing an example of the input value DB in MPC participant 9.

[0043] Figure 23 This is a data structure diagram showing an example of the additional information DB in MPC participant 9.

[0044] Figure 24 This is a data structure diagram showing an example of the share DB in the share storage unit of MPC participant 9.

[0045] Figure 25 This is a flowchart showing a series of actions in MPC participant 9. Detailed Implementation Manner

[0046] Hereinafter, the implementation manner will be described in detail with reference to the accompanying drawings. In addition, the following implementation manner does not limit the invention of the claimed scope of rights, and not all combinations of the features described in the implementation manner are necessarily essential for the invention. Two or more of the multiple features described in the implementation manner can be arbitrarily combined. In addition, the same reference numerals are attached to the same or similar structures, and repeated descriptions are omitted.

[0047] (Implementation Manner)

[0048] The implementation manner relates to an MPC-ZKP system that realizes a delegated attribute prover with privacy protection by combining the use of multi-party computation based on secret sharing, which is one of the secret computations, and ZKP.

[0049] In the MPC-ZKP system of this implementation manner, by combining the use of MPC and ZKP, for the data released by the data subject, it is possible to consistently exclude the behavior of exposing too much privacy other than the conclusion of the proposition for which proof is requested during the custody of the data, the calculation based on the data, the output of the calculation result, and the verification of the result output. In other words, it is possible to protect privacy with MPC and ZKP and limit the leakage of output privacy using the query monitoring method.

[0050] The main features (but not limited to this) of the MPC-ZKP system of this implementation manner are as follows.

[0051] 1. Privacy Protection during Proof

[0052] In the MPC-ZKP system of this embodiment, for the entrusted party or verifier of the proof, it is not necessary to deliver data including privacy in an understandable state. In the MPC-ZKP system, the following two mechanisms are used to protect privacy. Their respective details will be described later.

[0053] ● Input privacy protection function (secret calculation, ZKP)

[0054] ● Output privacy protection function (query auditing method)

[0055] 2. Logical transparency of verification

[0056] In the MPC-ZKP system of this embodiment, while showing the conclusion of verification, the logic of verification can be made unique and transparent. In addition, data is managed in pairs of digital signatures and messages. Based on this as a Witness, "the integrity of the message can be verified with the signature and public key" is included in the verification logic (Relation) of ZKP, thereby enabling the origin (data generator) of the data to be clarified.

[0057] 3. Generalization of verification

[0058] In the MPC-ZKP system of this embodiment, verifications with the same theme are generalized, and the data (Witness and Instance) required for verification is classified, thereby enabling single-shot implementation or multiple verifications on the same data (Witness and Instance). In addition, a Witness is non-public information used for verification, and an Instance is public information used for verification.

[0059] 4. Offline proof

[0060] As described later, depending on the ZKP scheme, with the calculated results that have been proven, it is possible to convince not only the original verifier but also multiple verifiers later (it is Transferable). Utilizing this property, it is possible to save the proof result only in a portable terminal (deleted from the entrusted party of the proof), and the holder (user) of the terminal can prove to the verifier face-to-face or via a dedicated line.

[0061] 5. Entrustment of proof, proxy proof

[0062] In the MPC-ZKP system of this embodiment, the person (data subject) who wants to keep the data confidential can, even if unable to perform the proof act for some reason and even without knowing the proof method (e.g., the calculation method of ZKP), provide the proof trustee (the provider of the MPC-ZKP system) with the data by simply preparing the data, partitioning the data, and sharing it secretly, so as to perform the verification requested by the verifier. The advantage of being able to prove on behalf is recognized, for example, in situations such as the person being absent (or dead, missing), temporary loss of authority due to terminal loss, lack of information technology literacy, or being interrogated by the authorities. Even if the proof is performed on behalf in this way, privacy protection can be achieved as described above.

[0063] 6. Enhancement of the persuasiveness of simple testimony (propositional function)

[0064] For a certain proposition, even if the proof trustee calculates the propositional function of the MPC and successfully outputs the verification result (testimony) while protecting the privacy of the data on which it is based, simply presenting the testimony alone may not necessarily convince the verifier. This is because there is a possibility that the trustee (the person who executes the propositional function of the MPC) colludes with the principal (data subject, etc.) to deceive the verifier, or the data subject presents false evidence to the verifier, or an incorrect verification result is derived due to the incompetence of the prover (errors or defects in the proof calculation). In other words, in simple proxy proof, simply presenting the output of the propositional function is unconvincing. For example, providing the execution result of the propositional function of the MPC is equivalent to such simple testimony.

[0065] In the MPC-ZKP system of this embodiment, a function is provided for the verifier to deliberately or randomly output a Proof (evidence) of ZKP for a proposition that is exactly the same as the previously executed propositional function. That is, for the above simple testimony, a function is set to suddenly check the correctness of the conclusion and the propriety of the verification logic process used. The effect is to restrain the proof trustee from making illegal testimony.

[0066] Through the above mechanism, in the entrusted party of the proof, a stronger motivation for not giving false testimony is generated. This is because if giving false testimony is known, it will significantly damage the credibility. That is, from the perspective of game theory, by deliberately embedding a mechanism that makes it difficult to give false testimony in the proof system, the simple testimony (the result of the propositional function) can have stronger persuasiveness. As a result, while reducing the chance of calculating ZKPs with high computational costs, the persuasiveness of the simple testimony, that is, the output result of the propositional function of MPC, can obtain persuasiveness equivalent to that of ZKPs. As an application, when the output result of MPC for any computational program f(x) based on the secret x is y, the proposition "the result of f(x) is y" can be proved, so a stronger motivation for not outputting the wrong calculation result of f(x) can be promoted.

[0067] 7. Solution to the combinatorial explosion of the prover and verifier in Interactive ZK

[0068] When calculating Interactive ZK, from the start to the end of the proof, the prover and the verifier must be able to communicate (must be online with each other). Especially when the data subject uses their own terminal to prove, the combination of "verifier: prover" becomes a "many: many" relationship, and a so-called combinatorial explosion will occur. In the MPC-ZKP system of this embodiment, while protecting privacy, the role of the prover of multiple data subjects can be entrusted to the MPC participants, and they can be centralized to one party. As a result, the combination of "verifier: prover" is transformed into a "many: one" relationship.

[0069] 8. Proof using the Witness of more than two data subjects

[0070] In the existing ZKPs that use the plaintext Witness, when proving based on the secrets (Witnesses) of multiple data subjects, one of the following methods needs to be adopted.

[0071] (1) Collect the Witnesses of each data subject into the environment of a trusted third party and request to calculate the ZKP here. In this case, it is necessary to abandon privacy protection against the environment of the trusted third party (TTP, Trusted Third Party).

[0072] (2) Each data subject calculates the proof based only on their own Witness. However, in this case, it becomes difficult to prove the information based on the combined (e.g., totaled) information of the two, and the Proof (evidence) increases corresponding to the number of data subjects, and there is a risk of leakage of the output privacy of each data subject.

[0073] On the other hand, in the MPC-ZKP system, for the Witness of each data subject, privacy protection (secret sharing) is performed for everyone other than the data subject himself / herself. Therefore, it is possible to protect the Witness of all data subjects and calculate a proof based on the Witnesses of multiple data subjects.

[0074] Figure 1 FIG. 4 is a schematic diagram showing the structure of the MPC-ZKP system 2 according to the embodiment. In this example, it is assumed that a patient visits a doctor and notifies the result to an administrative agency such as a border or prefectural border. The MPC-ZKP system 2 includes a data subject terminal 12 held by a data subject 4 such as a patient, a data generator database (DB) 14 that stores the data generated by data generators 6 such as doctors and hospitals and their shares, an MPC participant group 10 composed of multiple MPC participants 9 participating in MPC, a management server 22 that manages the management information of any MPC participant group 10, and a verifier terminal 16 held by a verifier 8 such as an administrative agency at a border or prefectural border. In each MPC participant (sometimes also referred to as an MPC participant server) included in the MPC participant group 10, a protocol for performing ZKP using MPC is installed. Each component of the MPC-ZKP system 2 (data subject terminal 12, data generator DB 14, each MPC participant in the MPC participant group 10, verifier terminal 16) is communicably connected to each other via a network such as the Internet. In addition, in this embodiment, the case where the data subject terminal 12 and the data generator DB 14 are separately configured is taken as an example for explanation, but the data generator DB 14 may also be included in the data subject terminal 12.

[0075] The provision method of ZKP in the MPC-ZKP system will be described. Generally, the calculation process of ZKP can be classified into three steps: Setup, Prove, and Verify. In this embodiment, Prove is implemented using MPC. That is, after the Witness is secretly shared using the k-out-of-n threshold secret sharing method (n≥k≥2) to make it a non-public value, the Prove step with the Witness as the input value is performed using multi-party computation (MPC) based on secret sharing. In addition, a prime number q, a generator g, and i∈{0,1,…,n−1} based on a security parameter l are set, where n is the number of MPC participants, and they are used as public values. In addition, the Witness is represented by w, and the shares obtained by secretly sharing w using the k-out-of-n threshold secret sharing method are represented by {w0,w1,…w n-1} is represented. w i is for the MPC participant P iDistributed. In the k-out-of-n threshold secret sharing method, it is possible to reconstruct using the shares held by more than k MPC participants out of n, where n≥k≥2. With MPC that satisfies functional completeness, all ZKPs can be realized.

[0076] zk-SNARKs and Groth-Sahai require a trusted setup. A trusted setup is a way to prepare for a zero-knowledge proof of a certain proposition by requesting a trusted party to perform a setup. For example, the participating parties encrypt random numbers and publicly disclose their values as CRS. It has the weakness that false proof can be made when the prover learns the random numbers (soundness is threatened). Therefore, multiple parties participate and cooperate during the trusted setup, and using properties such as homomorphicity, they release the CRS obtained by adding the random numbers of each party. Thus, as long as at least one of all the participating parties refuses to provide the random number, false proof can be prevented. Especially in some implementations such as Ligero and Sonic, which are subclasses of zk-SNARKs, the required trust can be reduced.

[0077] In the present invention, the MPC participants are trusted in the position of holding the secret shares, and multiple parties (n≥2) are configured, so all or part of the MPC participants can also serve as the duties of the trusted parties.

[0078] As an example, the steps of zk-SNARKs are shown (the following 1. to 3.).

[0079] 1. Calculation of the trusted setup jointly performed by the MPC participants

[0080] QAP<-Compile(relation)

[0081] CRS<-Setup(QAP)

[0082] Among them, relation is the verification logic expression corresponding to the verification logic, QAP is the Quadratic Arithmetic Program (or R1CS can also be used) corresponding to relation (the verification logic expression), CRS is the Common Reference String, CRS = {pk, vk}, pk is the ProvingKey, and vk is the Verification Key (hereinafter, CRS may sometimes be recorded as additional information).

[0083] 2. Prove performed by MPC

[0084] π i <-Prove(CRS, x, w i )

[0085] Among them, x is the Instance.

[0086] MPC participant P i provides π to the verifier i .

[0087] 3. Verify performed by the verifier

[0088] π <- Reconstruct(π0, π1, …, π n-1 )

[0089] {accept, reject} <- Verify(CRS, x, π)

[0090] Among them, accept is to accept the proof, and reject is to reject the proof.

[0091] The data subject 4 is the patient in this example, the holder of the provided data, or the person with the right to privacy. The data subject 4 is not limited to an individual and can also be an organization.

[0092] The data generator 6 is the person who observes the phenomenon and digitizes it. It is also the first data manager where the data subject 4 initially deposits the data. In this example, the data generator 6 is the doctor / hospital that examines the patient, or acquires, analyzes the subject, and digitizes the data. In other examples, the data generator 6 is the service operator that observes the phenomena detected by the observation terminal and sensors, etc., and digitizes them.

[0093] The service provider 7 is the operator of the service that uses the MPC-ZKP system 2. The service provider 7 operates the MPC participant group 10, or entrusts the operation to a third party. The service provider 7 receives the share of the custody data from the data generator 6 (the first data manager) via the data subject 4, so it can also be called the second data manager. It can also be called the data processor in the third-party provided version described later.

[0094] The MPC participant 9 is a server that performs secret calculations and calculates (data processing) on testimonies (propositional functions) or evidences (ZKP), and is each server that constitutes the MPC participant group 10. In the MPC participant group 10, there are multiple MPC participants 9, and there are cases where MPC is performed between servers under the jurisdiction of the same organization, and cases where MPC is performed between servers (or nodes) under the jurisdiction of different multiple organizations.

[0095] The verifier 8 is a person who uses the evidence and testimony (ZKP, output of a propositional function) made by the second data manager (service provider, MPC participant), which is the administrative authority such as the national border or county border in this example. The verifier 8 is the person who verifies the proof and testimony. There is also a case where the service provider 7 is the verifier 8.

[0096] The management server 22 is a server managed by the service provider that uses the secret calculation and zero-knowledge proof scheme in the MPC-ZKP system 2 and has jurisdiction over the MPC participant group 10. The management server 22 registers and stores the verification logic expressions (sometimes also called logical / arithmetic operation circuits) generated by the verifier 8, and in response to requests from the data subject terminal 12, the data generator terminal 24, and the MPC participant 9, provides the verification logic expressions to the request source.

[0097] Reference Figure 1 , describe the process of generating verification data, calculating proofs, and verifying from the registration of verification content in the MPC-ZKP system 2. Additionally, assume that the data subject 4 and the verifier 8 have been pre-registered as users in the management server 22 of the service provider 7, and the issuance of the data subject ID and the verifier ID has been completed respectively.

[0098] (1) The verifier 8 registers the verification logic expression from the verifier terminal 16 to the management server 22 that has jurisdiction over the MPC participant group 10. At this time, the management server 22 assigns a verification logic ID to the verification logic expression.

[0099] (2) The data subject terminal 12 confirms the verification logic ID requested by the verifier 8 and reads the verification logic expression associated with the verification logic ID from the management server 22 that has jurisdiction over the MPC participant group 10. The data and data types (data forms and requirements) for proof and the calculation method (propositional function, calculation method of ZKP) are uniquely determined according to the verification logic expression. Thus, the data subject 4 determines the observed phenomenon and the data generator 6 (such as a doctor / hospital, public institution) that generates the necessary data.

[0100] (3) The data subject 4 (patient) (via the data subject terminal 12) notifies the data generator 6 (such as a doctor / hospital, public institution) of the verification logic ID. The data generator terminal 24 reads the verification logic expression associated with the verification logic from the management server 22. The data and data types (data forms and requirements) for proof are uniquely determined according to the verification logic expression. When the data subject 4 (patient) is observed (such as examined / checked, identity confirmed) and evaluated by the data generator 6 (such as a doctor / hospital, public institution), the data generator terminal 24 reads the data of the evaluation result.

[0101] (4) The data producer terminal 24 processes the read data into the form of data classes and performs a digital signature using the private key sk of the public key encryption method of the data producer 6. In addition, the public key pk of the data producer 6 can be obtained using PKI or the like, for example. Let the generated data be w. Let the digital signature of the data be ws. The group of (w, ws) is called a signed witness. The data producer terminal 24 stores the generated signed witness (w, ws) in the data producer DB 14.

[0102] (5) The data subject terminal 12 obtains and reads the signed witness (w, ws) from the data producer DB 14. In order to verify the validity of the received signed witness (w, ws), the data subject terminal 12 uses the public key pk of the data producer obtained from PKI or the like to confirm that the integrity verification using the digital signature is successful. The data subject terminal 12 performs a k-out-of-n threshold secret sharing (n ≥ k ≥ 2) on the signed witness (w, ws). Let the shares obtained by secret sharing w be {w0, w1, …, w n-1}. Similarly, let the shares obtained by secret sharing ws be {ws0, ws1, …, ws n-1}. The group of (w i , ws i ) is called the share of the signed witness. Among them, i ∈ {0, 1, …, n}, and n is the number of participants in the MPC participant group 10.

[0103] (6) When the data subject terminal 12 receives an operation indicating that the data subject 4 agrees to the processing content (= verification logic expression, privacy policy) associated with the verification logic ID, it sends the share of the signed witness (w i , ws i ) to each MPC participant Pi of the MPC participant group 10. i )

[0104] (7) The MPC participant group 10 uses the share of the signed witness (w i , ws i ) in each MPC participant Pi and the public key pk of the data producer 6 obtained from PKI or the like to perform calculations using the testimony (propositional function) of the MPC based on the verification logic expression associated with the verification logic ID. Each MPC participant P i obtains the share τ i of the testimony.

[0105] (8) The verifier 8 receives the notification of the data subject ID from the data subject 4. The verifier terminal 16 of the verifier 8 receives from each MPC participant Pi of the MPC participant group 10 iReceive authentication and obtain the output shares {τ0, τ1, …, τ i} of the testimony associated with both the verification logic ID and the data subject ID from the MPC participant group 10 {obtain τ i from the MPC participant P i ). Perform Reconstruct (i.e., collect the secret-shared values and restore them to the original values) to obtain the testimony τ. When the verifier 8 does not recognize the testimony τ, input this situation to the verifier terminal 16. When the verifier terminal 16 receives an input indicating non-recognition of the testimony, it requests the evidence (Proof) obtained by zero-knowledge proof from the MPC participant group 10. Alternatively, when the verifier 8 does not deny τ, the verifier terminal 16 can also randomly request zero-knowledge proof from the MPC participant group 10.

[0106] (9) When receiving a request for the evidence (Proof, i.e., the output of the above Prove step) obtained by zero-knowledge proof, each MPC participant P i of the MPC participant group 10 performs calculations using ZKP of MPC based on the verification logic expression associated with the verification logic ID. When the ZKP scheme (type of ZKP) registered in the verification logic expression associated with the verification logic ID is, for example, NIZK (Non Interactive ZK), the MPC participant P i obtains the output shares {π0, π1, …, π n-1} of the evidence (Proof) as the proof result. On the other hand, when the ZKP scheme registered in the verification logic expression associated with the verification logic ID is, for example, Interactive ZK, the MPC participant P i : (1) Sends a commitment to the verifier terminal 16 of the verifier 8, (2) after the verifier terminal 16 of the verifier 8 sends a challenge to each MPC participant P i of the MPC participant group 10, (3) the MPC participant P i obtains the output shares {π0, π1, …, π n-1} of the evidence (Proof) as the proof result. Here, (2) and (3) may be repeated (Soundness Amplification).

[0107] (10) The verifier terminal 16 of the verifier 8 receives authentication from the MPC participant group 10 using a credential or the like and obtains the output shares {π0, π1, …, π n-1} of the evidence (Proof) associated with both the verification logic ID and the data subject ID from the MPC participant group 10 {obtain π i from the MPC participant P i) Perform Reconstruct to obtain the evidence (Proof), i.e., π. Additionally, corresponding to the ZKP scheme registered in the verification logic expression, obtain the CRS (additional information) required for the above-mentioned Verify from the MPC participant group 10. Calculate Verify, and the verification content is accepted (Accept) or rejected (Reject) by the verification terminal 16 of the verifier 8.

[0108] Figure 1 In the MPC-ZKP system 2, as long as the MPC participant group 10 can collect data belonging to the same person created by multiple data producers, it can perform multi-party proof regarding the same person. In the past, it was necessary to collect the documents issued by the data producers and present them to the verifier for verification. Most of the information included in such documents is redundant information that the verifier may not need to know originally. Figure 1 In the MPC-ZKP system 2, the MPC participant group 10 simultaneously performs the proof of purpose while protecting privacy.

[0109] In addition, by confidentially collecting data of different persons, the MPC participant group 10 can perform the proof of combining data of different persons without leaking privacy. In existing ZKPs, in order to perform the same processing, it is necessary to configure plaintext on the same computer for calculation. In this way, the privacy of at least one of the two persons will be leaked to someone other than the person himself / herself. Regarding this point, Figure 1 In the MPC-ZKP system 2, the MPC participant group 10 simultaneously performs the proof of purpose while protecting the privacy of multiple persons.

[0110] In addition, there is a possibility of issuing a new data subject ID to the data subject 4 and the old data subject ID separately and then performing the proof using the latter's data subject ID. As a result, it is possible to control so that the verifier cannot associate the past verification content by identity.

[0111] As Figure 1 an application example of the MPC-ZKP system 2, consider the case of applying it to the situation of judging whether to allow movement when the coronavirus spreads and movement between regions is restricted. When moving between regions, the administrative authority considers allowing movement after verifying that the infection probability of the person is very low. Since the definition of "very low infection probability" varies, the administrative authority prepares the following verification logic expression (CRS with signature).

[0112] Verification logic expression: If a PCR test is taken at a hospital and the result is negative, and the person has not been close to the area where cluster infections occurred within the past 1 week, then the infection probability is very low.

[0113] A person who wants to move to another region can take the following actions in advance.

[0114] 1. A service provider or MPC participant that has received a verification logic expression from the authority calculates a CRS (additional information) for the verification logic expression (e.g., Rank 1 Constraint System, Quadratic Arithmetic Program) and the data required for the operation of the verification logic.

[0115] 2. After the data subject downloads the verification logic expression and CRS (additional information) to the terminal, the data subject requests and receives the necessary data from the data producer (e.g., receives a medical examination in a hospital and activates the location information service).

[0116] 3. Calculate the calculation result (Proof) using the downloaded verification logic expression and data.

[0117] 4. Implement the proof by submitting the calculation result to the authority. At this time, the proof can also be performed offline (locally, within a local area network) by the data subject pre-obtaining the signed verification logic expression and CRS (additional information) of the service provider or MPC participant, or the authority pre-receiving the verification logic expression and additional information (CRS) from the service provider or MPC participant.

[0118] In the MPC-ZKP system 2 of this embodiment, the data in item 2 above is secretly shared and registered with the MPC participant group 10, and it is possible to perform a delegated proof implemented by performing calculations using MPC among these MPC participants. In addition, the service provider or MPC participant normalizes the circuit design and Setup required for ZKP by making the proof criteria common through logical coordination, thereby avoiding the establishment of multiple proofs with the same purpose.

[0119] Figure 2 is a schematic diagram for specifically explaining the confidentiality of the advantages of the MPC-ZKP system 2 using Figure 1 Confidentiality is achieved by the MPC-ZKP system 2, that is, unnecessary information disclosure is excluded. In the past, various data producers such as hospitals and map service operators observed evaluation objects such as patients and generated observation results respectively (e.g., xa indicating negative / positive medical examination results, xb indicating the basis for not having approached the area where cluster infections occurred, etc.). Then, the data xa and xb were collected in one place for judgment to decide whether to allow movement. The problem with this prior art is the privacy issue, that is, the original data must be collected in one place. As an evaluation object, there is an idea of not wanting to show more information than necessary to the verifier, and in this prior art, the exchange of data is carried out in writing, so the transaction procedures become lengthy.

[0120] In contrast, when using the MPC-ZKP system 2 of the present embodiment, for example, the data provider (which can also be the data subject) divides the data into shares and provides the shares to the MPC-ZKP system 2 instead of the original data. For example, xa indicating the negative / positive of the examination result is divided into two shares, xa1 and xa2, and sent to different servers (i.e., MPC participants) respectively. Similarly, xb indicating the basis of not having been close to the area where cluster infections occurred is divided into two shares, xb1 and xb2, and sent to different servers respectively. The MPC-ZKP system 2 (the MPC participant group 10 thereof) receives the data after being divided into shares (not the original data itself) and provides the verification result to the verifier 8 (via the verifier terminal 16). In this way, verification can be performed privately using MPC (share division) to protect privacy.

[0121] Figure 3 is a schematic diagram for explaining the logical transparency that demonstrates the advantages of the MPC-ZKP system 2 when using Figure 1 The MPC-ZKP system 2 ensures logical transparency and eliminates forgery. In the past, evaluators (witnesses) such as doctors and experts observed evaluation objects such as patients, evaluated the data x of the observation results according to the evaluation logic, and provided the evaluation result, that is, the conclusion y, to verifiers such as border and prefecture border management bureaus. The conclusion is mostly compressed into Yes / No such as whether there is an infection. There are the following two problems with this prior art.

[0122] (1) Problem of ability

[0123] It becomes a problem whether the evaluation logic by which the evaluator draws a conclusion is appropriate. Differences may occur in the "Accept" criterion due to the different viewpoints of the evaluator and the verifier.

[0124] (2) Problem of intention

[0125] There is a possibility that the evaluator tampers with the evidence and there is also a possibility of false testimony.

[0126] In contrast, when using the MPC-ZKP system 2 of the present embodiment, the data x is divided into shares ( Figure 3In the example shown, it is assumed to be a 2-out-of-2 secret sharing, and the shares are represented by x1 and x2), so the confidentiality of the data is preserved. The verification logic expression leaves the evaluator, is checked and deployed by the verifier, and is agreed by the evaluated object. The verification logic expression is constrained by the CRS, so the tampering of the verification logic expression cannot be carried out. The verification logic expression and the shares are provided to the MPC-ZKP system 2 to generate a proof. The verifier collects the output shares (such as y1 and y2) output by the MPC-ZKP system 2 and restores them to the conclusion y, thereby being able to obtain the proof of non-infected persons. In this way, as long as the data itself is not tampered with, an objective proof can be made. Regarding the tampering of the data itself, partial tampering countermeasures can be achieved by the data generator signing the shares, etc.

[0127] Figure 1 In the example, the case where the data generator 6 does not obtain consent from the data subject 4 for providing data (shares) to a third party is described, but it is not limited to this. There is also a case where the data generator 6 can obtain consent from the data subject 4 for providing data shares to a third party. Figure 19 It is a schematic diagram showing the structure of the MPC-ZKP system 2 in the case where the data generator 6 has obtained consent for providing to a third party. The signed witness (w, ws) is shared by the data generator 6 as (w i , ws i ), and is provided to each MPC participant 9 of the MPC participant group 10 from the data generator DB14 without passing through the data subject terminal 12.

[0128] Next, the details of the MPC-ZKP system 2 are described. Figure 4 It is a diagram showing the characteristics of the proof modes implemented in the MPC-ZKP system 2 in tabular form. There are three proof modes in the MPC-ZKP system 2: (1) the zero-knowledge proof mode executed by the user terminal, (2) the propositional function proof mode executed by the MPC, and (3) the zero-knowledge proof mode executed by the MPC. The user, i.e., the verifier 8, can use these three modes according to the requirements in different cases. The characteristics of each mode are as Figure 4As shown. As shown in the figure, the propositional function testimony mode executed by MPC does not have the transparency of verification logic. However, the verifier can randomly or arbitrarily request the proofs obtained from the zero-knowledge proof mode executed by MPC or the zero-knowledge proof mode executed by the user terminal. Therefore, it can play a role in suppressing perjury in the data of the propositional function testimony mode executed by MPC. The zero-knowledge proof mode executed by MPC has a huge computational amount. Therefore, if the number of executions of this mode can be reduced, it will help to shorten the total calculation time. The propositional function testimony mode executed by MPC does not have the transparency of verification logic, but can output conclusions (testimonies) more quickly compared with the zero-knowledge proof mode executed by MPC. Thus, by the verifier deliberately or randomly requesting the proof obtained from the zero-knowledge proof mode executed by MPC, it is possible to reduce the scenarios consuming computational load while preventing perjury in the testimony (the result of the propositional function) obtained from the propositional function testimony mode executed by MPC.

[0129] Next, regarding Figure 1 the structure of the verifier terminal 16 will be described. Regarding the hardware structure of the verifier terminal 16, as described later in reference to Figure 5 it can have the same hardware structure as the hardware structure described in Figure 5 .

[0130] Regarding the functional structure example of the verifier terminal 16, reference will be made to Figure 16 for description. In addition, each module shown in this figure and the block diagrams described below can be implemented in a hardware manner by elements such as the CPU of a computer or a mechanical device, or can also be implemented in a software manner by a computer program or the like. However, here, the functional modules implemented through their cooperation are depicted. Thus, these functional modules can be implemented in various forms by a combination of hardware and software, and those skilled in the art who come into contact with this specification should understand this point.

[0131] The verifier terminal 16 includes a verification logic expression acquisition unit 162, a verification logic expression deployment unit 164, a testimony request unit 165, a verification logic expression DB 166, an evidence request unit 168, and a verification unit 170. In the verifier terminal 16, it is possible to verify a proposition through ZKP or testimony using the output shares collected from each MPC participant 9 of the MPC participant group 10.

[0132] The verification logic expression acquisition unit 162 reads the input data types that can be used for the verification logic expression from the management server 22, and acquires (1) the relational expression of the object to be proven and (2) the ZKP scheme applied in the verification logic expression according to the input made by the verifier 8. The verification logic expression acquisition unit 162 registers the acquired verification logic expression in the verification logic expression DB 166.

[0133] The verification logic expression deployment unit 164 deploys the verification logic expressions registered in the verification logic expression DB 166 to the management server 22. Specifically, the verification logic expression deployment unit 164 registers the verification logic expressions (expressions representing relations) and the ZKP scheme to the management server 22 of the service provider 7, and obtains the verification logic IDs associated with the deployed verification logic expressions. The verification logic expression acquisition unit 162 registers the verification logic expressions in association with the verification logic IDs to the verification logic expression DB 166.

[0134] The verification logic expression DB 166 manages verification logic expressions. Figure 17 The data stored in the verification logic expression DB 166 is shown. The data stored in the verification logic expression DB 166 includes, for example, verification logic IDs, verification logic expressions, and ZKP schemes. In addition, the verification logic expression DB 166 may also be associated with the registered verifier IDs, but may also be in the same form as the data of the verification logic expression DB 118 in the management server 22 described later. The verifier 8 can view the data in the verification logic expression DB 166 at any time.

[0135] The testimony request unit 165 (corresponding to the operations performed by the verifier 8) sends a testimony request for requesting a testimony (propositional function) regarding the corresponding values of the verification logic ID and the data subject ID (details will be described later) to each MPC participant 9 in the MPC participant group 10. In addition, in this embodiment, the case where the testimony request is sent to the MPC participant 9 is taken as an example for description, but the testimony request may also be sent to the management server 22, and the management server 22 may request testimony from each MPC participant 9.

[0136] The evidence request unit 168 first requests additional information associated with the corresponding values of the verification logic ID and the data subject ID from the MPC participant 9. Then, for the MPC participant 9, it requests the evidence (output share of the Proof (π i). For example, the evidence request unit 168 generates an evidence request based on a request generated by the operation of the verifier 8 or a specified judgment in the evidence request unit 168, and sends it to the MPC participant 9. The evidence request unit 168 can make a specified judgment as described below. For example, after obtaining the output share of the propositional function, the evidence request unit 168 immediately determines whether a locally generated random number or a transaction hash value at a certain block height in the public chain (using a specified blockchain algorithm) after the moment of obtaining the share exceeds a specified threshold as a random number. When the above random number or transaction hash value exceeds the specified threshold, the evidence request unit 168 generates an evidence request (without waiting for a request generated by the operation of the verifier 8). In addition, in this embodiment, the case of sending a request for additional information and an evidence request to the MPC participant 9 is taken as an example for description, but the evidence request can also be sent to the management server 22, and the management server 22 requests additional information and evidence from each MPC participant 9.

[0137] The verification unit 170 obtains the output share of the testimony (propositional function) output from the MPC participant 9, performs Reconstruct, and obtains the testimony τ.

[0138] In addition, when an evidence is requested, the verification unit 170 obtains the output share (π i ) of the evidence (ZKP) and additional information associated with the verification logical expression from the MPC participant 9. The verification unit 170 restores it to ZKP (Proof) by collecting the obtained output shares. For example, the verification unit 170 authenticates the signed output share, the verification logical expression, and the CRS (especially the Verification Key in the case of using Trusted Setup) using the public key of the management server 22. In addition, the verification unit 170 verifies using the restored ZKP (Proof), the verification logical expression, and the Verification Key of the authenticated CRS in the case of using Trusted Setup. The verification unit 170 outputs, for example, either Accept or Reject as the verification result.

[0139] In addition, although Figure 16 is not clearly shown, the verifier terminal 16 may further have a verifier registration unit for registering the verifier 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 implement access control for requests from the verifier when applying individual policies regarding data processing.

[0140] Here, an explanation is given for the corresponding values of the above data subject IDs. The corresponding values of the data subject IDs are data for proof that can enable the data exchange of an individual in the verification logic expression and can repeatedly apply the verification logic expression to combinations of different individuals.

[0141] For example, consider the case of using the following verification logic expression. Additionally, in the following verification logic expression, the SigVerify function represents a function that verifies the integrity of the value of the second parameter using the public key of the first parameter and the digital signature of the third parameter.

[0142] --<Verification Logic Expression>--

[0143] DC008[0]+DC008[1]>10000000

[0144] &&SigVerify(DC012,DC008[0],DC013[0])

[0145] ==true

[0146] &&SigVerify(DC012,DC008[1],DC013[1])

[0147] ==true

[0148] --------------

[0149] In this verification logic expression, DCxxx represents a data class, DC008 represents annual income, DC012 represents the public key of the municipal government, and DC013 represents the signature of the municipal government for the annual income. "[0], [1], …" are subscripts that identify specific objects of each data class. For example, DC008[0] is the annual income of A, and DC008[1] refers to the annual income of B. This can be achieved by extracting the subscripts from the variables in the ASTs (Abstract Syntax Trees) of the verification logic expression. However, the parentheses ([]) enclosing the subscripts can also use different expressions. For example, when following the expressions of existing programming languages (such as C language) as the syntax of the verification logic expression, since it conflicts with the array expression, different notations and configurations can be used to make the expression different.

[0150] The corresponding value of the data subject ID is a mechanism that can specify an object of a data class through substitution. For example, when specifying the corresponding value of the data subject ID in the array form of [DS003, DS004], for the data subjects of DC008[0] and DC008[1], it can be assigned as:

[0151] DC008[0] = DS003, and DC008[1] = DS004

[0152] In this case, the above verification logic expression becomes an expression representing "whether the total annual income of two data subjects who have received signatures from the same municipal government exceeds 10 million yen". Thus, if the order of the data subject IDs listed in the data subject ID corresponding values (the subscripts of the array) is changed, or other IDs are specified, the generated verification logic expression can be used again for the verification of different combinations of individuals. Additionally, when the verification logic expression is for the verification of a single data subject, the above subscripts can be omitted, and a single data subject ID can be directly specified for the data subject ID corresponding value.

[0153] Next, the structure of MPC participant 9 (also referred to as the MPC participant server) will be described. Figure 5 is Figure 1 An example of the hardware structure diagram of MPC participant 9. Other MPC participants, the verifier terminal 16, the data subject terminal 12, and the data generator terminal 24 may also have the same hardware structure as that Figure 5 described. MPC participant 9 includes a memory 130, a processor 132, a communication interface 134, a display 136, and an input interface 138. These elements are respectively connected to a bus 140 and communicate with each other via the bus 140.

[0154] The memory 130 is a storage area for storing data and programs. The data and programs can be permanently stored in the memory 130 or temporarily stored. The processor 132 realizes various functions in MPC participant 9 by executing the programs stored in the memory 130. The communication interface 134 is an interface for sending and receiving data to and from the outside of MPC participant 9. For example, the communication interface 134 includes an interface for accessing a network, and data is transmitted via this network between other MPC participant servers, the data subject terminal 12, and the verifier terminal 16. 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.

[0155] Figure 6 is a block diagram showing Figure 1 an example of the functional structure of MPC participant 9. Each MPC participant 9 (i.e., P i ) is provided with an input data acquisition unit 102, a case storage unit 103, a calculation unit 104, a data providing unit 106, a share deletion unit 108, and a share storage unit 109.

[0156] The input data acquisition unit 102 acquires data related to the matter to be proven. There are two types of data, namely Instance (example) and the share of the witnessed share with signature (the share of Witness). The share acquisition unit 102 acquires the Instance and the share of the witnessed share with signature obtained by secret sharing (w i ,ws i ) from the data subject terminal 12 or the data generator terminal 24 via the network. In addition, various shares are expressed as {P i ,w i ,ws i ,v i ,τ i ,π i |i ∈ {0, 1, …, n - 1}}, where n is the number of MPC participants 9 in the MPC participant group 10, that is, the number of participants in the MPC, and i uniquely determines each MPC participant 9 (P i ). In addition, when the input data acquisition unit 102 transfers the Instance by reference, it further acquires its entity (such as the public key of the data generator 6) via the network.

[0157] The input data acquisition unit 102 communicates among the MPC participants 9 in the MPC participant group 10, and performs MPC processing on the verification algorithm for the integrity of the digital signature with the share of the witnessed share with signature (the share of Witness) as the input. Then, the output share (v i ) obtained as a result is shared among the MPC participants 9, and the verification result (v) is reconstructed. When the input data acquisition unit 102 confirms successful verification, it registers the share of the witnessed share with signature in the share storage unit 109. Furthermore, the input data acquisition unit 102 registers the Instance in the instance storage unit 103. The share data storage unit 109 and the instance storage unit 103 store these data in the Figure 22 shown form (such as a group of data subject ID, data class ID, and value).

[0158] The calculation unit 104 performs the calculation of the propositional function in response to receiving a testimony request from the verifier terminal 16, and performs the calculation of ZKP in response to receiving an evidence request from the verifier terminal 16.

[0159] (1) The case of receiving a testimony request from the verifier terminal 16 is described. The calculation unit 104 receives a testimony request regarding the value corresponding to the data subject ID and the verification logic ID from the verifier terminal 16. When the calculation unit 104 receives the testimony request, it starts the process of executing the propositional function based on the value corresponding to the data subject ID and the verification logic ID.

[0160] The calculation unit 104 first obtains the verification logic expression and the verification logic ID from the management server 22. Furthermore, for the individual policies of all data subject IDs included in the data subject ID corresponding value (obtained from the management server 22), it determines whether the protection scope shown in the data of the individual policy DB is satisfied. When the calculation unit 104 determines that the protection scope is satisfied for all data subject IDs, it calculates a propositional function that conforms to the verification logic expression based on the share of the data class and the value of Instance included in the verification logic expression.

[0161] The calculation unit 104 can send the data associated with the data subject ID corresponding value used for calculation (i.e., the privacy leaked by the data subject ID) to the management server 22 and have it registered in the verification history DB 142. That is, the calculation unit 104 enables the management server 22 to manage that the data related to the data subject ID corresponding value is used for propositional calculation, realizing necessary privacy control.

[0162] (2) Next, the case of calculating the ZKP in response to the evidence request received from the verifier terminal 16 will be described. In this case, the calculation unit 104 first receives a request for additional information related to the data subject ID corresponding value and the verification logic ID from the verifier terminal 16, and obtains the additional information associated with the data subject ID corresponding value and the verification logic ID. The calculation unit 104 sends the obtained additional information or the calculated additional information to the verifier terminal 16.

[0163] The verifier terminal 16 sends an evidence request correspondingly with the received additional information, so the calculation unit 104 receives the evidence request from the verifier terminal 16. In addition, when the ZKP scheme of the ZKP requested by the verifier terminal 16 is Interactive ZK, the calculation unit 104 also receives challenge information from the verifier terminal 16 in addition to the data subject ID corresponding value and the verification logic ID. When the calculation unit 104 receives the evidence request (or the evidence request and the challenge information), it starts the process for executing the ZKP based on the data subject ID corresponding value and the verification logic ID.

[0164] The computing unit 104 first obtains the verification logic expression and the verification logic ID from the management server 22. In addition, the computing unit 104 pre-reads the additional information sent to the verifier terminal 16. Here, the computing unit 104 determines whether the protection scope shown in the data of the individual policy DB of the management server 22 is satisfied for the individual policies of all the data subject IDs included in the data subject ID corresponding value (obtained from the management server 22). When the computing unit 104 determines that the protection scope is satisfied for all the data subject IDs, based on the share of the data class, the value of Instance, and the additional information included in the verification logic expression, the computing unit 104 calculates the ZKP that conforms to the verification logic expression. After that, the computing unit 104 stores the output share (the share of Proof, i.e., π, π i ) obtained after the ZKP calculation in the share storage unit 109.

[0165] In addition, the above-mentioned additional information can be stored, for example, in an additional information DB (not shown) in the data form shown in Figure 23 , or can be stored in the memory for a specified period. The data of the additional information, for example, as shown in Figure 23 , can be associated with the verification logic ID and the data subject ID corresponding value. The additional information may include CRS and commitment. The additional information varies according to the ZKP scheme. When the ZKP scheme belongs to Interactive ZK such as Schnorr’s Protocol and Sigma Protocol, the additional information includes, for example, a commitment. When the ZKP scheme belongs to NIZK (Non Interactive ZK) that requests Trust from a specific party, such as zk-SNARKS and Groth Sahai, the additional information includes, for example, CRS (Common Reference String). In addition, when the ZKP scheme belongs to NIZK such as zk-STARKs under the RO assumption that does not request Trust from a specific party, the additional information includes, for example, a commitment (Merkle Tree, Merkle Tree Root).

[0166] In addition, the output share obtained by the propositional function or ZKP can be stored, for example, in the share storage unit 109 in the data form shown in Figure 24 . Figure 24 In the data form shown, for example, the data subject ID corresponding value, the propositional function associated with the verification logic ID, the output share of the ZKP, and the calculation start date and time are stored.

[0167] When the computing unit 104 executes a propositional function, the data providing unit 106 outputs the output share obtained as the calculation result to the verifier terminal 16. In addition, when the computing unit 104 executes a ZKP, the output share obtained as the calculation result and the additional information used in the computing unit 104 are output to the verifier terminal 16. In addition, at this time, the data providing unit 106 can also determine whether the individual policies of all the data subject IDs included in the data subject ID corresponding value (obtained from the management server 22) satisfy the protection scope shown in the data of the individual policy DB. When it is determined that all the data subject IDs satisfy the protection scope, the output share (including additional information in the case of ZKP) is output.

[0168] 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 generator terminal 24 used by the data generator 6, the share deletion unit 108 deletes the target share from the share storage unit 109.

[0169] Figure 7 It represents the Figure 1 Block diagram of the functional structure example of the management server 22 operated by the service provider 7 for the MPC participant group 10 for management. The management server 22 includes a management information control unit 110, a setting unit 112, a verification request acquisition unit 114, a determination unit 116, a verification logic expression 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.

[0170] The management information control unit 110 issues IDs that uniquely determine the data registered in various DBs of the management server 22 (such as data subjects, verifiers, verification logic expressions, data classes, etc.). The data subject ID is information that uniquely identifies a data subject, and the management information control unit 110 issues this ID when registering a data subject. In addition, the data subject is not limited to an individual and can 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 a verifier. In addition, the service provider can be registered as a verifier. The verification logic ID includes a verification logic expression and a ZKP scheme (type of ZKP). The verification logic ID uniquely determines the combination of the verification logic expression and the type of ZKP. In the present embodiment, both the propositional function and the ZKP can be calculated based on the same form of verification logic expression. The data class ID is information that uniquely determines a data class. The data class includes the class name of the data (such as "age") and the type of the data (such as boolean or number of bits, etc.). When specifying the data class ID, it uniquely identifies the class of the data and the distinction between public / non-public (i.e., whether it is a witness or an example). The data class ID is issued by the management information control unit 110 when registering a data class.

[0171] In addition, the management information control unit 110 sends and receives data to and from the verifier terminal 16, the data subject terminal 12, or the MPC participant 9, etc. in the system 2, and controls the writing and reading of data to and from various DBs. Hereinafter, various data registrations and the like performed by the management information control unit 110 will be described.

[0172] (1) Registration control of data subject information

[0173] When the registration information control unit 110 registers the information of the data subject in the data subject terminal 12, it obtains the identity information such as the name / address of the data subject and the signature obtained from the certification authority for the identity information from the data subject terminal 12, 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 sends it to the data subject terminal 12. The data subject DB 122 records, for example, Figure 9 as shown, the data ID that identifies the data subject, the data class ID that identifies the data class, and the data associated with the data disclosed to the data subject. In addition, the ID information recorded in the data subject DB 122 can be made public, and in the case of being made public, it is regarded as an Instance. The information of the data subject recorded in the data subject DB 122 is recorded as shares in the MPC participant 9 respectively and kept confidential. If the data subject obtains multiple data subject IDs and uses the information of the data subject ID according to the purpose in different cases, the information is decentralized, and it is possible to prevent the entire identity information of the data subject from being known by collecting multiple information of one data subject.

[0174] (2) Registration control of verifier information

[0175] When the management information control unit 110 registers the information of the verifier in the verifier terminal 16, it obtains the identity information of the verifier 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, for example, Figure 11 as shown, the data associating the verifier ID, the verifier organization name, and the privilege query flag. The privilege query flag is a flag of a verifier indicating the privilege of having the output shares capable of obtaining testimony and evidence regardless of the set privacy policy. When the flag is set to "True" (for example, service providers and authorized administrative agencies, etc.), it indicates having this privilege.

[0176] (3) Reference control of data classes

[0177] When the verifier generates and edits a verification logic expression on the verifier terminal 16, the management information control unit 110 receives a reference to the data class from the verifier terminal 16 and sends the information of the data class to the verifier terminal 16. The information of the data class is registered by, for example, the service provider or the data generator 6, etc. When registering the data class, the management information control unit 110 issues a data class ID and registers the information in the data class DB 120. The data class DB 120 records, as shown in, for example, Figure 10 the data related to the data class ID, the data class name, the data form of the data class, the data form details that more specifically describe the data form, and the public classification. The data type is, for example, a Bool value or the number of bits, etc. Once the form of the data class is determined, the type (form) of the share of the data is determined, so it can also be considered that the form of the share of the data is registered in the data class DB 120. In addition, a data class with the public classification set to non - public is a witness, and a data class with the public classification set to public is an example.

[0178] (4) Registration / Reference Control of Verification Logic Expression

[0179] When the management information control unit 110 receives a verification logic expression sent from the verifier terminal 16, it registers the verification logic expression in the verification logic expression DB 118. At this time, the management information control unit 110 issues a verification logic ID and sends the issued verification logic ID to the verifier terminal 16. The verification logic DB 118 records, as shown in Figure 8 the verification logic ID that identifies the verification logic expression, the verification logic expression, and the ZKP scheme that identifies which ZKP algorithm (scheme) is used when performing ZKP. The verification logic ID is a value obtained by hashing the processing content (calculation formula) and the input data form (json, yaml, toml, etc.), and uniquely identifies the verification logic expression and the verified logic expression with a signature. The verification logic expression can be pseudocode. In addition, the verification logic expression can also use a predetermined specific notation such as "#" as a notation for identifying comments in the pseudocode.

[0180] When the verifier terminal 16 accesses the verification logic ID and the verification logic expression to provide the verification logic ID and the verification logic expression to the MPC participant 9, the management information control unit 110 provides the verification logic ID and the verification logic expression to the verifier terminal 16. Alternatively, when the verifier terminal 16 requests to provide the verification logic ID and the verification logic expression to the MPC participant 9, the management information control unit 110 provides the verification logic ID and the verification logic expression to the MPC participant.

[0181] In addition, the management information control unit 110 transmits the verification logic ID and the verification logic expression to the data subject terminal 12 as needed or in response to a request from the data subject terminal 12 .

[0182] (5) Registration control of individual policies

[0183] In response to receiving a registration request for a privacy policy of 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. The individual policy DB 128 is as follows: Figure 12 As shown, for example, the record will identify the data subject ID of the data subject for setting the privacy policy, the data class ID for identifying the data class related to the privacy policy, the verification logic ID, the verifier ID for determining the verifier who is the object of the privacy policy, the validity period of the privacy policy, and data associated with the protection scope of the privacy policy.

[0184] The effective period indicates the period during which this privacy policy is applied. Figure 12 In the example, it is expressed in minutes. Protection is no longer allowed after the specified period. The protection range indicates the range in which the true value is allowed to be narrowed down to what extent by executing multiple proofs. Specifically, the data representing the date of birth on October 1, 1980 is used as an example. For example, when proof (1) that the data subject's date of birth is after 1975 (>19741231) and proof (2) that the date of birth is before 1996 (<1996010>1) are executed, the privacy of the data subject's date of birth between 1975 and 1996 is leaked. However, for example, if the period of privacy leakage is longer than the value specified by the protection range, proof (1) and proof (2) are allowed. In contrast, when proof is further performed that the data subject's date of birth is before 1983 (<1984010>1), if the scope of privacy leakage is smaller than the value specified by the protection range (i.e., narrowed to a narrower range), the proof is refused to be executed.

[0185] In addition, the scales of values possessed by data classes include nominal scales (scales used to distinguish concepts), ordinal scales (scales with meaning in terms of magnitude), interval scales (scales with meaning in terms of the magnitude of the interval, i.e., the difference in numerical values), ratio scales (scales with meaning in terms of both the difference in numerical values and the ratio of numerical values), etc. The above protection scope can be set for the ordinal scale, interval scale, and ratio scale among these scales.

[0186] (6) Registration / reference control of verification history

[0187] When the MPC participant 9 executes a propositional function or a ZKP, when determining whether the MPC participant 9 does not violate the individual policy even when executing the proof, the data in the verification history DB is referred to. At this time, in response to the reference request from the MPC participant 9, the management information control unit 110 sends the corresponding data in the verification history DB to the MPC participant 9. In addition, after the MPC participant 9 executes the propositional function or the ZKP, the registration of the verification history is received from the MPC participant 9. Specifically, a request for each data class (associated with the value corresponding to the data subject ID) included in the verification logic expression used by the MPC participant 9 to execute the propositional function or the ZKP, the upper limit value and the lower limit value of the registered data is sent to the management server 22. In this case, the management information control unit 110 registers this historical information in the verification history DB142. The verification history DB142 is shown, for example, as Figure 13 shown, and for example, records data associating the data subject ID, the data class ID, the verifier ID, the lower limit value, the upper limit value, and their respective final proof date and time, etc. As records of the lower limit value and the upper limit value, by recording the comparison (proof) with the cases in the verification logic, it is possible to implement the determination of whether the execution of the proof is permitted using the individual policy. In addition, for the item of the final proof date and time, in the case of executing the ZKP using NIZK, a prescribed value (for example, 99999999) that can be regarded as a future value of the proof execution time can also be filled in the final proof date and time.

[0188] The order of the registration and reference processing and the like performed by the above management information control unit 110 is as described above, and can be controlled in the order of the registration control of the data subject information, the registration control of the verifier information, the reference control of the data class, the registration / reference control of the verification logic expression, the registration control of the individual policy, and the registration / reference control of the verification history. Alternatively, the management information control unit 110 can also perform the registration control of the individual policy at any timing, or can perform the registration control of the individual policy in response to receiving a notice from the MPC participant 9 indicating acceptance of the verifier's request for the proof.

[0189] The setting unit 112 generates an algorithm and a signed CRS. When the verification logic expression is deployed, the setting unit 112 generates a protocol for MPC for calculating the ZKP corresponding to this verification logic expression using MPC. At the same time, the setting unit 112 calculates the CRS. In the case where the ZKP scheme requests Trusted Setup, it is possible to make collusion difficult not only by the management server 22 but also through the cooperation of all MPC participants 9. The setting unit 112 digitally signs the generated CRS. The setting unit 112 publishes the generated protocol and the signed CRS to each MPC participant 9.

[0190] Return Figure 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 a network. The testimony request and the evidence request include, for example, a data subject ID corresponding value and a verification logic ID of a proof logic formula requested by the verifier 8.

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

[0192] The viewpoint of protecting output privacy (based on the above query monitoring method) will be described in more detail. Generally, the verifier cannot directly know the original data from the propositional function or ZKP. However, (as shown by the registration control of individual policies) when there is no restriction on the verifier's verification of data of the same data type, there is a possibility of leakage of the original data as a result of repeated verification. For example, countermeasures against chosen plaintext may become a problem, especially calculations using classes with a narrow range of acceptable values are likely to become a problem.

[0193] For example, regarding age, through repeated verification as described below, even if the correct age cannot be known from each verification result, the range of possible actual ages can be narrowed down by aggregating multiple verification results, and it can be determined that the data subject is 34 years old:

[0194] ● Is it over 50 years old? → False

[0195] ● Is it over 25 years old? → True

[0196] ● Is it over 37 years old? → False

[0197] ● Is it over 31 years old? → True

[0198] ● Is it over 34 years old? → True

[0199] ● Is it over 35 years old? → False

[0200] In the protection of output privacy of this embodiment, in order to maximize the protection of privacy (output privacy) that cannot be fully protected in MPC-ZKP, the MPC participant 9 or the service provider 7 plays the role of a fuse. The MPC participant 9 or the service provider 7 rejects the calculation of a propositional function or ZKP that has a significant risk of privacy leakage due to the verification logic requested by the verifier 8. In this sense, the MPC participant 9 or the service provider 7 plays the role of a fuse in the protection of output privacy. In addition, the benchmark for the risk of leakage can be determined according to the nature of the service and the agreement with the consumer.

[0201] The output privacy protection function implemented by the management server 22 determines the scope of privacy that the data subject 4 can be known to the verifier 8 using the individual policy DB 128, and the determination unit 116 protects the data subject 4 from threats to output privacy for data above the ordinal scale. The determination unit 116 determines whether to reject the verification request based on the content of the verification request obtained by the verification request acquisition unit 114, the privacy policy stored in the individual policy DB 128, and the verification history stored in the verification history DB 142.

[0202] More specifically, when the verifier 8 requests a propositional function or ZKP that violates the privacy policy, the determination unit 116 rejects the calculation (or the determination unit 116 causes the MPC participant 9 to reject the calculation). The specific columns of the privacy policy that may be stored in the individual policy DB 128 are as follows.

[0203] ● Policy 1: Avoid privacy leakage above a certain level for a specific verifier within a certain period (e.g., within 2 years).

[0204] ● Policy 2: Avoid privacy leakage above a certain level for a specific verifier.

[0205] ● Policy 3: Avoid privacy leakage above a certain level for all verifiers within a certain period.

[0206] ● Policy 4: Avoid privacy leakage above a certain level for all verifiers.

[0207] The "privacy above a certain level" described in the explanation of the above privacy policy can be set individually for each data subject. For example, it is determined by conditions such as "not wanting the age to be determined with an error of 10-year units (e.g., less than 40 years old and over 30 years old)" and "not wanting the savings amount to be determined with an error of 1 million yen units".

[0208] For such privacy policies, they are managed in the individual policy DB 128 for each data subject and the type of data (data class) (such as age, income, etc.). When a propositional function or ZKP that violates the privacy policy is requested, in order to protect the data subject 4 from threats to the output policy, the determination unit 116 rejects the verification request.

[0209] When the determination unit 116 approves the verification request, it causes each MPC participant 9 in the MPC participant group 10 to execute the propositional function or ZKP and provide the output share obtained as a result to the verifier terminal 16. Alternatively, when the determination unit 116 approves the verification request, it provides the corresponding output share stored in the verifier DB 124 to the verifier terminal 16.

[0210] Figure 21It is a representative view of the output privacy leakage notification screen 900 displayed on the display of the data subject terminal 12 of the data subject 4. The output privacy leakage notification screen 900 is generated by referring to the verification history DB 142 and presents the privacy scope leaked due to the propositional function or ZKP to the data subject 4. Figure 21 In the example shown, the range of the age used for verification is indicated by a diagonal line. In addition, Figure 21 one-dimensional display is adopted here, but two-dimensional display such as a Venn diagram can also be used.

[0211] Figure 14 It represents Figure 1 a block diagram of the functional structure example of the data subject terminal 12. The data subject terminal 12 has a management information request unit 144, a data acquisition unit 146, a data providing unit 148, an individual policy unit 150, and a data deletion request unit 145.

[0212] The management information request unit 144 requests management information (especially the verification logic expression) from the management server 22 of the service provider 7. The management information request unit 144 acquires the management information associated with the verification logic ID and displays it on the display. The data subject 4 can view and confirm the verification logic expression requested by the verifier 8 and can commission the data generator 6 to generate necessary data (such as receiving a medical examination at a hospital, etc.).

[0213] When the signed witness (w, ws) is saved 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 storage unit 152. In addition, the data acquisition unit 146 acquires necessary examples (such as the public key of the data generator 6) from the outside and registers them in the cache storage unit 152.

[0214] The data providing unit 148 transforms the signed witness (w, ws) saved in the cache storage unit 152 into shares and provides each MPC participant 9 in the MPC participant group 10 with the shares (w i , ws i )(i = 0 to the number of MPC participants - 1) (i.e., secret-sharing it). The data providing unit 148 also provides examples to each MPC participant 9 in addition to the shares of the signed witness.

[0215] The individual policy setting unit 150 reads the data class from the management server 22 and sets the privacy policy for each data class. For example, according to the operations performed by the data subject 4, the privacy policy is set for each data class and the privacy policy is set for the management server. In addition, the individual policy setting unit 150 can set which verifier (verifier ID) is granted the proof permission according to the operations performed by the data subject 4.

[0216] The data deletion request unit 145 can request the MPC participant 9 of the MPC participant group 10 to delete the saved shares.

[0217] In addition, although Figure 14 is not clearly shown, the data subject terminal 12 may further have a data subject registration unit (the name and address of the data subject) for registering the data subject and obtaining data for uniquely identifying each verifier's data subject ID. At this time, a signature for the information of the data subject ID (for example: information capable of confirming the authentication performed by a public institution) may also be provided.

[0218] Figure 15 FIG. is a block diagram showing an example of the functional structure 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.

[0219] The verification logic acquisition unit 156 reads the verification logic from the management server 22 and, for example, displays it on a display. Thereby, the data generator 8 can confirm and understand the necessary data and its form.

[0220] The data observation unit 154 generates data regarding the matter to be proven. In the example where the data generator 6 is a doctor or a hospital, the generated data is examination results, analysis results of the subject, and the like. The data observation unit 154 registers the generated data (for example, the testimony (secret information) in the generated data) in the data generator DB 14. In addition, the cases (public information) in the generated data may also be stored in the data generator DB 14. The data observation unit 154 may also register the data subject ID and the data class ID of each data together.

[0221] The digital signature unit 158 generates a signed testimony by performing a digital signature (for example, signing with the private key of the data generator) on the data (testimony) generated by the data observation unit 154 and registers it in the data generator DB 14. In addition, the digital signature unit 158 may also generate a signature for the case and register it in the data generator DB 14.

[0222] The share providing unit 161 generates shares of the signature and the data by sharing the signed testimony generated by the digital signature unit 158, and further signs each share. The share providing unit 161 can provide the generated signed shares to the MPC participant 9. In addition, the share providing unit 161 may be invalidated when providing shares from the data subject terminal 12 to the MPC participant 9. On the other hand, as Figure 19It is validated in the structure that provides shares to the MPC participant 9 from the data producer terminal 24 and the data producer DB 14.

[0223] 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. The data providing unit 160 can provide the generated data to others or other organizations with the prior consent of the data subject 4.

[0224] The operation of the MPC-ZKP system 2 configured with the above structure will be described.

[0225] Figure 18 It is a diagram showing the process of the proof sequence in the MPC-ZKP system 2. Figure 18 The case where the zk-SNARKs is used as the ZKP algorithm will be described. Figure 18 The sequence corresponds to the zero-knowledge proof mode executed by MPC and the zero-knowledge proof mode executed by the user terminal as described above. Figure 18 The sequence includes steps S802, S804, S806, S808, S810, S812. Among them, steps S802 and S804 represent the process of defining the verification logic performed by the service provider 7 or the verifier 8, steps S806, S808, S810, and S812 represent the ZKP process, and steps S808 and S810 represent the MPC process. In addition, steps S808 and S810 are executed in the case of the zero-knowledge proof mode executed by MPC and are not executed in the zero-knowledge proof mode executed by the user terminal.

[0226] In this sequence, first, the content to be proved (verified) is specified (step S802), and its verification logic expression is generated (step S804). The verification logic can be prepared by the verifier 8 or, as "content that is often verified", prepared in advance by the service provider 7. The verification logic expression includes calculation formulas (processing content) and the form of input data (json, yaml, toml, etc.). In addition, a ZKP scheme is associated with the verification logic expression. In the verification logic, there are those for propositional functions and those for ZKP. In this sequence, those for ZKP are assumed, and those for propositional functions will be described later. The management server 22 that has received the verification logic expression issues a verification logic ID.

[0227] The verifier terminal 16 of the verifier 8 or the MPC participant 9 calculates the verification logic expression required to prove the verification logic and the CRS (in the case of using Trusted Setup) (step S806). The calculation of the CRS can be performed by the normal calculation performed by the MPC participant 9 (MPC using the shared values may not be implemented). However, when the adopted ZKP scheme requests Trusted Setup, the MPC participant 9 (and the verifier 8) collaboratively perform the Setup phase.

[0228] However, in the case of a scheme that depends on the security of a hash function (random oracle hypothesis) such as zk-STARKs, Trusted Setup is not required.

[0229] In step S808, the data required for the proof is obtained.

[0230] <In the case of calculating ZKP using MPC and assuming data is provided to a third party>

[0231] When the signed shares required for verification have not been registered, the MPC participant 9 requests the signed shares from the data generator terminal 24 of the data generator 6 through the entrustment of the data subject 4 or the service provider 7. Alternatively, the following data provision can also be automatically performed from the data generator terminal 24 of the data generator 6.

[0232] The data generator terminal 24 of the data generator 6 obtains the verification logic expression from the management server 22 of the service provider 7, and prepares the signed shares of the requested data according to the format of the input data, that is, the values obtained by secretly sharing (sharing) the plaintext, the values obtained by secretly sharing (sharing) the signature of the plaintext, and the values of the signatures for each share. The data generator terminal 24 publishes each signed share to the MPC participant server 20 of the MPC participant 9 one by one.

[0233] The MPC participant 9 obtains the public key of the data generator 6 and verifies the integrity of the signed shares and the signed shares it receives.

[0234] <In the case of calculating ZKP using MPC and not assuming data is provided to a third party>

[0235] When the data required for verification has not been registered, the data subject terminal 12 obtains the verification logic expression from the management server 22 of the service provider 7, and requests the plaintext of the data required for the proof and the signature of the plaintext from the data generator terminal 24 according to the format of the input data.

[0236] The data producer terminal 24 prepares the plaintext of the requested data and the signature of the plaintext. The data producer terminal 24 provides them to the data subject terminal 12.

[0237] The data subject terminal 12 uses the public key of the data producer 6 to verify the integrity based on the digital signature.

[0238] The data subject terminal 12 performs secret sharing (sharding) on the plaintext of the data obtained from the data producer terminal 24 and the signature of the plaintext, generates shards with signatures (e.g., shards of signed witnesses), and publishes each shard with a signature to the MPC participant 9 one by one.

[0239] The MPC participant 9 obtains the public key of the data producer 6 and verifies the integrity of the shards with signatures (e.g., shards of signed witnesses) it receives.

[0240] <In the case where the ZKP is calculated in the data subject terminal 12 of the data subject 4>

[0241] Based on the input data ID associated with the verification logic ID, confirm whether the data is registered (saved) in the local data subject terminal 12. If it is not registered, the data subject terminal 12 requests the data required for the proof from the data producer terminal 24. The data producer terminal 24 prepares the plaintext of the requested data and the signature of the plaintext. The data producer terminal 24 provides all of them to the data subject terminal 12. The data subject terminal 12 uses the public key of the data producer 6 to confirm that the signature can be correctly authenticated. The data subject terminal 12 registers the data in the local data subject terminal 12.

[0242] In step S810, the prover calculates the ZKP.

[0243] <In the case where the prover = the MPC participant 9>

[0244] The MPC participant 9 calculates the ZKP based on the verification logic expression associated with the target verification logic ID, or based on the CRS in the case of using TrustedSetup. Additionally, the calculation of the ZKP can be limited to the case where the verification logic expression satisfies the privacy policy of individual privacy as described above.

[0245] For the ZKP of the calculation result, in the state where the output is share-ized, each output share is saved by MPC participant 9. At this time, the management server 22 can also issue a credential for authenticating the share for obtaining the ZKP, that is, the output share, and associate it after issuing the credential ID. In this case, after obtaining the prior and post-facto permission of the data subject, the service provider 7 directly notifies the verifier of the information associated with the credential ID. Or, it is also possible to implement notifying the data subject 4 of the information associated with the credential ID, and the data subject 4 can only notify the other party (verifier 8) to be proved of the information associated with the credential ID, and provide a proof associated with the attributes of the person himself / herself.

[0246] In this way, by using the credential, the data subject 4 associated with the proof ID can control whether to allow the verifier 8 to access the evidence (ZKP) (can judge allow / deny and instruct the system) by registering and deleting the credential information after calculating the ZKP. MPC participant 9 only provides the output share of the ZKP (online proof) to the verifier 8 permitted by the data subject 4 online. However, in exceptional situations where it is inconvenient for the data subject to know the query in matters related to searches, etc., the response method is not limited to this based on the judgment of the service provider.

[0247] The calculation result can also be published to the data subject terminal 12, and the data subject 4 allows the verifier 8 to refer to it (offline proof).

[0248] <When the prover = the data subject 4 (the data subject terminal 12)>

[0249] The data subject terminal 12 requests the verification logic expression associated with the target verification logic ID from MPC participant 9 or the management server 22, or requests the CRS when using Trusted Setup.

[0250] The data subject terminal 12 calculates the ZKP based on the obtained verification logic expression or CRS.

[0251] The calculation result is retained in the data subject terminal 12, and the verifier 8 is allowed to refer to it at will (offline proof). Or it can also be entrusted to the service provider 7 for custody, and the verifier 8 can verify it online (online proof). When online proof can be achieved, the data subject 4 associated with the proof ID can control whether to allow the verifier 8 to access the evidence (ZKP) (can judge allow / deny and instruct the system) by registering and deleting the information associated with the credential ID. MPC participant 9 only provides the output share of the ZKP (online proof) to the verifier 8 permitted by the data subject 4 online.

[0252] In step S812, the verifier 8 verifies the ZKP.

[0253] <Case where the ZKP holder = MPC participant 9>

[0254] The verifier terminal 16 of the verifier 8 obtains evidence (the output share of the ZKP) from the MPC participant 9. Additionally, providing the output share of the ZKP may be limited to the case where the verification logical expression satisfies the conditions of the privacy policy of individual privacy as described above, and the case where the verifier 8 is allowed to access the output share with a credential. For example, in the case of access control using a credential, after obtaining the prior and subsequent consent of the data subject, the service provider directly notifies the verifier of the information associated with the credential ID. 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 uses the authentication of the credential associated with the received credential ID and the verifier ID to obtain evidence (the output share of the ZKP), the verification logical expression, or obtains the CRS in the case of using Trusted Setup. The verifier terminal 16 restores the ZKP (Proof) from the output share and obtains the verification result through the verification step (Verify) of the restored ZKP.

[0255] <Case where the ZKP holder = data subject 4 (data subject terminal 12)>

[0256] The data subject 4 provides the evidence (the output share of the ZKP) and the signed verification logical expression, or the signed CRS in the case of using Trusted Setup, to the verifier 8. 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 the verification result through the verification step (Verify) of the restored ZKP.

[0257] Figure 20 It is a diagram showing the process of the sequence of proofs (testimonies) using propositional functions in the MPC-ZKP system 2. Figure 20 The sequence corresponds to the propositional function testimony pattern executed by MPC as described above. Figure 20 The sequence includes steps S820, S822, S824, S826, where steps S820, S822 represent the process of defining the verification logic performed by the service provider 7 or the verifier 8, and steps S824, S826 represent the process of MPC.

[0258] In this sequence, first, the content to be proved (verified) (step S820) is specified, and its verification logic expression is generated (step S822). The verification logic can be prepared by the verifier 8 or, as "content often verified", prepared in advance by the service provider 7. The verification logic includes calculation formulas (processing content) and the form of input data (json, yaml, toml, etc.). In the verification logic, there are those for propositional functions and those for ZKP. In this sequence, it is assumed to be for propositional functions. The management server 22 that has received the verification logic issues a verification logic ID.

[0259] In step S824, the data required for the proof is obtained.

[0260] <In the case of MPC calculation and on the premise of providing data to a third party>

[0261] When the data required for verification has not been registered, the data generator terminal 24 obtains the verification logic from the management server 22 of the service provider 7, and according to the format of the input data, prepares the signed shares of the requested data, that is, the values obtained by secret sharing (sharification) of the plaintext, the shares of the signature of the plaintext, and the signatures of each share (signed shares). The data generator terminal 24 publishes each share to the MPC participant 9 one by one.

[0262] The MPC participant 9 obtains the public key of the data generator 6 and verifies the integrity of the signature shares and signed shares it has received.

[0263] <In the case of MPC calculation and not on the premise of providing data to a third party>

[0264] When the data required for verification has not been registered, the data subject terminal 12 obtains the verification logic expression from the management server 22 of the service provider 7, and according to the format of the input data, requests the plaintext of the data required for the proof from the data generator terminal 24 and the signature of the plaintext.

[0265] The data generator terminal 24 prepares the plaintext of the requested data and the signature of the plaintext. The data generator terminal 24 provides them to the data subject terminal 12.

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

[0267] The data subject terminal 12 secret-shares (sharifies) the plaintext and the data of the signature of the plaintext obtained from the data generator terminal 24, generates signed shares (such as shares of signed witnesses), and publishes each signed share to the MPC participant 9 one by one.

[0268] The MPC participant 9 obtains the public key of the data producer 6 and verifies the integrity of the signed shares (e.g., the shares of the signed witness) it has received.

[0269] In step S826, the prover calculates the propositional function and the verifier 8 verifies the result.

[0270] The MPC participant 9 performs MPC based on the verification logic expression associated with the target verification logic ID to obtain shares of the verification result. Additionally, the calculation of MPC can be limited to the case where the verification logic expression satisfies the conditions of the privacy policy for individual privacy as described above. Alternatively, the management server 22 can also issue a credential for authenticating the acquisition of the shares of the verification result and associate it after issuing the credential ID. It is also possible to implement the management server 22 notifying the data subject 4 of the information associated with this credential ID, and the data subject 4 providing this information to the verifier 8 when proving, so as to be able to provide proof associated with the attributes of the individual to the verifier 8.

[0271] In the case of using a credential, after obtaining the prior and post-facto permission of the data subject, the service provider directly notifies the verifier of the information associated with the credential ID. Alternatively, the data subject 4 provides the information associated with the credential ID to the verifier 8 in advance. The verifier 8 uses the credential to obtain the verification result (True / False).

[0272] with Figure 18 and Figure 20 The flowcharts shown respectively illustrate the actions in the zero-knowledge proof mode and the propositional function testimony mode executed by MPC in the overall MPC-ZKP system. However, as described above, the zero-knowledge proof mode executed by MPC can suppress perjury in the propositional function testimony mode executed by MPC by being appropriately combined and executed in the MPC participant 9. Additionally, when the MPC participant 9 executes the calculation of the propositional function or ZKP, by considering the privacy policy, the leaked privacy can be appropriately controlled. Hereinafter, for an example of the actions in the MPC participant 9 that achieve these functions, reference is made to Figure 25 for description. Additionally, the actions in the MPC participant 9 are implemented by a processor executing a program stored in the memory of the MPC participant 9.

[0273] In S2501, after the processor of the MPC participant 9 obtains the shares of the signed witness from the data subject terminal 12 or the data producer terminal 24, it uses the public key of the data producer terminal 24 to verify that the obtained shares of the signed witness have not been partially tampered with.

[0274] In S2502, the processor of MPC participant 9 receives either a testimony request or an evidence request, i.e., a verification request, from the verifier terminal 16. At this time, the corresponding value of the data subject ID and the verification logic ID related to the verification request are identified. Then, in S2503, based on this verification logic ID, a verification logic expression is obtained (from the management server 22).

[0275] In S2504, the processor of MPC participant 9 determines whether the execution of the verification logic expression is within the protection scope of the privacy policy. Specifically, the comparison result and the information on the protection scope of the data class associated with the corresponding value of the data subject ID related to the verification request in the data of the above verification history DB and individual policy DB are obtained, and it is determined whether the data is reduced to within the protection scope of the data class set as the privacy policy due to the execution of the verification logic expression this time. In S2505, when the processor determines that the verification logic expression is within the protection scope, it proceeds to S2506; otherwise, this process ends.

[0276] In S2506, the processor of MPC participant 9 determines whether the requested verification request is an evidence request (i.e., a request for executing ZKP). For example, the processor makes this determination in this step according to whether the verification request received from the verifier terminal 16 is an evidence request or a testimony request. When the verification request is an evidence request, ZKP is executed in S2508; when the verification request is a testimony request, a propositional function is executed in S2507.

[0277] In S2509, the processor of MPC participant 9 provides the verifier terminal 16 with the output share obtained as the processing result of the propositional function or ZKP. In the verifier terminal 16, the output shares sent from each MPC participant 9 are Reconstructed to restore the result. After the processor of MPC participant 9 provides the output share to the verifier terminal 16, a series of operations end.

[0278] In the above embodiment, an example of the storage unit is a hard disk or a semiconductor memory. In addition, based on the description of this specification, each part can be implemented by a CPU (not shown), modules of installed application programs, modules of system programs, and a semiconductor memory that temporarily stores the content of data read from the hard disk, etc. Those skilled in the art who come into contact with this specification should understand this point.

[0279] According to the MPC-ZKP system 2 of this embodiment, by combining the use of MPC and ZKP, a delegated attribute prover with privacy protection can be implemented. Especially in the case where the data subject himself / herself is not present, it is also possible to perform the proof based on the original data (private information) of the data subject without disclosing the original data.

[0280] Proofs calculated on the user's own terminal are sometimes unconvincing. In such cases, in the MPC-ZKP system 2 according to the present embodiment, the MPC-ZKP system 2 proves based on verifying the authenticity of data using the public key of the data generator (such as a hospital, government, etc.). Therefore, it is equivalent to testimony made by a third party, so the persuasiveness is improved.

[0281] In the MPC-ZKP system 2 of the present embodiment, the data generator 6 generates data and attaches a digital signature thereto. There are cases where there are multiple data generators 6. For example, consider the case where (1) a hospital that conducts PCR tests and (2) a service provider of location information services are both data generators 6. Both the test result and the location information (Have you ever been close to the cluster infection occurrence site?) are verified using ZKP, and the border control, prefecture border control, etc. admit that "this person can enter the country" based on both being False (negative and never been close to the cluster infection site). In the MPC-ZKP system 2, for information of different natures (test result, location information), the data generator 6 that generates each piece of information (data) individually signs it, thereby being able to improve the reliability of the proof conducted by the MPC-ZKP system 2.

[0282] As described above, there are two types of testimony methods.

[0283] 1. Only provide the result of the propositional function executed by MPC (without making ZKP)

[0284] For an execution request of a function (propositional function) that returns a true or false value, return True or False. Only functions that have received an execution permission from the data subject can be executed. In this case, since evidence of the correct calculation process is not generated, the basis is relatively weak. When worried about the size of the computational cost of executing ZKP using MPC, and insufficient communication bandwidth and recording area, it is suitable to preliminarily review only True / False through the propositional function executed by MPC. By requesting ZKP suspiciously or suddenly (randomly), for the prover (service provider, MPC calculator), in view of the possibility of contradiction between the conclusion of the propositional function and ZKP, it is difficult to forge the conclusion corresponding to the request for the propositional function casually.

[0285] 2. Provide ZKP calculated by MPC

[0286] Since the proof content includes the propriety of the calculation process until the conclusion is derived, the basis is strong. This becomes a deterrent to forgery in the testimony of the propositional function cited in 1. In addition, various conditions such as whether the authentication of the signature is successful can be attached to the proof content of ZKP.

[0287] The structure and operation of the MPC-ZKP system 2 in the embodiment have been described above. This embodiment is an example, and various modifications can be achieved by combinations of the respective components and processes. Such modifications are also within the scope of the present invention, and those skilled in the art should understand this point.

[0288] In the embodiment, the case where the data subject 4 is different from the data generator 6 has been described, but it is not limited thereto. For example, the functions of the data generator terminal 24 can also be implemented by an application running in the TEE (Trusted Execution Environment) of the data subject terminal 12.

[0289] When the functions of the data generator terminal 24 are implemented by an application running locally on the data subject terminal 12, in a normal application, the data subject 4 can easily tamper with the data. Therefore, an application running in the TEE is used here.

[0290] There is a possibility that the OS (Operating System) accesses the program and data in a normal application. In this case, there is a possibility that the program and data are easily tampered with. On the other hand, it is very difficult to tamper with the program and data in an application running in the TEE. The reason for the difficulty is that the TEE is an environment that is hardware-isolated from the OS, and it is difficult for the program and data to be tampered with in the application running here. That is, the integrity of the code and data is protected. Since the data subject terminal 12 is a local terminal, although the defense is not complete, it is safe as long as the side-channel attack is not successful.

[0291] The application running in this TEE acquires information of external devices (peripheral devices) that can be operated by the TEE, that is, sensors (GPS receivers, thermometers, etc.) connected by a wireless interface, and organizes, analyzes, and interprets it.

[0292] The application in the TEE shares the obtained calculation results, signs them, and publishes them to the MPC participant 9. Before publishing the shares, the application can also confirm "Can it be published?" to the user with a privacy policy attached. In this way, the "data generator 6" can be replaced with the "application in the data subject terminal 12".

[0293] Description of Reference Numerals

[0294] 2 MPC-ZKP system, 4 data subject, 6 data generator, 8 verifier, 10 MPC participant group, 12 data subject terminal, 14 data generator DB.

Claims

1. One of a plurality of devices participating in multiparty computation, which is equipped with a protocol for performing zero-knowledge proof using multiparty computation based on secret sharing, characterized in that, Comprising: An acquisition unit that acquires a share of data regarding the matter to be proven; A first output unit that outputs an output share of a testimony obtained as a result of calculating a propositional function through the multi-party computation with the acquired share as an input, so as to reproduce the output shares of the testimony collected from the multiple devices participating in the multi-party computation to obtain the testimony; And A second output unit that, when requesting a zero-knowledge proof from the verifier terminal in addition to the output share of the testimony, outputs an output share of evidence obtained as a result of performing a calculation according to a protocol with the acquired share as an input, Based on the output shares of the proof collected from the multiple devices participating in the multi-party computation to reproduce the evidence, to perform verification in the zero-knowledge proof.

2. The device according to claim 1, characterized in that: It further includes a unit that uses the digital signature attached to the acquired share to verify that the original data of the share has not been tampered with.

3. The device according to claim 1 or 2, characterized in that: The zero-knowledge proof is a zero-knowledge proof using a verification logical expression or a common reference string.

4. The device according to claim 3, characterized in that: The common reference string in the case of performing Trusted Setup is generated by the multiple devices participating in the multi-party computation or the verifier terminal collaborating with each other, Where Trusted Setup is a trusted setup.

5. The device according to claim 1 or 2, characterized in that: The verification in the zero-knowledge proof is performed in the verifier terminal according to a random or arbitrary request of the verifier.

6. The device according to claim 3, characterized in that: The verification in the zero-knowledge proof is performed in the verifier terminal according to a random or arbitrary request of the verifier.

7. The device according to claim 4, characterized in that: The verification in the zero-knowledge proof is performed in the verifier terminal according to a random or arbitrary request of the verifier.

8. The device according to claim 5, characterized in that: The verification in the zero-knowledge proof is performed in the verifier terminal after performing a verification based on the propositional function on the output shares collected from the multiple devices participating in the multi-party computation.

9. The device according to claim 6, characterized in that: The verification in the zero-knowledge proof is performed in the verifier terminal after performing a verification based on the propositional function on the output shares collected from the multiple devices participating in the multi-party computation.

10. The device according to claim 7, characterized in that: The verification in the zero-knowledge proof is performed in the verifier terminal after performing a verification based on the propositional function on the output shares collected from the multiple devices participating in the multi-party computation.

Images