CN115174087A - 用于用多方计算执行的零知识证明的装置和系统 - Google Patents

用于用多方计算执行的零知识证明的装置和系统 Download PDF

Info

Publication number
CN115174087A
CN115174087A CN202111030539.8A CN202111030539A CN115174087A CN 115174087 A CN115174087 A CN 115174087A CN 202111030539 A CN202111030539 A CN 202111030539A CN 115174087 A CN115174087 A CN 115174087A
Authority
CN
China
Prior art keywords
data
mpc
verification
verifier
zkp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111030539.8A
Other languages
English (en)
Inventor
川口将司
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nomura Research Institute Ltd
Original Assignee
Nomura Research Institute Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nomura Research Institute Ltd filed Critical Nomura Research Institute Ltd
Publication of CN115174087A publication Critical patent/CN115174087A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)
  • Storage Device Security (AREA)

Abstract

本发明提供一种用多方计算执行的零知识证明用的装置和系统，其实现用户便利性更高的证明服务，并且实现能够减小隐私信息的泄漏风险的技术。本发明的装置是一种安装有用基于秘密共享的多方计算来执行零知识证明用的协议的、参加多方计算的多个装置中的一个装置，其包括：获取单元，其获取关于要证明的事项的数据的份额；和输出单元，其输出将获取到的份额作为输入而按照协议进行了计算的结果所得到的输出份额。根据从参加多方计算的多个装置收集到的输出份额，能够进行零知识证明中的验证。

Description

用于用多方计算执行的零知识证明的装置和系统
技术领域
本发明涉及用于用多方计算执行的零知识证明的装置和系统。
背景技术
近年来，已知有关于零知识证明的技术。零知识证明(Zero-Knowledge Proof，ZKP)是无需对对方公开自己所具有的知识(秘密)地、对对方证明自己知道知识(秘密)、或者该知识(秘密)具备某种性质、满足条件用的技术。但是，ZKP必须具备以下3个性质：完备性(Completeness，如果证明者试图证明的命题是真则必然能够说服验证者的性质)、可靠性(Soundness，证明者试图证明的命理是假的情况下说服会高概率地失败的性质)、零知识性(Zero-Knowledge，验证者根据证明者证明某一命题的结果得到的知识，仅有该命题是真的性质。即验证者即使不具有知识，也能够模拟证明的妥当性的性质)。关于与ZKP相关的用语、各方法的特征的标准化正在进展，本文原则上遵循该标准(参考非专利文献1)。
另一方面，多方计算(Multi-Party Computation，MPC)是能够对输入值保密地导出计算结果的加密技术。特别将用k-out-of-n门限秘密共享法(n≥k≥2)使相当于秘密的输入值秘密共享为多个份额、保管各份额的参与方执行规定的步骤(协议)、导出计算结果的计算方法，称为基于秘密共享的多方计算。该计算方法能够具备FunctionalCompleteness(功能完备性)，在非专利文件2中记载了两方计算的各种协议的实现例。
当前，呼吁社会基础架构的数字化，隐私保护成为紧要课题，ZKP和MPC作为有效的对策方案受到了关注。
现有技术文献
非专利文献
非专利文献1：ZKProof Community Reference,Version 0.2,2019年12月31日，URL:https://docs.zkproof.org/pages/reference/reference.pdf
非专利文献2：Sander Siim,A Comprehensive Protocol Suite for SecureTwo-Party Computation,2016,URL:https://cyber.ee/research/theses/sander_siim_msc.pdf
发明内容
发明要解决的课题
对个人或组织请求对外部的验证者的证明的事例大量存在。现代的证明行为大多是通过对验证者公开第三方机构颁发的证书、或本人(本组织)所具有的信息而完成的。
但是，在证明行为的过程中，对验证者给出的信息中，在量和质上都包括不必要的内容的情况大量存在。例如购买酒类时证明“本人是成人”的手段，可能是通过出示证明者即本人的驾驶证、对验证者即酒类的卖方通知出生年月日而完成的。本例中，在“本人是成年”的事实以外，在量(实际年龄)和质(住址等)上都包括多余的信息。
即，请求限制上述不必要的隐私信息(请求证明的命题的结论以上的信息)的泄漏、且不损害便利性地、具有对验证者来说充分的说服力的证明手段。
上述问题能够用已知的零知识证明有条件地解决。但是，请求用零知识证明计算Prove的人处理隐私信息(明文的知识)并计算。因此，对他人委托证明行为的情况下，请求对受委托方公开隐私信息。作为典型例，在进行基于两人的隐私信息的证明的情况下，对两人中的某一人、或者第三者委托证明行为，至少两人中的某一人的隐私信息被本人以外的某人得知成为前提。不想泄漏不必要的隐私信息的人受到基于该隐私信息的证明的请求时发生问题。
本发明是鉴于上述课题得出的。其目的在于实现用户便利性更高的证明服务，或者实现能够减小隐私信息的泄漏风险的技术。
用于解决课题的技术方案
本发明的一个方式涉及一种装置。该装置是一种安装有用基于秘密共享的多方计算来执行零知识证明用的协议的、参加多方计算的多个装置中的一个装置，其包括：获取单元，其获取关于要证明的事项的数据的份额；和输出单元，其输出将获取到的份额作为输入而按照协议进行了计算的结果所得到的输出份额。基于从参加多方计算的多个装置收集到的输出份额，能够进行零知识证明中的验证。
本发明的另一方式是一种系统。该系统是一种进行零知识证明的系统，其包括：保存隐私策略的策略保存单元；保存验证的历史的历史保存单元；从验证者获取验证请求的单元；和基于获取到的验证请求的内容、所述策略保存单元所保存的隐私策略和所述历史保存单元所保存的验证的历史，来判断是否拒绝验证请求的单元。
另外，以上构成要素的任意的组合和将本发明的构成要素与表达在装置、方法、系统、计算机程序、保存了计算机程序的记录介质等之间相互置换得到的结果，作为本发明的方式也是有效的。
发明的效果
根据本发明，能够实现用户便利性更高的证明服务，或者减小隐私信息的泄漏风险。
附图说明
图1是表示实施方式的MPC-ZKP系统的结构的示意图。
图2是用于说明使用图1的MPC-ZKP系统的优点的保密性的示意图。
图3是用于说明使用图1的MPC-ZKP系统的优点的逻辑透明性的示意图。
图4是用表形式表示MPC-ZKP系统中实现的证明模式的特征的图。
图5是图1的MPC参加方的MPC参加方(也称为MPC参加服务器)的硬件结构图。
图6是表示图1的MPC参加方的MPC参加方的功能结构例的框图。
图7是表示为了管理图1的MPC参加方组而由服务提供者运用的管理服务器的功能结构例的框图。
图8是表示图7的验证逻辑表达式DB的一例的数据结构图。
图9是表示图7的数据主体DB的一例的数据结构图。
图10是表示图7的数据类DB的一例的数据结构图。
图11是表示图7的验证者DB的一例的数据结构图。
图12是表示图7的个别策略DB的一例的数据结构图。
图13是表示图7的验证历史DB的一例的数据结构图。
图14是表示图1的数据主体终端的功能结构例的框图。
图15是表示数据生成者的终端即数据生成者终端的功能结构例的框图。
图16是表示图1的验证者终端的功能结构例的框图。
图17是表示验证者终端16的验证逻辑表达式DB的一例的数据结构图。
图18是表示MPC-ZKP系统中的证明的序列的流程的图。
图19是表示数据生成者关于对第三者提供已获取同意的情况下的MPC-ZKP系统的结构的示意图。
图20是表示MPC-ZKP系统中的用命题函数进行的证明(证言)的序列的流程的图。
图21是数据主体的数据主体终端的显示器上显示的输出隐私泄漏通知画面的代表画面图。
图22是表示MPC参加方9中的输入值DB的一例的数据结构图。
图23是表示MPC参加方9中的追加信息DB的一例的数据结构图。
图24是表示MPC参加方9的份额保存部中的份额DB的一例的数据结构图。
图25是表示MPC参加方9中的一系列动作的流程图。
具体实施方式
以下，参考附图详细说明实施方式。另外，以下实施方式并不限定请求的权利范围的发明，并且实施方式中说明的特征的组合的全部并不一定对于发明是必要的。也可以将实施方式中说明的多个特征中的两个以上特征任意地组合。另外，对于相同或者同样的结构附加相同的参考编号，省略重复的说明。
(实施方式)
实施方式涉及通过组合使用作为秘密计算之一的基于秘密共享的多方计算和ZKP，来实现附带隐私保护的委托属性证明器的MPC-ZKP系统。
本实施方式的MPC-ZKP系统中通过组合使用MPC和ZKP，对于数据主体放出的数据，能够在该数据的保管、基于该数据的计算、计算结果输出、结果输出的验证中一贯地，排除在关于请求证明的命题的结论以外暴露过多的隐私的行为。换言之，能够用MPC和ZKP保护隐私，用查询监查法限制输出隐私的泄漏。
本实施方式的MPC-ZKP系统的主要特征(但不限定于此)如下所述。
1.证明时的隐私保护
本实施方式的MPC-ZKP系统中，对于证明的受委托方或验证者，不需要以能够理解的状态交付包括隐私的数据。MPC-ZKP系统中，用以下2个机制保护隐私。各自的详情在后文中叙述。
●输入隐私保护功能(秘密计算，ZKP)
●输出隐私保护功能(查询监查法)
2.验证的逻辑透明性
本实施方式的MPC-ZKP系统中，能够在示出验证的结论的同时，使验证的逻辑唯一，使其具有透明性。另外，对于数据按数字签名与消息的配对进行管理，在将其作为Witness(见证)的基础上，在ZKP的验证逻辑(Relation)中包括“消息的完整性能够用签名和公开密钥验证”，由此能够使数据的出处(数据生成者)明确。
3.验证的共通化
本实施方式的MPC-ZKP系统中，使主旨相同的验证共通化，对验证所需的数据(Witness和Instance)进行分类，由此能够促进单次化、或者实施关于相同数据(Witness和Instance)的多个验证。另外，见证(Witness)是用于验证的非公开信息，事例(Instance)是用于验证的公开信息。
4.离线证明
如后所述，取决于ZKP的方案，用曾证明的计算结果，不仅能够说服当初的验证者，此后也能够说服多个验证者(是Transferable)。利用该性质，能够仅在可携带的终端中保存证明结果(从证明的受委托方处删除)，由终端的持有者(使用者)对验证者面对面地、或者经过专用线路地进行证明。
5.证明的委托、代理证明
本实施方式的MPC-ZKP系统中，想要对数据保密的本人(数据主体)即使因某种理由而不能进行证明行为，即使不知道证明方法(例如ZKP的计算方法)也能够通过仅准备数据并使数据份额化、使其秘密共享地对证明的受委托方(MPC-ZKP系统的提供者)提供，而实施验证者请求的验证。能够代理地证明的优点，是例如在本人不在(或者死亡、失踪)、终端遗失等导致的暂时性的权限丧失、信息技术的素养不足、受到当局的询问等状况下能够被承认。即使这样代理进行证明，也可以如上所述地完成隐私保护。
6.单纯证言(命题函数)的说服力的强化
对于某一命题，即使证明的受委托方计算MPC的命题函数，在保护作为依据的数据的隐私的同时，成功输出了验证结果(证言)，但仅单纯举出证言，也不一定会说服验证者。这是因为，不能否认存在受委托方(执行MPC的命题函数的人物)与委托方(数据主体等)相互勾结、欺骗验证者、或者数据主体对验证者提出虚假的证据、或者因证明者的能力不足(证明计算的错误、缺陷)而导出错误的验证结果等可能性。换言之，在简单的代理证明，仅提出命题函数的输出是缺乏说服力的。例如提供MPC的命题函数的执行结果相当于这样的单纯的证言。
本实施方式的MPC-ZKP系统中，提供验证者故意地或者随机地输出关于与先前执行的命题函数完全相同的命题的ZKP的Proof(证据)的功能。即，对于上述单纯的证言，设置能够突发地检查结论的正确性和所采用的验证逻辑的流程的妥当性的功能。其效果是牵制证明的受委托方使其难以作出非法的证言。
通过上述机制，在证明的受委托方中，产生对于不作伪证的较强的动机。这是因为在作伪证被人得知的情况下，会显著地损害信用。即，在博弈论的观点上，通过故意在证明系统中嵌入难以作伪证的机制，能够使单纯证言(命题函数的结果)具有较强的说服力。结果上，在减少进行计算成本高的ZKP的计算的机会的同时，单纯证言、即MPC的命题函数的输出结果的说服力能够得到与ZKP相当的说服力。作为其应用，设对基于秘密x的任意计算程序f(x)进行MPC的输出结果为y时，能够证明“f(x)的结果是y”这一命题，所以能够促成对于不输出错误的f(x)的计算结果的较强的动机。
7.Interactive ZK中的证明者与验证者的组合爆炸的解决
计算Interactive ZK的情况下，从证明开始直到证明结束，证明者与验证者都必须能够对话(必须相互在线)。特别是数据主体用自己的终端进行证明的情况下，“验证者：证明者”的组合成“多：多”的关系，会发生所谓组合爆炸。本实施方式的MPC-ZKP系统中，能够在保护隐私的同时，将多个数据主体的证明者的角色委托至MPC参加方，使其集中至一方。结果，将“验证者：证明者”的组合变换为“多：一”的关系。
8.使用两人以上的数据主体的Witness的证明
在使用明文的Witness的现有的ZKP中，要进行基于多个数据主体的秘密(Witness)的证明时，需要采用以下任一种方法。
(1)将各数据主体的Witness收集至可信任的第三者的环境中，请求在此处计算ZKP。该情况下，需要放弃针对可信任的第三者的环境(TTP，Trusted Third Party)进行的隐私保护。
(2)各个数据主体计算仅基于自身的Witness的证明。但是，该情况下基于将两者的信息合并(例如：合计)的信息的证明变得困难，并且Proof(证据)与数据主体的数量相应地增加，存在各数据主体的输出隐私泄漏的风险。
另一方面，在MPC-ZKP系统中，对于各个数据主体的Witness，针对数据主体本人以外的所有人进行了隐私保护(秘密共享)，所以能够保护全部数据主体的Witness地，计算基于多个数据主体的Witness的证明。
图1是表示实施方式的MPC-ZKP系统2的结构的示意图。本例中，设想患者请医师看诊，并对国境、县境等的管理局通知其结果的状况。MPC-ZKP系统2具有患者等数据主体4所持有的数据主体终端12、保存医师和医院等数据生成者6生成的数据及其份额的数据生成者数据库(DB)14、由参加MPC的多个MPC参加方9组成的MPC参加方组10、管理任一MPC参加方组10的管理信息的管理服务器22、以及国境、县境等的管理局等验证者8所持有的验证者终端16。MPC参加方组10中包括的各MPC参加方(有时也称为MPC参加服务器)中，安装有用MPC执行ZKP用的协议。MPC-ZKP系统2的各构成要素(数据主体终端12、数据生成者DB14、MPC参加方组10的各MPC参加方、验证者终端16)经由互联网等网络相互可通信地连接。另外，本实施方式中，以数据主体终端12与数据生成者DB14分开构成的情况为例进行说明，但数据生成者DB14也可以包括在数据主体终端12中。
对MPC-ZKP系统中的ZKP的提供方式进行说明。一般而言，ZKP的计算过程能够分类为Setup、Prove、Verify这3个步骤。本实施方式中，用MPC实施其中的Prove。即，对于Witness用k-out-of-n门限秘密共享法(n≥k≥2)进行秘密共享，使其成为非公开值之后，用基于秘密共享的多方计算(MPC)进行以Witness为输入值的Prove的步骤。另外，设定基于安全参数l的质数q、生成元g、i∈{0,1,…,n-1}，n是MPC参加方的数量，将它们作为公开值。另外，Witness用w表示，对w用k-out-of-n门限秘密共享法进行秘密共享得到的份额用{w0,w1,…wn-1}表示。wi是对MPC参加方Pi分发的。k-out-of-n门限秘密共享法中，能够用n个中的k以上个MPC参加方保存的份额进行重现(Reconstruct)，n≥k≥2。用满足功能完备性(Functional Completeness)的MPC，能够实现所有ZKP。
zk-SNARKs和Groth-Sahai请求可信设置(Trusted Setup)。Trusted Setup是对可信任的参与方请求进行关于某一命题的零知识证明的准备(Setup)的方式。例如参加的参与方对随机数加密，将其值作为CRS公开。具有该随机数被证明者得知时能够进行伪证的弱点(Soundness受到威胁)。因此，在Trusted Setup时多个参与方参加、合作，利用同态性等性质，发布将各参与方的随机数相加得到的CRS。由此，只要参加的全部参与方中的至少1个参与方拒绝提供随机数，就能够防止伪证。特别是在作为zk-SNARKs的子类的Ligero和Sonic等一部分实现中，能够减小请求的Trust(信赖)。
本发明中，MPC参加方在保存秘密的份额的立场上受到信任，配置了多个参与方(n≥2)，所以MPC参加方的全部或一部分可以兼具受信任的参与方的职责。
作为例子，示出zk-SNARKs的步骤(以下1.～3.)。
1.MPC参加方共同进行的Trusted Setup的计算
QAP<-Compile(relation)
CRS<-Setup(QAP)
其中，relation是与验证的逻辑对应的验证逻辑表达式，QAP是与relation(验证逻辑表达式)对应的Quadratic Arithmetic Program(二次算术程序)(或者也可以采用R1CS)，CRS是Common Reference String(公共参考字符串)，CRS＝{pk,vk}，pk是ProvingKey，vk是Verification Key(验证密钥)(以下有时将CRS记载为追加信息)。
2.MPC进行的Prove
πi<-Prove(CRS,x,wi)
其中，x是Instance。
MPC参加方Pi对验证者提供πi。
3.验证者进行的Verify
π<-Reconstruct(π0,π1,…,πn-1)
{accept,reject}<-Verify(CRS,x,π)
其中，accept是接受证明，reject是拒绝证明。
数据主体4在本例中是患者，是提供的数据的持有者，或者拥有隐私权的本人。数据主体4不限于个人，也可以是组织。
数据生成者6是观测现象、将其数据化的角色的人物。它也是数据主体4最初寄存数据的第一数据管理者。本例中，数据生成者6是对患者进行诊察、或者获取、分析受检体、并进行数据化的医师/医院。另外，其他例子中，数据生成者6是观测用终端和传感器等检测的现象、进行数据化的服务运营者。
服务提供者7是使用MPC-ZKP系统2的服务的运营者。服务提供者7运用MPC参加方组10，或者将运用委托至第三者。服务提供者7从数据生成者6(第一数据管理者)经由数据主体4接收保管数据的份额，所以也可以称为第二数据管理者。在后述的第三者提供版中也可以称为数据处理者。
MPC参加方9是进行秘密计算和对证言(命题函数)或证据(ZKP)进行计算(数据处理)的服务器，是构成MPC参加方组10的各个服务器。MPC参加方组10中，包括多个MPC参加方9，存在同一组织管辖的服务器之间进行MPC的情况，和不同的多个组织管辖的服务器之间(或者节点之间)进行MPC的情况。
验证者8是使用第二数据管理者(服务提供者、MPC参加方)作出的证据、证言(ZKP、命题函数的输出)的人物，本例中是国境、县境等的管理局。验证者8是要验证证明、证言的人物。也存在服务提供者7是验证者8的情况。
管理服务器22是使用MPC-ZKP系统2中的秘密计算和零知识证明的方案的服务提供者管理的服务器，对MPC参加方组10进行管辖。管理服务器22登记、保存由验证者8生成的验证逻辑表达式(有时也称为逻辑/算术运算回路)，响应来自数据主体终端12和数据生成者终端24、MPC参加方9的请求，对请求源提供验证逻辑表达式。
参考图1，说明MPC-ZKP系统2中的从登记验证内容起的、生成用于验证的数据、计算证明、直到验证的处理的流程。另外，假设数据主体4和验证者8已预先在服务提供者7的管理服务器22中进行了用户登记，已分别完成了数据主体ID和验证者ID的发放。
(1)验证者8从验证者终端16将验证逻辑表达式登记至管辖MPC参加方组10的管理服务器22。此时，由管理服务器22对验证逻辑表达式赋予验证逻辑ID。
(2)数据主体终端12确认验证者8请求的验证逻辑ID，从管辖MPC参加方组10的管理服务器22读取与验证逻辑ID关联的验证逻辑表达式。用于证明的数据和数据类(数据的形式和要件)和计算方法(命题函数、ZKP的计算方法)根据验证逻辑表达式唯一地决定。由此，数据主体4确定观测现象并生成必要的数据的数据生成者6(例如医师/医院、公共机构)。
(3)数据主体4(患者)(经由数据主体终端12)对数据生成者6(例如医师/医院、公共机构)通知验证逻辑ID。数据生成者终端24从管理服务器22读取与验证逻辑关联的验证逻辑表达式。用于证明的数据和数据类(数据的形式和要件)根据验证逻辑表达式唯一地决定。数据主体4(患者)受到数据生成者6(例如医师/医院、公共机构)的观测(例如诊察/检查、身份确认)、进行评价时，由数据生成者终端24读取评价结果的数据。
(4)数据生成者终端24将所读取的数据加工为数据类的形式，用数据生成者6的公开密钥加密方式的私有密钥sk实施数字签名。另外，数据生成者6的公开密钥pk例如能够用PKI等获取。设所生成的数据为w。设对数据的数字签名为ws。将(w,ws)的组称为带有签名的见证(Witness)。数据生成者终端24将生成的带有签名的见证(w,ws)保存在数据生成者DB14中。
(5)数据主体终端12从数据生成者DB14获取、读取带有签名的见证(w,ws)。数据主体终端12为了验证接收到的带有签名的见证(w,ws)的妥当性，而用从PKI等获取的数据生成者的公开密钥pk，确认用数字签名进行的完整性的验证成功。数据主体终端12对带有签名的见证(w,ws)进行k-out-of-n门限秘密共享(n≥k≥2)。设对w进行秘密共享得到的份额为{w0,w1,…,wn-1}。同样地，设对ws进行秘密共享得到的份额为{ws0,ws1,…,wsn-1}。将(wi,wsi)的组称为带有签名的见证的份额。其中，i∈{0,1,…,n}，n是MPC参加方组10的参与方数量。
(6)数据主体终端12在接受表示数据主体4同意与验证逻辑ID关联的处理内容(＝验证逻辑表达式、隐私策略)的操作时，对MPC参加方组10的各MPC参加方Pi发送带有签名的见证的份额(wi,wsi)。
(7)MPC参加方组10用各MPC参加方Pi中的带有签名的见证的份额(wi,wsi)和从PKI等获取的数据生成者6的公开密钥pk，基于与验证逻辑ID关联的验证逻辑表达式，进行使用MPC的证言(命题函数)的计算。各MPC参加方Pi得出证言的份额τi。
(8)验证者8从数据主体4接受数据主体ID的通知。验证者8的验证者终端16从MPC参加方组10的各MPC参加方Pi接受认证，从MPC参加方组10获取与验证逻辑ID和数据主体ID双方关联的证言的输出份额{τ0,τ1,…,τi}(从MPC参加方Pi获取τi)，进行Reconstruct(即收集秘密共享的值并复原为原本的值)而得出证言τ。验证者8不承认证言τ的情况下，对验证者终端16输入该情况。验证者终端16在接受表示不承认证言的输入时，对MPC参加方组10请求用零知识证明得到的证据(Proof)。或者，验证者8并非不承认τ的情况下，验证者终端16也能够随机地对MPC参加方组10请求零知识证明。
(9)接受了用零知识证明得到的证据(Proof，即上述Prove步骤的输出)的请求的情况下，MPC参加方组10的各MPC参加方Pi基于与验证逻辑ID关联的验证逻辑表达式，进行使用MPC的ZKP的计算。与验证逻辑ID关联的验证逻辑表达式中登记的ZKP方案(ZKP的种类)例如是NIZK(Non Interactive ZK)的情况下，MPC参加方Pi得出作为证明结果的证据(Proof)的输出份额{π0,π1,…,πn-1}。另一方面，与验证逻辑ID关联的验证逻辑表达式中登记的ZKP方案例如是Interactive ZK的情况下，MPC参加方Pi：(1)对验证者8的验证者终端16发送承诺，(2)验证者8的验证者终端16对MPC参加方组10的各MPC参加方Pi发送了质询之后，(3)MPC参加方Pi得出作为证明结果的证据(Proof)的输出份额{π0,π1,…,πn-1}。此处，有时反复进行(2)和(3)(Soundness Amplification)。
(10)验证者8的验证者终端16用凭证等从MPC参加方组10接受认证，从MPC参加方组10获取与验证逻辑ID和数据主体ID双方关联的证据(Proof)的输出份额{π0,π1,…,πn-1}(从MPC参加方Pi获取πi)，进行Reconstruct，得出证据(Proof)即π。另外，与验证逻辑表达式中登记的ZKP的方案相应地，从MPC参加方组10获取上述Verify所需的CRS(追加信息)。计算Verify，由验证者8的验证终端16接受(Accept)或拒绝(Reject)验证的内容。
图1的MPC-ZKP系统2中，MPC参加方组10只要能够收集多个数据生成者创建的归属于同一个人的数据，就能够进行关于同一个人的多方证明。以往，需要收集数据生成者发放的文件并对验证者提出，请求其进行验证。该文件中，大多包括本来验证者可以不知道的多余的信息。图1的MPC-ZKP系统2中，MPC参加方组10在保护隐私的同时，一齐实施目的的证明。
另外，MPC参加方组10通过保密地收集不同人物的数据，能够不泄漏隐私地，进行将不同人的数据组合的证明。在现有的ZKP中为了实施同样的处理，需要将明文配置至同一计算机进行计算。这样，两人中的至少一方的隐私会对本人以外的某人泄漏。关于这一点，图1的MPC-ZKP系统2中，MPC参加方组10在保护多人的隐私的同时，一齐实施目的的证明。
另外，存在对于数据主体4与旧数据主体ID分别地发放新数据主体ID之后、使用后者的数据主体ID实施证明的可能性。由此，能够控制使验证者不能与过去的验证内容按身份关联。
作为图1的MPC-ZKP系统2的应用例，考虑应用于冠状病毒蔓延、限制地区之间的移动时判断是否允许移动的情况。在地区之间移动时，管理局考虑在验证本人的感染概率非常低之后，允许移动。“感染概率非常低”的定义各不一致，所以管理局准备如下所述的验证逻辑表达式(带有签名的CRS)。
验证逻辑表达式：如果在医院接受PCR检查，结果是阴性，并且过去1周以内未曾接近集群感染发生地区，则感染概率非常低。
想要移动至其他地区的人，可以事先采取如下所述的行动。
1.从管理局接受了验证逻辑表达式的服务提供者或MPC参加方，计算验证逻辑表达式(例如：Rank 1 Constraint System、Quadratic Arithmetic Program)、和验证逻辑的运算所需的数据的CRS(追加信息)。
2.数据主体将该验证逻辑表达式、CRS(追加信息)下载至终端后，对数据生成者请求并接受必要的数据(例如：在医院中接受诊察，起动位置信息服务)。
3.用已下载的验证逻辑表达式和数据导出计算结果(Proof)。
4.通过对管理局提出计算结果来实施证明。此时，通过数据主体预先获取服务提供者或MPC参加方的带有签名的验证逻辑表达式和CRS(追加信息)，或者管理局事先从服务提供者或MPC参加方接受验证逻辑表达式和追加信息(CRS)，也能够离线(本地、局域网)进行该证明。
本实施方式的MPC-ZKP系统2使上述2.的数据秘密共享至MPC参加方组10地进行登记，能够进行通过在这些MPC参加方之间用MPC进行计算而实施证明的委托证明。另外，服务提供者或MPC参加方通过对逻辑进行协调来使证明的基准共通化，使ZKP所需的回路设计和Setup归一化，由此能够避免滥立目的相同的证明。
图2是用于具体说明使用图1的MPC-ZKP系统2的优点的保密性的示意图。用MPC-ZKP系统2实现了保密性、即排除不必要的信息公开。以往，医院、地图服务运营者等不同的多种数据生成者观测患者等评价对象，分别生成观测结果(例如表示诊察结果的阴性/阳性的xa、未曾接近集群感染发生地区的依据xb等)。然后，将该数据xa、xb收集至一处进行判断，决定是否允许移动。该现有技术的问题点在于隐私问题，即必须将原始数据收集至一处。作为评价对象，有不想对验证者展示必要以上的自己的信息的想法，并且该现有技术中数据的交换是书面进行的，所以事务手续变得冗长。
与此相对，使用本实施方式的MPC-ZKP系统2的情况下，例如数据生成者一方(也可以由数据主体进行)使数据份额化，对MPC-ZKP系统2不是提供原始数据而是提供份额。例如，表示诊察结果的阴性/阳性的xa被分割为xa1、xa2这两个份额，分别发送至不同的服务器(即MPC参加方)。未曾接近集群感染发生地区的依据xb也同样被分割为xb1、xb2这两个份额，分别发送至不同的服务器。MPC-ZKP系统2(的MPC参加方组10)接受份额化后的数据(不是原始数据本身)，(经由验证者终端16)对验证者8提供验证结果。这样，能够用MPC(份额化)保护隐私地进行验证。
图3是用于说明使用图1的MPC-ZKP系统2的优点的逻辑透明性的示意图。用MPC-ZKP系统2保障逻辑透明性，排除伪造。以往，医生、专家等评价者(证人)观测患者等评价对象，对观测结果的数据x按照评价逻辑进行评价，对国境、县境等的管理局等验证者提供评价结果即结论y。结论在大多情况下被压缩为是否感染等是(Yes)/否(No)。该现有技术的问题点有以下2个。
(1)能力的问题
评价者得出结论的评价逻辑是否具有妥当性成为问题。因评价者与验证者的观点的不同而可能在“接受(Accept)”的基准上产生差异。
(2)意图的问题
存在评价者篡改证据的可能性，并且存在作出虚假证言的可能性。
与此相对，使用本实施方式的MPC-ZKP系统2的情况下，数据x被份额化(图3所示的例子中设想为2-out-of-2秘密共享，用x1、x2表示份额)，所以保存了数据的保密性。验证逻辑表达式离开评价者、被验证者检查和部署，并且由评价对象同意。该验证逻辑表达式受CRS约束，所以不能进行验证逻辑表达式的篡改。验证逻辑表达式和份额被提供至MPC-ZKP系统2，来生成证言。验证者收集MPC-ZKP系统2输出的输出份额(例如y1、y2)并复原为结论y，由此能够得出非感染者的证明。这样，只要数据本身没有被篡改，就能够作出具有客观性的证言。关于数据本身的篡改，能够通过数据生成者对份额签名等实现部分的篡改对策。
图1的例子中，对于数据生成者6关于对第三者提供数据(的份额)不从数据主体4获取同意的情况进行了说明，但不限于此，也存在数据生成者6关于对第三者提供数据的份额能够从数据主体4获取同意的情况。图19是表示数据生成者6关于对第三者提供已获取同意的情况下的MPC-ZKP系统2的结构的示意图。带有签名的见证(w,ws)被数据生成者6份额化为(wi,wsi)，不经由数据主体终端12地，从数据生成者DB14对MPC参加方组10的各MPC参加方9提供。
接着，说明MPC-ZKP系统2的详情。图4是用表形式表示MPC-ZKP系统2中实现的证明模式的特征的图。MPC-ZKP系统2中有(1)由用户终端执行的零知识证明模式、(2)用MPC执行的命题函数证言模式、(3)用MPC执行的零知识证明模式这3个证明模式，用户即验证者8能够与要件相应地分情况使用这3个模式。各模式的特征如图4所示。如图所示，用MPC执行的命题函数证言模式不具备验证逻辑的透明性，但验证者能够随机或任意地请求用MPC执行的零知识证明模式或由用户终端执行的零知识证明模式得到的证明，所以可以发挥对用MPC执行的命题函数证言模式的数据中作出伪证的抑制力的作用。用MPC执行的零知识证明模式计算量庞大，所以如果能够减少该模式的执行次数，则有助于缩短总计算时间。用MPC执行的命题函数证言模式中不具有验证逻辑的透明性，但与用MPC执行的零知识证明模式相比能够迅速地输出结论(证言)。从而，通过验证者故意或随机地请求执行用MPC执行的零知识证明模式得到的证明，能够在减少耗费计算负荷的场景的同时，防止在用MPC执行的命题函数证言模式得到的证言(命题函数的结果)中作出伪证。
接着，对于图1的验证者终端16的结构进行说明。关于验证者终端16的硬件结构，如参考图5在后文中所述，可以具有与图5中记载的硬件结构同样的硬件结构。
对于验证者终端16的功能结构例，参考图16进行说明。另外，该图和以下说明的框图中示出的各模块，能够以硬件方式用计算机的CPU等元件或机械装置实现，也可以以软件方式用计算机程序等实现，但此处，描绘了通过其协作而实现的功能模块。从而，这些功能模块能够用硬件、软件的组合以各种形式实现，接触本说明书的本领域技术人员应当理解这一点。
验证者终端16具有验证逻辑表达式获取部162、验证逻辑表达式部署部164、证言请求部165、验证逻辑表达式DB166、证据请求部168和验证部170。验证者终端16中，能够用从MPC参加方组10的各MPC参加方9收集的输出份额，通过ZKP或证言验证命题。
验证逻辑表达式获取部162从管理服务器22读取能够用于验证逻辑表达式的输入数据类，并且按照验证者8进行的输入，获取验证逻辑表达式中的(1)要证明的对象的关系式和(2)应用的ZKP方案。验证逻辑表达式获取部162将所获取的验证逻辑表达式登记在验证逻辑表达式DB166中。
验证逻辑表达式部署部164将验证逻辑表达式DB166中登记的验证逻辑表达式部署至管理服务器22。具体而言，验证逻辑表达式部署部164将验证逻辑表达式(表示Relation的式子)和ZKP方案登记至服务提供者7的管理服务器22，获取与部署的验证逻辑表达式关联的验证逻辑ID。验证逻辑表达式获取部162将验证逻辑表达式与验证逻辑ID关联地登记至验证逻辑表达式DB166。
验证逻辑表达式DB166管理验证逻辑表达式。图17中示出了验证逻辑表达式DB166中保存的数据。验证逻辑表达式DB166中保存的数据例如包括验证逻辑ID、验证逻辑表达式、ZKP方案。另外，验证逻辑表达式DB166也可以还与进行了登记的验证者ID关联，但也可以是与后述的管理服务器22中具有的验证逻辑表达式DB118的数据同样的形式。验证者8能够在任意时机查看验证逻辑表达式DB166的数据。
证言请求部165(与验证者8进行的操作相应地)将请求关于验证逻辑ID和数据主体ID对应值(详情后述)的证言(命题函数)用的证言请求发送至MPC参加方组10的各MPC参加方9。另外，本实施方式中，以将证言请求发送至MPC参加方9的情况为例进行了说明，但也可以将证言请求发送至管理服务器22，由管理服务器22对各MPC参加方9请求证言。
证据请求部168对于MPC参加方9，首先请求与验证逻辑ID和数据主体ID对应值关联的追加信息。之后，对于MPC参加方9，请求用MPC-ZKP系统计算得到的证据(Proof的输出份额(πi))。例如，证据请求部168基于由验证者8进行的操作产生的请求、或者证据请求部168中的规定的判断，生成证据请求并将其发送至MPC参加方9。证据请求部168可以如下所述地进行规定的判断。例如，证据请求部168在获取命题函数的输出份额之后，立即判断本地生成的随机数、或者将获取份额的时刻以后的(使用规定的区块链算法的)公共链中、某一区块高度处的交易散列值作为随机数，判断其是否超过了规定阈值。证据请求部168在上述随机数或交易散列值超过了规定阈值的情况下，(无需等待由验证者8进行的操作产生的请求地)生成证据请求。另外，本实施方式中，以将追加信息的请求和证据请求发送至MPC参加方9的情况为例进行了说明，但也可以将证据请求发送至管理服务器22，由管理服务器22对各MPC参加方9请求追加信息和证据。
验证部170从MPC参加方9获取输出的证言(命题函数)的输出份额，进行Reconstruct(复原)，获取证言τ。
另外，验证部170在请求了证据的情况下，从MPC参加方9获取证据(ZKP)的输出份额(πi)和与验证逻辑表达式关联的追加信息。验证部170通过收集获取的输出份额而复原为ZKP(Proof)。例如，验证部170使用管理服务器22的公开密钥，对带有签名的输出份额、验证逻辑表达式和(使用Trusted Setup的情况下的)CRS(特别是Verification Key)进行认证。另外，验证部170使用复原得到的ZKP(Proof)、验证逻辑表达式和(使用Trusted Setup的情况下的)已认证的CRS的Verification Key进行验证。验证部170例如输出接受(Accept)或拒绝(Reject)中的任一者作为验证结果。
另外，虽然图16中没有明确示出，但验证者终端16也可以进一步具有进行验证者8的登记、获取唯一识别各验证者的验证者ID用的验证者登记部。例如，通过对数据主体4提供验证者ID，数据主体8(在运用关于数据处理的个别策略时)能够实现对验证者的请求的访问控制。
此处，对于上述数据主体ID对应值进行说明。数据主体ID对应值是能够使验证逻辑表达式中的个人的数据交换、能够将验证逻辑表达式反复用于不同的个人的组合的证明用的数据。
例如，考虑使用以下验证逻辑表达式的情况。另外，以下验证逻辑表达式中的SigVerify函数表示使用第一参数的公开密钥对于第二参数的值用第三参数的数字签名验证完整性的函数。
--<验证逻辑表达式>--
DC008[0]+DC008[1]>10000000
&&SigVerify(DC012,DC008[0],DC013[0])
＝＝true
&&SigVerify(DC012,DC008[1],DC013[1])
＝＝true
--------------
该验证逻辑表达式中，DCxxx表示数据类，DC008表示年收入，DC012表示市政府的公开密钥，DC013表示市政府对年收入的签名。“[0],[1],…”是下标，识别各数据类的具体的对象。例如，DC008[0]是A的年收入，DC008[1]指的是B的年收入。这一点能够通过在验证逻辑表达式的ASTs(Abstract Syntax Trees)中从变量中提取下标而实现。但是，包围下标的括号([])也可以使用不同的表达。例如，沿用现有的编程语言(C语言等)的表达作为验证逻辑表达式的语法的情况下，因为与数组表达冲突，所以可以用不同的记号、不同的配置使表达不同。
数据主体ID对应值是能够通过代入而指定数据类的对象的机制，例如用[DS003,DS004]的数组形式指定数据主体ID对应值时，对于DC008[0]和DC008[1]的数据主体，能够分配为：
DC008[0]＝DS003，和DC008[1]＝DS004
该情况下，上述验证逻辑表达式成为表示“作为从同一市政府接受了签名的数据主体的两个人的年收入的合计是否超过1千万日元”的式子。这样，如果改变数据主体ID对应值中列举的数据主体ID的顺序(数组的下标)、或者指定其他ID，就能够将生成的验证逻辑表达式再次用于不同的个人的组合的证明。另外，验证逻辑表达式是以一名数据主体为对象的证明的情况下，上述下标能够省略，对于数据主体ID对应值可以直接指定单体的数据主体ID。
接着，对于MPC参加方9(也称为MPC参加服务器)的结构进行说明。图5是图1的MPC参加方9的硬件结构图的一例。其他MPC参加方、验证者终端16、数据主体终端12、数据生成者终端24也可以具有与图5中记载的硬件结构同样的硬件结构。MPC参加方9包括存储器130、处理器132、通信接口134、显示器136和输入接口138。这些要素分别与总线140连接，经由总线140相互通信。
存储器130是存储数据和程序用的存储区域。数据和程序可以永久地存储在存储器130中，也可以暂时性地存储。处理器132通过执行存储器130中存储的程序，而实现MPC参加方9中的各种功能。通信接口134是与MPC参加方9的外部之间进行数据的发送接收用的接口。例如，通信接口134包括访问网络用的接口，经由该网络与其他MPC参加服务器和数据主体终端12和验证者终端16之间进行数据的传递。显示器136是显示各种信息用的设备，例如是液晶显示器或有机EL(Electroluminescence：电致发光)显示器等。输入接口138是接受来自用户的输入用的设备。输入接口138例如包括鼠标和键盘和在显示器138上设置的触摸面板。
图6是表示图1的MPC参加方9的功能结构例的框图。各MPC参加方9(即Pi)具备输入数据获取部102、事例保存部103、计算部104、数据提供部106、份额删除部108和份额保存部109。
输入数据获取部102获取与要证明的事项相关的数据。数据有2类，是Instance(事例)和带有签名的见证的份额(Witness的份额)。份额获取部102从数据主体终端12或数据生成者终端24经由网络获取Instance和秘密共享得到的带有签名的见证的份额(wi,wsi)。另外，各种份额用{Pi,wi,wsi,vi,τi,πi|i∈{0,1,…,n-1}}表达，n是MPC参加方组10中的MPC参加方9的数量、即参加MPC的参与方数量，i唯一决定各MPC参加方9(Pi)。另外，输入数据获取部102在用参照传递Instance的情况下，进一步经由网络获取其实体(例如数据生成者6的公开密钥)。
输入数据获取部102在MPC参加方组10的MPC参加方9之间进行通信，对以带有签名的见证的份额(Witness的份额)为输入的数字签名的完整性的验证算法进行MPC处理。然后，在MPC参加方9之间共享结果得到的输出份额(vi)，Reconstruct(复原)得到验证的结果(v)。输入数据获取部102在确认验证成功时，将带有签名的见证的份额登记至份额保存部109。进而，输入数据获取部102将Instance登记至事例保存部103。份额数据保存部109和事例保存部103用图22所示的形式(例如数据主体ID、数据类ID和值的组)保存这些数据。
计算部104与接受来自验证者终端16的证言请求相应地进行命题函数的计算，并且与从验证者终端16接受证据请求相应地进行ZKP的计算。
(1)对于接受来自验证者终端16的证言请求的情况进行说明。计算部104从验证者终端16接受关于数据主体ID对应值和验证逻辑ID的证言请求。计算部104接受证言请求时，开始基于该数据主体ID对应值和验证逻辑ID的面向执行命题函数的处理。
计算部104首先从管理服务器22获取验证逻辑表达式和验证逻辑ID。进而，对于(从管理服务器22得到)数据主体ID对应值中包括的全部数据主体ID的个别策略，判断是否满足个别策略DB的数据所示的保护范围。计算部104对于全部数据主体ID都判断为满足保护范围的情况下，基于验证逻辑表达式中包括的数据类的份额和Instance的值，计算符合验证逻辑表达式的命题函数。
计算部104能够将与用于计算的数据主体ID对应值关联的数据(即数据主体ID泄漏的隐私)发送至管理服务器22，使其登记在验证历史DB142中。即，计算部104使管理服务器22管理与数据主体ID对应值相关的那样的数据被用于命题计算，实现必要的隐私控制。
(2)接着，对于接受来自验证者终端16的证据请求而计算ZKP的情况进行说明。该情况下，计算部104事先从验证者终端16接受与数据主体ID对应值和验证逻辑ID相关的追加信息的请求，获取与数据主体ID对应值和验证逻辑ID关联的追加信息。计算部104将所获取的追加信息或计算得到的追加信息发送至验证者终端16。
验证者终端16与接收到追加信息相应地与获取相应地发送证据请求，所以计算部104从验证者终端16接受证据请求。另外，由验证者终端16请求的ZKP的ZKP方案是Interactive ZK的情况下，计算部104在数据主体ID对应值和验证逻辑ID之外，也从验证者终端16接收质询信息。计算部104接受证据请求(或者证据请求和质询信息)时，开始基于该数据主体ID对应值和验证逻辑ID的面向执行ZKP的处理。
计算部104首先从管理服务器22获取验证逻辑表达式和验证逻辑ID。另外，计算部104预先读取对验证者终端16发送的追加信息。此处，计算部104对于(从管理服务器22得到的)数据主体ID对应值中包括的全部数据主体ID的个别策略，判断是否满足管理服务器22的个别策略DB的数据所示的保护范围。计算部104对于全部数据主体ID都判断为满足保护范围的情况下，基于验证逻辑表达式中包括的数据类的份额、Instance的值和追加信息，计算符合验证逻辑表达式的ZKP。之后，计算部104将ZKP计算后得到的输出份额(Proof即π的份额，πi)保存在份额保存部109中。
另外，上述追加信息例如可以按图23所示的数据形式保存在未图示的追加信息DB中，也可以持续规定期间地保存在存储器中。追加信息的数据例如如图23所示，可以与验证逻辑ID和数据主体ID对应值相关联。追加信息中可能包括CRS和承诺。追加信息与ZKP方案相应地不同，ZKP方案属于Schnorr’s Protocol、Sigma Protocol等Interactive ZK的情况下，追加信息例如包括承诺。ZKP方案属于zk-SNARKS和Groth Sahai等、对特定参与方请求Trust的NIZK(Non Interactive ZK)的情况下，追加信息例如包括CRS(Common ReferenceString)。另外，ZKP方案属于RO假设的zk-STARKs等、不对特定参与方请求Trust的NIZK的情况下，追加信息例如包括承诺(Merkle Tree，Merkle Tree Root)。
另外，用命题函数或ZKP得到的输出份额，例如可以按图24所示的数据形式保存在份额保存部109中。图24所示的数据形式中，例如保存与数据主体ID对应值、验证逻辑ID相关联的命题函数、ZKP的输出份额和计算开始日期时间。
数据提供部106在计算部104执行了命题函数的情况下，将作为计算结果得到的输出份额输出至验证者终端16。另外，计算部104执行了ZKP的情况下，将作为计算结果得到的输出份额和计算部104中使用的追加信息输出至验证者终端16。另外，此时，数据提供部106也可以对于(从管理服务器22得到的)数据主体ID对应值中包括的全部数据主体ID的个别策略，判断是否满足个别策略DB的数据所示的保护范围，对于全部数据主体ID都判断为满足保护范围的情况下，将输出份额(ZKP的情况下还包括追加信息)输出。
份额删除部108从数据主体4使用的数据主体终端12和/或数据生成者6使用的数据生成者终端24接受删除请求时，从份额保存部109中删除作为对象的份额。
图7是表示为了管理图1的MPC参加方组10而由服务提供者7运用的管理服务器22的功能结构例的框图。管理服务器22具有管理信息控制部110、设置部112、验证请求获取部114、判断部116、验证逻辑表达式DB118、数据类DB120、数据主体DB122、验证者DB124、个别策略DB128和验证历史DB142。
管理信息控制部110发放唯一决定管理服务器22的各种DB中登记的数据(例如数据主体、验证者、验证逻辑表达式、数据类等)的ID。数据主体ID是唯一识别数据主体的信息，管理信息控制部110在登记数据主体时发放该ID。另外，数据主体不限于个人，也可以是组织。验证者ID是唯一识别验证者的信息，管理信息控制部110在登记验证者时发放该ID。另外，也可以将服务提供者登记为验证者。验证逻辑ID包括验证逻辑表达式和ZKP方案(ZKP的种类)。验证逻辑ID唯一决定验证逻辑表达式与ZKP的种类的组合。本实施方式中，命题函数和ZKP都能够基于同一形式的验证逻辑表达式进行计算。数据类ID是唯一确定数据类的信息，数据类包括数据的类名(例如“年龄”)和数据的类型(例如布尔型或比特数等)，在指定数据类ID时，唯一识别数据的类及其公开/非公开的区别(即是见证还是事例)。数据类ID是管理信息控制部110在登记数据类时发放的。
另外，管理信息控制部110与系统2中的验证者终端16和数据主体终端12或MPC参加方9等之间进行数据的发送接收，控制对各种DB的数据写入和读取。以下，对于管理信息控制部110进行的各种数据的登记等进行说明。
(1)数据主体信息的登记控制
登记信息控制部110在数据主体终端12中登记数据主体的信息时，从数据主体终端12获取数据主体的名字/住址等身份信息、和对于身份信息从认证机构得到的签名，在数据主体DB122中登记数据。此时，管理信息控制部110对于新数据主体发放数据主体ID，并发送至数据主体终端12。数据主体DB122例如如图9所示，记录将识别数据主体的数据ID、识别数据类的数据类ID和对数据主体公开的数据关联的数据。另外，数据主体DB122中记录的ID的信息可以公开，公开的情况下视为Instance。数据主体DB122中记录的数据主体的信息，被作为份额分别记录在MPC参与方9中而保密。数据主体如果获取多个数据主体ID，按目的分情况使用数据主体ID的信息，则信息被分散化，能够防止通过收集1个数据主体的多个信息而得知该数据主体的身份信息整体。
(2)验证者信息的登记控制
管理信息控制部110在验证者终端16中登记验证者的信息时，从验证者终端16获取验证者的身份信息，在验证者DB124中登记数据。此时，管理信息控制部110对新验证者发放验证者ID，并发送至验证者终端16。验证者DB124例如如图11所示，记录将验证者ID、验证者组织名和特权查询标志关联的数据。特权查询标志是表示与设定的隐私策略无关地、具有能够得到证言和证据的输出份额的特权的验证者的标志。标志被设定为“True”的情况(例如服务提供者和具有权限的行政机构等)，表示具有该特权。
(3)数据类的参照控制
管理信息控制部110在验证者在验证者终端16中生成、编辑验证逻辑表达式时，从验证者终端16接受数据类的参照，将数据类的信息发送至验证者终端16。数据类的信息例如由服务提供者或数据生成者6等登记，管理信息控制部110在登记该数据类时，发放数据类ID并在数据类DB120中登记信息。数据类DB120例如如图10所示，记录将数据类ID、数据类名、该数据类的数据形式、更详细地说明数据形式的数据形式详情和公开分类关联的数据。数据类型例如是Bool值或比特数等。只要决定了数据类的形式，就决定了该数据的份额的种类(形式)，所以也可以认为在数据类DB120中登记了数据的份额的形式。另外，公开分类被设定为非公开的数据类是见证，公开分类被设定为公开的数据类是事例。
(4)验证逻辑表达式的登记/参照控制
管理信息控制部110在从验证者终端16发送了验证逻辑表达式时，将该验证逻辑表达式登记至验证逻辑表达式DB118。此时，管理信息控制部110发放验证逻辑ID，将发放的验证逻辑ID发送至验证者终端16。验证逻辑是DB118如图8所示，将确定验证逻辑表达式的验证逻辑ID、验证逻辑表达式和识别执行ZKP的情况下使用哪个ZKP算法(方案)的ZKP方案关联地记录。验证逻辑ID是将处理内容(计算式)和输入数据形式(json、yaml、toml等)变换为散列值得到的值，唯一识别验证逻辑表达式和带有签名的验证逻辑表达式。验证逻辑表达式可以是伪代码。另外，验证逻辑表达式也可以使用“#”等预先决定的特定记号，作为识别伪代码内的注释用的记号。
管理信息控制部110在验证者终端16为了对MPC参加方9提供验证逻辑ID和验证逻辑表达式而访问验证逻辑ID和验证逻辑表达式的情况下，对验证者终端16提供验证逻辑ID和验证逻辑表达式。或者，也可以在由验证者终端16请求对MPC参加方9提供验证逻辑ID和验证逻辑表达式的情况下，对MPC参加方提供验证逻辑ID和验证逻辑表达式。
另外，管理信息控制部110根据需要或者与来自数据主体终端12的请求相应地，将验证逻辑ID和验证逻辑表达式发送至数据主体终端12。
(5)个别策略的登记控制
管理信息控制部110与从数据主体终端12接受对验证者ID的隐私策略的登记请求相应地，将该隐私策略登记至个别策略DB128。个别策略DB128如图12所示，例如记录将识别设定隐私策略的数据主体的数据主体ID、识别与该隐私策略相关的数据类的数据类ID、验证逻辑ID、确定作为该隐私策略的对象的验证者的验证者ID、该隐私策略的有效期间、和该隐私策略的保护范围关联的数据。
有效期间表示应用该隐私策略的期间，图12的例子中按分钟单位表示。经过指定的期间后不再保护。保护范围表示允许通过执行多个证明而将真值处于哪个范围中缩小至何种程度的范围。具体而言，以表示1980年10月1日的出生年月日的数据为例进行说明。例如，在执行了数据主体的出生年月日是1975年以后(>19741231)的证明(1)和该出生年月日是1996年以前(<19960101)的证明(2)时，数据主体的出生年月日处于1975年至1996年之间这一隐私泄漏。但是，例如隐私泄漏的期间与用保护范围指定的值相比更大的情况下，允许证明(1)和证明(2)。与此相对，进一步进行该数据主体的出生年月日是1983年以前(<19840101)的证明的情况下，隐私泄漏的范围与用保护范围指定的值相比更小(即缩小至较窄的范围)的情况下，拒绝执行该证明。
另外，数据类具有的值的尺度中，有名义尺度(用于区分概念的尺度)、顺序尺度(在大小关系上具有含义的尺度)、间隔尺度(间隔的大小即数值的差)上具有含义的尺度、比例尺度(在数值的差和数值的比上都具有含义的尺度)等。上述保护范围能够对于这些尺度中的顺序尺度、间隔尺度和比例尺度设定。
(6)验证历史的登记/参照控制
由MPC参加方9执行命题函数或ZKP时，判断是否MPC参加方9即使执行证明也不违反个别策略时，参照验证历史DB的数据。此时，管理信息控制部110与MPC参加方9的参照请求相应地，将对应的验证历史DB的数据发送至MPC参加方9。另外，在由MPC参加方9执行命题函数或ZKP之后，从MPC参加方9接受验证历史的登记。具体而言，将对于MPC参加方9用于执行命题函数或ZKP的验证逻辑表达式中包括的(与数据主体ID对应值关联的)各数据类、登记数据的可用的上限值和下限值的请求发送至管理服务器22。该情况下，管理信息控制部110将该历史信息登记至验证历史DB142。验证历史DB142例如如图13所示，例如记录将数据主体ID、数据类ID、验证者ID、下限值、上限值和各自的最终证明日期时间等关联的数据。作为下限值和上限值的记录，通过记录与验证逻辑中的事例的比较(证明)，能够实现使用个别策略的是否允许执行证明的判断。另外，关于最终证明日期时间的项目，在用NIZK执行ZKP的情况下，也可以用视为证明执行时刻的未来的值用的规定值(例如99999999)填入最终证明日期时间。
上述管理信息控制部110进行的登记和参照等处理的顺序如上所述，可以控制为数据主体信息的登记控制、验证者信息的登记控制、数据类的参照控制、验证逻辑表达式的登记/参照控制、个别策略的登记控制、验证历史的登记/参照控制的顺序。或者，管理信息控制部110也可以在任意时机进行个别策略的登记控制，也可以与从MPC参加方9接收了表示接受验证者对证明的请求的通知相应地，进行个别策略的登记控制。
设置部112生成算法和带有签名的CRS。设置部112在验证逻辑表达式被部署时，生成用于用MPC计算与该验证逻辑表达式对应的ZKP用的MPC用的协议。同时设置部112计算CRS。ZKP方案请求Trusted Setup的情况下，能够不仅由管理服务器22、而是通过由全部MPC参加方9合作使串通变得困难。设置部112对生成的CRS进行数字签名。设置部112将生成的协议和带有签名的CRS发布至各MPC参加方9。
返回图7，验证请求获取部114从验证者8的验证者终端16经由网络获取证言请求或证据请求。证言请求和证据请求例如包括数据主体ID对应值和验证者8请求的证明逻辑式的验证逻辑ID。
判断部116与获取的验证请求相应地，在保护输出隐私的观点上，判断是否拒绝验证请求。判断部116进行的是否拒绝验证请求的判断，是通过使用个别策略DB128和验证历史DB142中保存的数据而实现的。
对于(基于上述查询监查法的)保护输出隐私的观点，更具体地进行说明。一般而言，验证者不能根据命题函数或ZKP直接得知原本的数据。但是，(如个别策略的登记控制所示)对于验证者对同一数据类的数据的验证不存在限制的情况下，存在通过反复进行验证而在结果上原本的数据泄漏的可能性。例如，对选择明文的对策可能成为问题，特别是使用可取的值的范围狭窄的类进行的计算易于成为问题。
例如，关于年龄，通过如下所述的反复验证，即使不能根据各验证结果得知正确的年龄，也能够通过将多个验证结果汇总，而缩小实际年龄可能取到的范围，确定数据主体是34岁：
●是50岁以上？→False(伪)
●是25岁以上？→True(真)
●是37岁以上？→False(伪)
●是31岁以上？→True(真)
●是34岁以上？→True(真)
●是35岁以上？→False(伪)
本实施方式的输出隐私的保护中，为了使MPC-ZKP中不能完全保护的隐私(输出隐私)的保护最大化，而由MPC参加方9或服务提供者7担当熔断的作用。MPC参加方9或服务提供者7拒绝因验证者8请求的验证逻辑而使隐私显著具有泄漏风险的命题函数或ZKP的计算。在该意义上，MPC参加方9或服务提供者7发挥输出隐私的保护中的熔断的作用。另外，有泄漏风险的基准可以根据服务的性质、与消费者的协定决定。
用管理服务器22实现的输出隐私的保护功能，用个别策略DB128决定数据主体4可以被验证者8得知的隐私的范畴，用判断部116对于顺序尺度以上的数据，保护数据主体4不受到对输出隐私的威胁。判断部116基于用验证请求获取部114获取的验证请求的内容、个别策略DB128中保存的隐私策略、和验证历史DB142中保存的验证的历史，判断是否拒绝验证请求。
更具体而言，由验证者8请求了违反隐私策略的命题函数或ZKP的情况下，判断部116拒绝计算(或者判断部116使MPC参加方9拒绝计算)。个别策略DB128中可能保存的隐私策略的具体列如下所述。
●策略1：在某一期间内(例如2年以内)，对于特定的验证者，避免一定以上的隐私泄漏。
●策略2：对于特定的验证者，避免一定以上的隐私泄漏。
●策略3：在某一期间内，对于全部验证者，避免一定以上的隐私泄漏。
●策略4：对于全部验证者，避免一定以上的隐私泄漏。
上述隐私策略的说明中表述的“一定以上的隐私”，能够按每个数据主体个别地设定。例如用“不希望年龄被以10年单位的误差确定(例如：不足40岁且30岁以上)”、“不希望储蓄额被以100万日元单位的误差确定”这样的条件决定。
对于这样的隐私策略，按每个数据主体和数据(数据类)的种类(例如年龄、收入等)在个别策略DB128中管理。请求了违反隐私策略的命题函数或ZKP的情况下，为了保护数据主体4不受到对输出策略的威胁，判断部116拒绝验证请求。
判断部116在承认了验证请求的情况下，使MPC参加方组10的各MPC参加方9执行命题函数或ZKP，使其对验证者终端16提供结果得到的输出份额。或者，判断部116在承认了验证请求的情况下，对验证者终端16提供验证者DB124中保存的对应的输出份额。
图21是数据主体4的数据主体终端12的显示器上显示的输出隐私泄漏通知画面900的代表画面图。输出隐私泄漏通知画面900是通过参照验证历史DB142而生成的，对数据主体4提示因命题函数或ZKP而泄漏的隐私范围。图21所示的例子中，用斜线示出了年龄中用于验证的判断的范围。另外，图21中采用了一维显示，但也可以采用文氏图等二维显示。
图14是表示图1的数据主体终端12的功能结构例的框图。数据主体终端12具有管理信息请求部144、数据获取部146、数据提供部148、个别策略部150和数据删除请求部145。
管理信息请求部144对于服务提供者7的管理服务器22，请求管理信息(特别是验证逻辑表达式)。管理信息请求部144获取与验证逻辑ID关联的管理信息，并使显示器显示。数据主体4能够查看、确认验证者8请求的验证逻辑表达式，能够对数据生成者6委托生成必要的数据(例如接受医院的诊察等)。
数据获取部146在(用数据生成者6或数据生成者终端24)将带有签名的见证(w,ws)保存在数据生成者6的数据生成者DB14中时，从该数据生成者DB14获取带有签名的见证，并登记至缓存保存部152。另外，数据获取部146从外部获取必要的事例(例如数据生成者6的公开密钥)，并登记至缓存保存部152。
数据提供部148将缓存保存部152中保存的带有签名的见证(w,ws)变换为份额，对MPC参加方组10的各MPC参加方9提供各个带有签名的见证的份额(wi,wsi)(i＝0～MPC参加方数-1)(即使其秘密共享)。数据提供部148在带有签名的见证的份额之外，也对各MPC参加方9提供事例。
个别策略设定部150从管理服务器22读取数据类，按每个数据类设定隐私策略。例如，按照数据主体4进行的操作，按每个数据类设定隐私策略，对管理服务器设定隐私策略。另外，个别策略设定部150能够按照数据主体4进行的操作，设定对哪个验证者(验证者ID)赋予证明许可。
数据删除请求部145能够对MPC参加方组10的MPC参加方9请求删除保存的份额。
另外，虽然图14中没有明确示出，但数据主体终端12也可以进一步具有进行数据主体的登记(数据主体的姓名和住址)、获取唯一识别各验证者的数据主体ID用的数据主体登记部。此时，也可以提供对数据主体ID的信息的签名(例如：能够确认公共机构进行的认证的信息)。
图15是表示数据生成者终端24的功能结构例的框图。数据生成者终端24具有验证逻辑获取部156、数据观测部154、数字签名部158、数据提供部160、份额提供部161和数据生成者DB14。
验证逻辑获取部156从管理服务器22读取验证逻辑，例如使显示器显示。由此，数据生成者8能够确认、理解必要的数据及其形式。
数据观测部154生成关于要证明的事项的数据。数据生成者6是医师、医院的例子中，生成的数据是诊察结果和受检体的分析结果等。数据观测部154将所生成的数据(例如所生成的数据中的见证(秘密信息))登记至数据生成者DB14。另外，生成数据中的事例(公开信息)也可以保存在数据生成者DB14中。数据观测部154还可以一并登记数据主体ID、各数据的数据类ID。
数字签名部158通过对由数据观测部154生成的数据(见证)实施数字签名(例如用数据生成者的私有密钥签名)而生成带有签名的见证，并登记至数据生成者DB14。另外，数字签名部158也可以生成对事例的签名，并登记至数据生成者DB14。
份额提供部161通过使由数字签名部158生成的带有签名的见证份额化而生成签名和数据的份额，进而对各份额也实施签名。份额提供部161能够对MPC参加方9提供所生成的带有签名的份额。另外，份额提供部161在从数据主体终端12对MPC参加方9提供份额的情况下也可以无效化。另一方面，如图19所示，在从数据生成者终端24和数据生成者DB14对MPC参加方9提供份额的结构中有效化。
数据提供部160与来自数据主体终端12的请求相应地，对数据主体终端12提供数据主体4的数据和对应的带有签名的份额。数据提供部160在由数据主体4事先同意的情况下，能够对他人、其他组织提供生成的数据。
对由以上结构构成的MPC-ZKP系统2的动作进行说明。
图18是表示MPC-ZKP系统2中的证明的序列的流程的图。图18说明采用zk-SNARKs作为ZKP的算法的情况。图18的序列对应于上述用MPC执行的零知识证明模式和由用户终端执行的零知识证明模式。图18的序列包括步骤S802、S804、S806、S808、S810、S812，其中步骤S802、S804表示服务提供者7或验证者8进行的验证逻辑的定义的流程，步骤S806、S808、S810、S812表示ZKP的流程，步骤S808、S810表示MPC的流程。另外，步骤S808、S810在用MPC执行的零知识证明模式的情况下执行，在由用户终端执行的零知识证明模式下不执行。
本序列中，首先规定要证明(要验证)的内容(步骤S802)，生成其验证逻辑表达式(步骤S804)。验证逻辑可以由验证者8准备，或者作为“常被验证的内容”，由服务提供者7事先准备。验证逻辑表达式中包括计算式(处理内容)和输入数据的形式(json、yaml、toml等)。另外，对于验证逻辑表达式，关联ZKP方案。验证逻辑中，存在命题函数用的和ZKP用的。本序列中设想为ZKP用的，关于命题函数用的在后文中叙述。接受了验证逻辑表达式的管理服务器22发放验证逻辑ID。
验证者8的验证者终端16或MPC参加方9计算验证逻辑的证明所需的验证逻辑表达式和(使用Trusted Setup的情况下的)CRS(步骤S806)。CRS的计算可以用MPC参加方9进行的通常的计算进行(可以不实施使用份额化的值的MPC)。但是，采用的ZKP方案请求TrustedSetup的情况下，MPC参加方9(和验证者8)协作地进行Setup阶段。
但是，采用zk-STARKs等依赖于散列函数的安全性(随机预言机假设)的方案的情况下，不需要Trusted Setup。
在步骤S808中，获取证明所需的数据。
＜用MPC计算ZKP的情况、且以对第三者提供数据为前提的情况＞
验证所需的带有签名的份额尚未登记的情况下，MPC参加方9通过数据主体4或服务提供者7的委托，对数据生成者6的数据生成者终端24请求带有签名的份额。或者，也可以从数据生成者6的数据生成者终端24自动地进行以下数据提供。
数据生成者6的数据生成者终端24从服务提供者7的管理服务器22获取验证逻辑表达式，按照输入数据的格式，准备请求的数据的带有签名的份额、即明文的秘密共享(份额化)得到的值、对明文的签名的秘密共享(份额化)得到的值、和对各份额签名的值。数据生成者终端24将各个带有签名的份额逐一发布至MPC参加者9的MPC参加服务器20。
MPC参加方9获取数据生成者6的公开密钥，验证各自接受的签名的份额和带有签名的份额的完整性。
＜用MPC计算ZKP的情况、且不以对第三者提供数据为前提的情况＞
验证所需的数据尚未登记的情况下，数据主体终端12从服务提供者7的管理服务器22获取验证逻辑表达式，按照输入数据的格式，对数据生成者终端24请求证明所需的数据的明文和对明文的签名。
数据生成者终端24准备请求的数据的明文和对明文的签名。数据生成者终端24将它们提供至数据主体终端12。
数据主体终端12使用数据生成者6的公开密钥，验证基于数字签名的完整性。
数据主体终端12使从数据生成者终端24获取的明文和对明文的签名的数据秘密共享(份额化)，生成带有签名的份额(例如带有签名的见证的份额)，将各个带有签名的份额逐一发布至MPC参加方9。
MPC参加方9获取数据生成者6的公开密钥，验证各自接受的带有签名的份额(例如带有签名的见证的份额)的完整性。
＜在数据主体4的数据主体终端12中计算ZKP的情况＞
基于与验证逻辑ID关联的输入数据ID，确认在本地的数据主体终端12中登记数据(是否已保存)。尚未登记的情况下，数据主体终端12对数据生成者终端24请求证明所需的数据。数据生成者终端24准备请求的数据的明文和对明文的签名。数据生成者终端24将它们全部提供至数据主体终端12。数据主体终端12使用数据生成者6的公开密钥，确认能够正确地认证签名。数据主体终端12将数据登记在本地的数据主体终端12中。
在步骤S810中，证明者计算ZKP。
＜证明者＝MPC参加方9的情况＞
MPC参加方9基于与目标验证逻辑ID关联的验证逻辑表达式、或者在使用TrustedSetup的情况下基于CRS计算ZKP。另外，计算ZKP可以限定于如上所述验证逻辑表达式满足个别隐私的隐私策略的条件的情况。
对于计算结果的ZKP，以份额化为输出份额的状态，由MPC参加方9保存各输出份额。此时，管理服务器22也可以发放对于获取ZKP的份额即输出份额的认证用的凭证，在发放凭证ID之后关联。该情况下，服务提供者7在得到数据主体的事先、事后的允许之后，对验证者直接通知与该凭证ID关联的信息。或者，也能够实现对数据主体4通知与凭证ID关联的信息，数据主体4能够仅对要证明的对方(验证者8)通知与凭证ID关联的信息，提供与本人的属性关联的证明。
这样，通过使用凭证，与证明ID关联的数据主体4在计算ZKP之后通过凭证信息的登记、删除，能够控制是否允许验证者8访问证据(ZKP)(能够判断允许/不允许，并对系统指示)。MPC参加方9仅对受到数据主体4许可的验证者8在线提供ZKP的输出份额(在线证明)。但是，在搜查相关事项查询等使数据主体得知查询的情况下会产生不便的特例的状况下，应对方式基于服务提供者的判断不限于此。
也可以将计算结果发布至数据主体终端12，数据主体4使验证者8参照(离线证明)。
＜证明者＝数据主体4(的数据主体终端12)的情况＞
由数据主体终端12对MPC参加方9或管理服务器22请求与目标验证逻辑ID关联的验证逻辑表达式、或者使用Trusted Setup的情况下请求CRS。
数据主体终端12基于获取的验证逻辑表达式或CRS计算ZKP。
计算结果保留在数据主体终端12中，按自己的意愿使验证者8参照(离线证明)。或者也可以交由服务提供者7保管，验证者8能够在线地验证(在线证明)。能够实现在线证明的情况下，与证明ID关联的数据主体4通过与凭证ID关联的信息的登记、删除，能够控制是否允许验证者8访问证据(ZKP)(能够判断允许/不允许，并对系统指示)。MPC参加方9仅对受到数据主体4许可的验证者8在线提供ZKP的输出份额(在线证明)。
在步骤S812中，验证者8验证ZKP。
＜ZKP保有者＝MPC参加方9的情况＞
验证者8的验证者终端16从MPC参加方9获取证据(ZKP的输出份额)。另外，提供ZKP的输出份额可以限定于如上所述验证逻辑表达式满足个别隐私的隐私策略的条件的情况、和用凭证允许了验证者8访问输出份额的情况。例如，用凭证进行访问控制的情况下，服务提供者在得到数据主体的事先、事后的允许之后，对验证者直接通知与凭证ID关联的信息。或者，数据主体4预先对验证者8提供与凭证ID关联的信息。验证者8的验证者终端16用与接受通知的凭证ID关联的凭证和验证者ID的认证，获取证据(ZKP的输出份额)、验证逻辑表达式、或者使用Trusted Setup的情况下获取CRS。验证者终端16根据输出份额复原得到ZKP(Proof)，通过对复原得到的ZKP的验证步骤(Verify)，得出验证结果。
＜ZKP保有者＝数据主体4(的数据主体终端12)的情况＞
数据主体4将证据(ZKP的输出份额)和带有签名的验证逻辑表达式、或者在使用Trusted Setup的情况下将带有签名的CRS提供至验证者8。验证者8的验证者终端16验证CRS的真实性。验证者终端16根据输出份额复原得到ZKP(Proof)，通过对复原得到的ZKP的验证步骤(Verify)，得出验证结果。
图20是表示MPC-ZKP系统2中的用命题函数进行的证明(证言)的序列的流程的图。图20的序列对应于上述用MPC执行的命题函数证言模式。图20的序列包括步骤S820、S822、S824、S826，其中步骤S820、S822表示服务提供者7或验证者8进行的验证逻辑的定义的流程，步骤S824、S826表示MPC的流程。
本序列中，首先规定要证明(要验证)的内容(步骤S820)，生成其验证逻辑表达式(步骤S822)。验证逻辑可以由验证者8准备，或者作为“常被验证的内容”，由服务提供者7事先准备。验证逻辑中包括计算式(处理内容)和输入数据的形式(json、yaml、toml等)。验证逻辑中，存在命题函数用的和ZKP用的。本序列中设想为命题函数用的。接受了验证逻辑的管理服务器22发放验证逻辑ID。
在步骤S824中，获取证明所需的数据。
＜用MPC计算的情况、且以对第三者提供数据为前提的情况＞
验证所需的数据尚未登记的情况下数据生成者终端24从服务提供者7的管理服务器22获取验证逻辑，按照输入数据的格式，准备请求的数据的带有签名的份额、即明文的秘密共享(份额化)得到的值、对明文的签名的份额和对各份额的签名(带有签名的份额)。数据生成者终端24将各份额逐一发布至MPC参加方9。
MPC参加方9获取数据生成者6的公开密钥，验证各自接受的签名的份额和带有签名的份额的完整性。
＜用MPC计算的情况、且不以对第三者提供数据为前提的情况＞
验证所需的数据尚未登记的情况下，数据主体终端12从服务提供者7的管理服务器22获取验证逻辑表达式，按照输入数据的格式，对数据生成者终端24请求证明所需的数据的明文和对明文的签名。
数据生成者终端24准备请求的数据的明文和对明文的签名。数据生成者终端24将它们提供至数据主体终端12。
数据主体终端12使用数据生成者6的公开密钥，验证基于数字签名的完整性。
数据主体终端12使从数据生成者终端24获取的明文和对明文的签名的数据秘密共享(份额化)，生成带有签名的份额(例如带有签名的见证的份额)，将各个带有签名的份额逐一发布至MPC参加方9。
MPC参加方9获取数据生成者6的公开密钥，验证各自接受的带有签名的份额(例如带有签名的见证的份额)的完整性。
在步骤S826中，证明者计算命题函数，验证者8验证结果。
MPC参加方9基于与目标验证逻辑ID关联的验证逻辑表达式进行MPC，得出验证结果的份额。另外，计算MPC可以限定于如上所述验证逻辑表达式满足个别隐私的隐私策略的条件的情况。或者，管理服务器22也可以发放获取验证结果的份额的认证用的凭证，在发放凭证ID之后关联。也能够实现管理服务器22对数据主体4通知与该凭证ID相关联的信息，数据主体4在要证明时通过对验证者8通知这些信息，能够对验证者8提供与本人的属性关联的证明。
使用凭证的情况下，服务提供者在得到数据主体的事先、事后的允许之后，对验证者直接通知与凭证ID关联的信息。或者，数据主体4预先对验证者8提供与凭证ID相关联的信息。验证者8使用凭证得出验证结果(True/False)。
用图18和图20所示的流程图，分别说明了MPC-ZKP系统整体中的、用MPC执行的零知识证明模式下的动作、和用MPC执行的命题函数证言模式下的动作。但是，如上所述，用MPC执行的零知识证明模式通过在MPC参加方9中与用MPC执行的命题函数证言模式适当组合地执行，能够抑制用MPC执行的命题函数证言模式的伪证。另外，在MPC参加方9执行命题函数或ZKP的计算时，通过考虑隐私策略，能够适当地控制泄漏的隐私。以下，对于实现这些功能的MPC参加方9中的动作例，参考图25进行说明。另外，MPC参加方9中的动作，是通过处理器执行MPC参加方9的存储器中保存的程序而实现的。
在S2501中，MPC参加方9的处理器从数据主体终端12或数据生成者终端24获取带有签名的见证的份额之后，使用数据生成者终端24的公开密钥，验证获取的带有签名的见证的份额没有被部分篡改。
在S2502中，MPC参加方9的处理器从验证者终端16接受证言请求和证据请求中的任一者即验证请求。此时，识别与验证请求相关的数据主体ID对应值和验证逻辑ID。然后，在S2503中，基于该验证逻辑ID，(从管理服务器22)获取验证逻辑表达式。
在S2504中，MPC参加方9的处理器判断执行验证逻辑表达式是否在隐私策略的保护范围内。具体而言，获取上述验证历史DB和个别策略DB的数据中的、与验证请求相关的数据主体ID对应值关联的比较结果和数据类的保护范围的信息，判断是否因本次执行验证逻辑表达式而使数据缩小至作为隐私策略设定的数据类的保护范围以内。在S2505中，处理器判断为验证逻辑表达式在保护范围内的情况下，前进至S2506，并非如此的情况下结束本处理。
在S2506中，MPC参加方9的处理器判断请求的验证请求是否证据请求(即ZKP的执行请求)。例如，处理器与从验证者终端16接受到的验证请求是证据请求还是证言请求相应地进行本步骤的判断。处理器在验证请求是证据请求的情况下在S2508中执行ZKP，在验证请求是证言请求的情况下在S2507中执行命题函数。
在S2509中，MPC参加方9的处理器对验证者终端16提供作为命题函数或ZKP的处理结果得到的输出份额。在验证者终端16中，对从各MPC参加方9发送的输出份额进行Reconstruct而复原为结果。MPC参加方9的处理器对验证者终端16提供输出份额后，结束一系列动作。
上述实施方式中，保存部的例子是硬盘或半导体存储器。另外，基于本说明书的记载，能够用未图示的CPU、安装的应用程序的模块、系统程序的模块、和暂时性地存储从硬盘读取的数据的内容的半导体存储器等实现各部，接触本说明书的本领域技术人员应当理解这一点。
根据本实施方式的MPC-ZKP系统2，通过组合使用MPC和ZKP，能够实现附带隐私保护的委托属性证明器。特别是数据主体本人不在的情况下，也能够不公开原始数据地执行基于数据主体的原始数据(隐私信息)的证明。
在用户自身的终端中计算得到的证明有时缺乏说服力。这样的情况下，根据本实施方式的MPC-ZKP系统2，MPC-ZKP系统2在用数据生成者(例如医院、政府等)的公开密钥验证数据的真实性的基础上进行证明，所以相当于第三者作出的证言，所以说服力提高。
本实施方式的MPC-ZKP系统2中，数据生成者6生成数据，对其附加数字签名。存在有多名数据生成者6的情况。例如，考虑(1)进行PCR检查的医院和(2)位置信息服务的服务提供者都是数据生成者6的情况。对检查结果和位置信息(是否曾接近集群感染发生场所？)双方用ZKP进行验证，国境、县境等的管理局根据都是False(阴性，且未曾接近集群感染场所)承认“此人可以入境”。MPC-ZKP系统2中，对于不同性质的信息(检查结果、位置信息)，生成各信息(数据)的数据生成者6自身个别地进行签名，由此能够提高MPC-ZKP系统2进行的证明的可靠性。
如上所述，证言方法可以有2种。
1.仅提供用MPC执行的命题函数的结果(不作出ZKP)
对于返回真假值的函数(命题函数)的执行请求，返回True或False。仅能够执行从数据主体接受了执行许可的函数。该情况下，因为不生成正确经过了计算过程的证据，所以作为依据较薄弱。担心用MPC执行ZKP的计算成本的大小、和通信带宽、记录区域不足的情况下，适合通过用MPC执行的命题函数仅对True/False进行预备性地审查。通过在结果可疑的情况下或突发地(随机地)请求ZKP，对于证明者(服务提供者、MPC计算者)而言，鉴于命题函数与ZKP的结论中产生矛盾的可能性，难以随便伪造与对命题函数的请求对应的结论。
2.提供用MPC计算得到的ZKP
因为证明内容中包括直到导出结论的计算过程的妥当性，所以作为依据是强有力的。这成为对1.中举出的命题函数的证言中发生伪造的抑制力。另外，能够对ZKP的证明内容附加对署名的认证是否成功等各种条件。
以上对于实施方式的MPC-ZKP系统2的结构和动作进行了说明。该实施方式是示例，能够用各构成要素和各处理的组合实现各种变形例，并且这样的变形例也在本发明的范围内，本行业从业者应当理解这一点。
实施方式中，对于数据主体4与数据生成者6不同的情况进行了说明，但不限于此。例如，数据生成者终端24的功能也可以用在数据主体终端12的TEE(Trusted ExecutionEnvironment：可信执行环境)中运行的应用实现。
用在数据主体终端12的本地中运行的应用实现数据生成者终端24的功能的情况下，在通常的应用中，数据主体4能够简单地篡改数据。因此，此处使用在TEE中运行的应用。
通常的应用存在由OS(Operating System：操作系统)访问程序和数据的可能性。该情况下，存在程序和数据容易发生篡改的可能性。另一方面，在TEE中运行的应用非常难以篡改程序和数据。困难的依据在于TEE是在与OS在硬件上隔离的环境，在此处运行的应用中，难以发生程序和数据的篡改。即，代码和数据的完整性受到保护。既然数据主体终端12是本地终端，则虽然防御并非完全，但只要旁路攻击没有成功就是安全的。
在该TEE中运行的应用，获取能够由TEE操作的外部设备(周边设备)、即用无线接口连接的传感器(GPS接收机、体温计等)的信息，对其进行整理、分析、解释。
TEE中的应用使该获取、计算结果份额化，并进行签名，对MPC参加方9发布。在即将发布份额前，也可以由应用对用户附带隐私策略地，进行“可否发布？”的确认。这样，能够将“数据生成者6”置换为“数据主体终端12中的应用”。
附图标记说明
2MPC-ZKP系统，4数据主体，6数据生成者，8验证者，10MPC参加方组，12数据主体终端，14数据生成者DB。

Claims (7)

1.一种安装有用基于秘密共享的多方计算来执行零知识证明用的协议的、参加多方计算的多个装置中的一个装置，其特征在于，包括：
获取单元，其获取关于要证明的事项的数据的份额；和
输出单元，其输出将获取到的份额作为输入而按照协议进行了计算的结果所得到的输出份额，
基于从参加多方计算的多个装置收集到的输出份额，能够进行零知识证明中的验证。
2.如权利要求1所述的装置，其特征在于：
还包括使用获取到的份额所附带的数字签名来验证该份额的原本的数据没有被篡改的单元。
3.如权利要求1或2所述的装置，其特征在于：
零知识证明是使用验证逻辑表达式，或公共参考字符串，即Common ReferenceString，简称为CRS，的种类的零知识证明。
4.如权利要求3所述的装置，其特征在于：
进行Trusted Setup的情况下的CRS是参加多方计算的多个装置或者验证者的终端进行协作来生成的，
其中Trusted Setup是可信设置。
5.如权利要求1～4中任一项所述的装置，其特征在于：
所述零知识证明中的验证，是根据验证者的随机或任意的请求来执行的。
6.如权利要求5所述的装置，其特征在于：
所述零知识证明中的验证，是在根据从参加多方计算的多个装置收集到的输出份额进行了基于命题函数的计算的验证之后执行的。
7.一种进行零知识证明的系统，其特征在于，包括：
保存隐私策略的策略保存单元；
保存验证的历史的历史保存单元；
从验证者获取验证请求的单元；和
基于获取到的验证请求的内容、所述策略保存单元所保存的隐私策略和所述历史保存单元所保存的验证的历史，来判断是否拒绝验证请求的单元。
CN202111030539.8A 2021-04-02 2021-09-03 用于用多方计算执行的零知识证明的装置和系统 Pending CN115174087A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-063738 2021-04-02
JP2021063738A JP2022158677A (ja) 2021-04-02 2021-04-02 マルチパーティ計算で行われるゼロ知識証明のための装置およびシステム

Publications (1)

Publication Number Publication Date
CN115174087A true CN115174087A (zh) 2022-10-11

Family

ID=77666210

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111030539.8A Pending CN115174087A (zh) 2021-04-02 2021-09-03 用于用多方计算执行的零知识证明的装置和系统

Country Status (6)

Country Link
US (1) US12010235B2 (zh)
EP (1) EP4068678A1 (zh)
JP (1) JP2022158677A (zh)
CN (1) CN115174087A (zh)
AU (2) AU2021229174A1 (zh)
IL (1) IL286318A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115694812A (zh) * 2022-12-28 2023-02-03 苏州浪潮智能科技有限公司 一种基于零知识的门限身份认证方法、装置及云计算系统
CN117729040A (zh) * 2023-12-22 2024-03-19 中国人民解放军国防科技大学 一种可验证的天际线安全查询方法及系统

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115499247B (zh) * 2022-11-16 2023-03-28 哈尔滨工业大学(深圳)(哈尔滨工业大学深圳科技创新研究院) 基于零知识证明的属性凭证的验证方法及装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG11202005567QA (en) 2017-12-13 2020-07-29 Nchain Holdings Ltd System and method for securely sharing cryptographic material
CN112929181B (zh) * 2018-05-08 2024-01-02 维萨国际服务协会 抗Sybil攻击身份的生成
US11444779B2 (en) 2018-08-02 2022-09-13 Paypal, Inc. Techniques for securing application programming interface requests using multi-party digital signatures
US11218316B2 (en) 2018-12-05 2022-01-04 Ares Technologies, Inc. Secure computing hardware apparatus
US11316691B2 (en) * 2019-04-15 2022-04-26 Eygs Llp Methods and systems for enhancing network privacy of multiple party documents on distributed ledger-based networks
WO2021041771A1 (en) 2019-08-30 2021-03-04 Cornell University Decentralized techniques for verification of data in transport layer security and other contexts

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115694812A (zh) * 2022-12-28 2023-02-03 苏州浪潮智能科技有限公司 一种基于零知识的门限身份认证方法、装置及云计算系统
CN117729040A (zh) * 2023-12-22 2024-03-19 中国人民解放军国防科技大学 一种可验证的天际线安全查询方法及系统
CN117729040B (zh) * 2023-12-22 2024-06-21 中国人民解放军国防科技大学 一种可验证的天际线安全查询方法及系统

Also Published As

Publication number Publication date
US12010235B2 (en) 2024-06-11
AU2021229174A1 (en) 2022-10-20
IL286318A (en) 2022-11-01
JP2022158677A (ja) 2022-10-17
EP4068678A1 (en) 2022-10-05
AU2023226639A1 (en) 2023-09-21
US20220329432A1 (en) 2022-10-13

Similar Documents

Publication Publication Date Title
US10887098B2 (en) System for digital identity authentication and methods of use
US11025419B2 (en) System for digital identity authentication and methods of use
JP7253085B2 (ja) 電子投票システム、装置、制御方法、及び、プログラム
US20220209938A1 (en) One-time-pad encryption system and methods
US20210226800A1 (en) Preserving privacy of linked cross-network transactions
US11362826B2 (en) Endorsement process for non-deterministic application
CN115174087A (zh) 用于用多方计算执行的零知识证明的装置和系统
US11949794B2 (en) Data anonymization of blockchain-based processing pipeline
US20210314139A1 (en) Noisy transaction for protection of data
CN112291062B (zh) 一种基于区块链的投票方法及装置
US20220276996A1 (en) Assessment node and token assessment container
US20220329436A1 (en) Token-based identity validation via blockchain
US20220278845A1 (en) Honest behavior enforcement via blockchain
US20230092436A1 (en) Framework for demaraction of digital assets
CN117280346A (zh) 用于生成、提供和转发基于与用户相关的电子文件的可信电子数据集或证书的方法和装置
Pali et al. A comprehensive survey of aadhar and security issues
EP3883204A1 (en) System and method for secure generation, exchange and management of a user identity data using a blockchain
US20230245112A1 (en) Non-interactive token certification and verification
US20230208640A1 (en) Selective audit process for privacy-preserving blockchain
US20220301376A1 (en) Method and System for Deployment of Authentication Seal in Secure Digital Voting
US11481222B2 (en) Computation and prediction of linked access
Hicks Design and Usage of Transparency Enhancing Technologies
Gerbaud Voter Registration: A Security and Cryptography Perspective
Li A Verifiable I/O Approach for End-to-end Eligibility Verifiability in Black-box E-Voting Systems
Edwards End-to-End Verifiable Internet Voting Blockchain

Legal Events

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