JP2022158677A

JP2022158677A - マルチパーティ計算で行われるゼロ知識証明のための装置およびシステム

Info

Publication number: JP2022158677A
Application number: JP2021063738A
Authority: JP
Inventors: 将司川口; Shoji Kawaguchi
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2021-04-02
Filing date: 2021-04-02
Publication date: 2022-10-17
Also published as: AU2023226639A1; CN115174087A; IL286318A; AU2021229174A1; EP4068678A1; US20220329432A1

Abstract

【課題】よりユーザ利便性の高い証明サービスを実現するか、または、プライバシー情報の漏洩リスクを小さくすることができる技術を実現する。【解決手段】装置は、秘密分散ベースのマルチパーティ計算でゼロ知識証明を行うためのプロトコルが実装された、マルチパーティ計算に参加する複数の装置のうちのひとつの装置であって、証明したい事項に係るデータのシェアを取得する取得手段と、取得されたシェアを入力としてプロトコルにしたがい計算を行った結果得られた出力シェアを出力する出力手段と、を備える。マルチパーティ計算に参加する複数の装置から集められた出力シェアにより、ゼロ知識証明における検証が可能である。【選択図】図１

Description

本発明は、マルチパーティ計算で行われるゼロ知識証明のための装置およびシステムに関する。

近年、ゼロ知識証明に係る技術が知られている。ゼロ知識証明（Ｚｅｒｏ－ＫｎｏｗｌｅｄｇｅＰｒｏｏｆ、ＺＫＰ）は、自分が持っている知識（秘密）を相手に開示することなく、自分が知識（秘密）を知っていること、あるいはその知識（秘密）がある性質を備えること、条件を満たすことを相手に証明するための技術である。ただし、ＺＫＰは以下３つの性質を備えていなければならない：完全性（Ｃｏｍｐｅｌｅｔｅｎｅｓｓ、証明者が証明を試みる命題が真であれば検証者を必ず説得できる性質）、健全性（Ｓｏｕｎｄｎｅｓｓ、証明者が証明を試みる命題が偽である場合は高い確率で説得が失敗に終わる性質）、ゼロ知識性（Ｚｅｒｏ－Ｋｎｏｗｌｅｄｇｅ、証明者がある命題を証明した結果から検証者が得られる知識は、その命題が真であること以外に皆無である性質。つまり検証者が知識を持たなくても、証明の妥当性をシミュレーションすることが可能である性質）。ＺＫＰに関する用語、各手法の特徴に関する標準化が推進されており、当文書も原則これに従う（非特許文献１参照）。

一方、マルチパーティ計算（Ｍｕｌｔｉ－ＰａｒｔｙＣｏｍｐｕｔａｔｉｏｎ、ＭＰＣ）は、入力値を秘匿したまま計算結果を導くことのできる暗号技術である。特にｋ－ｏｕｔ－ｏｆ－ｎ閾値型秘密分散法（ｎ≧ｋ≧２）により、秘密にあたる入力値を複数のシェアに秘密分散させたまま、各シェアを預かるパーティが所定の手続き（プロトコル）をこなし、計算結果を導く計算手法を、秘密分散ベースのマルチパーティ計算と呼ぶ。この計算手法はＦｕｎｃｔｉｏｎａｌＣｏｍｐｌｅｔｅｎｅｓｓを備えることができ、２パーティ計算による各種プロトコルの実装例は非特許文献２に記載される。
社会基盤のデジタル化が叫ばれ、プライバシー保護が喫緊の課題となる昨今、ＺＫＰとＭＰＣは有効な対策手段として注目を集めている。

ZKProof Community Reference, Version 0.2, ２０１９年１２月３１日、URL: https://docs.zkproof.org/pages/reference/reference.pdf Sander Siim, A Comprehensive Protocol Suite for Secure Two-Party Computation, 2016, URL:https://cyber.ee/research/theses/sander_siim_msc.pdf

個人または組織に、外部の検証者に対する証明が要求されるケースは多数ある。現代の証明行為の多くは、第三者機関が発行した証明書、あるいは当人（当組織）が備える情報を、検証者に公開することで果たされる。

しかし証明行為の過程で、検証者に与える情報には、量と質ともに不必要なものが含まれることが多々ある。たとえば酒類を購入する際に「当人が成人であること」を証明する手段は、証明者である当人の免許証を提示することで、検証者である酒類の売り手へ生年月日を通知することにより、果たされるかもしれない。この例では「当人が成年であること」の事実のほか、量（実年齢）と質（住所など）ともに余計な情報が含まれる。
すなわち、上述した不必要なプライバシー情報（証明を要求される命題の結論以上の情報）の漏洩を制限し、また利便性を損なうこともなく、検証者に対する十分な説得力を備えた証明手段が望まれつつある。

上述の問題は、既知のゼロ知識証明により条件付きで解消可能である。ただし、ゼロ知識証明でＰｒｏｖｅを計算する者は、プライバシー情報（平文の知識）を取り扱い、計算することが求められる。そのため証明行為を他者へ委託する場合、プライバシー情報を委託先へ明かすことが求められる。典型例として、２人のプライバシー情報に基づく証明を行う場合、２人のうちいずれか、あるいは第三者に証明行為を委託することとなり、少なくとも２人のうちいずれかのプライバシー情報が、本人以外の誰かに知られることが前提となる。不必要なプライバシー情報を漏らしたくない者が、そのプライバシー情報に基づいた証明を要求された際に問題となる。

本発明は上述した課題を鑑みてなされたものである。その目的は、よりユーザ利便性の高い証明サービスを実現するか、または、プライバシー情報の漏洩リスクを小さくすることができる技術を実現することである。

本発明のある態様は、装置に関する。この装置は、秘密分散ベースのマルチパーティ計算で命題関数とゼロ知識証明とを行うためのプロトコルが実装された、マルチパーティ計算に参加する複数の装置のうちのひとつの装置であって、証明したい事項に係るデータのシェアを取得する取得手段と、取得されたシェアを入力としてプロトコルにしたがい計算を行った結果得られた出力シェアを出力する出力手段と、を備える。マルチパーティ計算に参加する複数の装置から集められた出力シェアにより、命題関数における検証、またはゼロ知識証明における検証が可能である。
本発明の別の態様は、システムである。このシステムは、ゼロ知識証明を行うシステムであって、プライバシーポリシーを保持するポリシー保持手段と、検証の履歴を保持する履歴保持手段と、検証者から検証要求を取得する手段と、取得された検証要求の内容と、前記ポリシー保持手段に保持されるプライバシーポリシーと、前記履歴保持手段に保持される検証の履歴と、に基づいて、検証要求を拒否するか否かを判定する手段と、を備える。

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

本発明によれば、よりユーザ利便性の高い証明サービスを実現するか、または、プライバシー情報の漏洩リスクを小さくすることができる。

実施の形態に係るＭＰＣ－ＺＫＰシステムの構成を示す模式図である。図１のＭＰＣ－ＺＫＰシステムを利用するメリットである秘匿性を説明するための模式図である。図１のＭＰＣ－ＺＫＰシステムを利用するメリットであるロジックの透明性を説明するための模式図である。ＭＰＣ－ＺＫＰシステムで実装される証明モードの特徴を表形式で示す図である。図１のＭＰＣ参加パーティのＭＰＣ参加パーティ（ＭＰＣ参加サーバともいう）のハードウエア構成図である。図１のＭＰＣ参加パーティのＭＰＣ参加パーティの機能構成例を示すブロック図である。図１のＭＰＣ参加パーティ群を管理するためにサービス提供者が運用する管理サーバの機能構成例を示すブロック図である。図７の検証ロジック式ＤＢの一例を示すデータ構造図である。図７のデータ主体ＤＢの一例を示すデータ構造図である。図７のデータクラスＤＢの一例を示すデータ構造図である。図７の検証者ＤＢの一例を示すデータ構造図である。図７の個別ポリシーＤＢの一例を示すデータ構造図である。図７の検証履歴ＤＢの一例を示すデータ構造図である。図１のデータ主体端末の機能構成例を示すブロック図である。データ生成者の端末であるデータ生成者端末の機能構成例を示すブロック図である。図１の検証者端末の機能構成例を示すブロック図である。検証者端末１６の検証ロジック式ＤＢの一例を示すデータ構造図である。ＭＰＣ－ＺＫＰシステムにおける証明のシーケンスの流れを示すチャートである。データ生成者が第三者提供について合意取得済みの場合のＭＰＣ－ＺＫＰシステムの構成を示す模式図である。ＭＰＣ－ＺＫＰシステムにおける命題関数による証明（証言）のシーケンスの流れを示すチャートである。データ主体のデータ主体端末のディスプレイに表示される出力プライバシー漏洩通知画面の代表画面図である。ＭＰＣ参加パーティ９における入力値ＤＢの一例を示すデータ構造図である。ＭＰＣ参加パーティ９における追加情報ＤＢの一例を示すデータ構造図である。ＭＰＣ参加パーティ９のシェア保持部におけるシェアＤＢの一例を示すデータ構造図である。ＭＰＣ参加パーティ９における一連の動作を示すフローチャートである。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴のうち二つ以上の特徴が任意に組み合わされてもよい。また、同一若しくは同様の構成には同一の参照番号を付し、重複した説明は省略する。

（実施の形態）
実施の形態は、秘密計算のひとつである秘密分散ベースのマルチパーティ計算と、ＺＫＰと、を組み合わせて用いることで、プライバシー保護を伴う委託属性証明器を実現するＭＰＣ－ＺＫＰシステムに関する。

本実施の形態に係るＭＰＣ－ＺＫＰシステムではＭＰＣとＺＫＰとを組み合わせて用いることにより、データ主体の手を離れたデータについて、そのデータの保管、そのデータに基づく計算、計算の結果出力、結果出力の検証まで一貫して、証明を求められている命題についての結論以外について余計なプライバシーを晒す行為を排除できる。言い換えると、ＭＰＣとＺＫＰにより入力プライバシーを保護し、クエリ監査法により出力プライバシーの漏洩を限定的にすることが可能になる。

本実施の形態に係るＭＰＣ－ＺＫＰシステムの主な特徴（但しこれらに限定されない）は以下のとおりである。
１．証明時のプライバシー保護
本実施の形態に係るＭＰＣ－ＺＫＰシステムでは、証明の委託先あるいは検証者に対して、プライバシーが含まれたデータを理解可能な状態で引き渡す必要がなくなる。ＭＰＣ－ＺＫＰシステムでは、以下２つの仕組みによりプライバシーが保護される。それぞれの詳細は後述する。
●入力プライバシー保護機能（秘密計算、ＺＫＰ）
●出力プライバシー保護機能（クエリ監査法）
２．検証のロジックの透明性
本実施の形態に係るＭＰＣ－ＺＫＰシステムでは、検証の結論を示すと同時に、検証のロジックを一意にし、透明性を持たせることが可能になる。またデータをデジタル署名とメッセージのペアで管理し、これらをＷｉｔｎｅｓｓとしたうえで、ＺＫＰの検証ロジック（Ｒｅｌａｔｉｏｎ）に『メッセージの完全性が署名と公開鍵により検証可能であること』を含めることで、データの出処（データ生成者）を明らかにできる。
３．検証の共通化
本実施の形態に係るＭＰＣ－ＺＫＰシステムでは、主旨を同じくする検証を共通化し、検証に必要なデータ（ＷｉｔｎｅｓｓとＩｎｓｔａｎｃｅ）をクラス分類しておくことで、ワンスオンリー化を促進したり、同じデータ（ＷｉｔｎｅｓｓとＩｎｓｔａｎｃｅ）に関する複数の検証を実施可能にしたり、することができる。なお、ウィットネス（Ｗｉｔｎｅｓｓ）は、検証に用いられる非公開情報であるのに対し、インスタンス（Ｉｎｓｔａｎｃｅ）は、検証に用いられる公開情報である。
４．オフライン証明
後述するようにＺＫＰのスキーム次第では、一度の証明の計算結果により、当初の検証者だけではなく、以降複数の検証者を説得することもできる（Ｔｒａｎｓｆｅｒａｂｌｅである）。この性質を利用して、証明結果を持ち運び可能な端末上のみに保存し（証明の委託先から削除し）、端末の所有者（利用者）から検証者へ対面、あるいは専用線越しでの証明を可能にする。
５．証明の委託、代理証明
本実施の形態に係るＭＰＣ－ＺＫＰシステムでは、データを秘密に保ちたい当人（データ主体）が何かしらの理由により証明行為を不可能としていても、証明方法（例：ＺＫＰの計算方法）を知らなくても、データを用意し、データをシェア化して、証明の委託先（ＭＰＣ－ＺＫＰシステムの提供者）へ秘密分散させて提供するだけで、検証者が求める検証を実施することが可能となる。代理で証明できることのメリットは、たとえば本人不在（あるいは死亡、行方不明）、端末の紛失等による一時的な権限の喪失、情報技術のリテラシ不足、当局からの問い合わせを受けた状況等において認められる。こうして証明を代行してもらいながらも、前述の通りプライバシー保護が果たされる。
６．単純な証言（命題関数）の説得力の強化
ある命題について、証明の委託先がＭＰＣによる命題関数を計算し、根拠となるデータのプライバシーを守りつつ、検証結果（証言）を出力することができたとしても、単純に証言を立てるだけでは、検証者が説得されるとは限らない。なぜなら委託先（ＭＰＣによる命題関数を行った者）と、委託元（データ主体など）が結託して、検証者を騙そうとしたり、データ主体が検証者に嘘の証拠を提出していたり、証明者の能力不足（証明計算の誤り、バグ）により間違った検証結果が導かれたり、といった可能性が否めないからである。言い換えると、素朴な代理証明においては、命題関数の出力のみの提出には、説得力が欠ける。たとえばＭＰＣによる命題関数の実行結果を提供することが、このような単純な証言に該当する。
本実施の形態に係るＭＰＣ－ＺＫＰシステムでは、検証者の任意に、または無作為に、先に実行した命題関数とまったく同じ命題に関するＺＫＰのＰｒｏｏｆ（証拠）を出力する機能を提供する。つまり上述した単純な証言に対して、結論の正しさや、採用された検証ロジックの手続きの妥当性を抜き打ちチェックできる機能を設ける。この効果は、証明の委託先が、不正な証言をしづらくする牽制として働く。
上述した仕組みにより、証明の委託先には、偽証しないことへの強いインセンティブが生まれる。偽証したことが知られた場合、著しく信用を損ねるためである。つまりゲーム理論的な見地から、偽証しづらい仕組みを敢えて証明システムに組み込むことで、単純な証言（命題関数の結果）に強い説得力を与えることができる。結果的に、計算コストの高いＺＫＰの計算を行う機会を減らしながらも、単純な証言、すなわちＭＰＣによる命題関数の出力結果の説得力は、ＺＫＰに準ずるものを得ることができる。この応用として、秘密ｘに基づく任意の計算プログラムｆ（ｘ）をＭＰＣした出力結果をｙとしたとき、「ｆ（ｘ）の結果はｙである」という命題の証明が可能になるため、誤ったｆ（ｘ）の計算結果を出力しないことへの強いインセンティブを与えることもできる。
７．ＩｎｔｅｒａｃｔｉｖｅＺＫにおける証明者と検証者の組合せ爆発の解消
ＩｎｔｅｒａｃｔｉｖｅＺＫを計算する場合、証明開始から証明完了まで、証明者と検証者は対話できなければならない（互いにオンラインでなければならない）。特にデータ主体が自身の端末により証明を行う場合、「検証者：証明者」の組み合わせは「多：多」の関係となり、いわゆる組合せ爆発を起こしてしまう。本実施の形態に係るＭＰＣ－ＺＫＰシステムでは、プライバシーを保護しながらも、複数のデータ主体の証明者の役割をＭＰＣ参加パーティに委託し、一本化できる。結果として「検証者：証明者」の組み合わせは「多：１」の関係に変換される。
８．２人以上のデータ主体のＷｉｔｎｅｓｓを用いた証明
平文のＷｉｔｎｅｓｓを用いる従来のＺＫＰでは、複数のデータ主体の秘密（Ｗｉｔｎｅｓｓ）に基づく証明を行いたいとき、以下いずれかの方策を採る必要があった。
(1) 各データ主体のＷｉｔｎｅｓｓを信頼できる第三者の環境に集め、そこでＺＫＰを計算してもらう。この場合、信頼できる第三者の環境（ＴＴＰ、ＴｒｕｓｔｅｄＴｈｉｒｄＰａｒｔｙ）からのプライバシー保護はあきらめる必要がある。
(2) 個々のデータ主体が自身のＷｉｔｎｅｓｓのみに基づく証明を計算する。ただしこの場合は２者の情報を合わせた（例：合計）情報に基づく証明が困難になり、またＰｒｏｏｆ（証拠）がデータ主体の数だけ増えてしまい、各データ主体の出力プライバシーが漏れてしまう恐れがある。
一方、ＭＰＣ－ＺＫＰシステムでは、個々のデータ主体のＷｉｔｎｅｓｓは、データ主体本人以外のすべてからプライバシー保護（秘密分散）されるため、すべてのデータ主体のＷｉｔｎｅｓｓを保護したまま、複数のデータ主体のＷｉｔｎｅｓｓに基づく証明を計算することが可能となる。

図１は、実施の形態に係るＭＰＣ－ＺＫＰシステム２の構成を示す模式図である。この例では、患者が医師に診察してもらい、その結果を国境・県境等の管理局に知らせる状況を想定している。ＭＰＣ－ＺＫＰシステム２は、患者などのデータ主体４が所有するデータ主体端末１２と、医師や病院などのデータ生成者６が生成したデータおよびそのシェアを格納するデータ生成者データベース（ＤＢ）１４と、ＭＰＣに参加する複数のＭＰＣ参加パーティ９からなるＭＰＣ参加パーティ群１０と、あるＭＰＣ参加パーティ群１０の管理情報を管理する管理サーバ２２と、国境・県境等の管理局などの検証者８が所有する検証者端末１６と、を備える。ＭＰＣ参加パーティ群１０に含まれる各ＭＰＣ参加パーティ（ＭＰＣ参加サーバという場合もある）には、ＭＰＣでＺＫＰを行うためのプロトコルが実装されている。ＭＰＣ－ＺＫＰシステム２の各構成要素（データ主体端末１２、データ生成者ＤＢ１４、ＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティ、検証者端末１６）は、インターネットなどのネットワークを介して互いに通信可能に接続されている。なお、本実施の形態では、データ主体端末１２とデータ生成者ＤＢ１４とが別体として構成される場合を例に説明しているが、データ生成者ＤＢ１４がデータ主体端末１２に含まれてもよい。

ＭＰＣ－ＺＫＰシステムにおけるＺＫＰの提供形態を説明する。一般的に、ＺＫＰの計算過程はＳｅｔｕｐ、Ｐｒｏｖｅ、Ｖｅｒｉｆｙの３つの手続きに分類可能である。本実施の形態では、このうちのＰｒｏｖｅをＭＰＣで実施する。すなわちＷｉｔｎｅｓｓはｋ－ｏｕｔ－ｏｆ－ｎ閾値型秘密分散法（ｎ≧ｋ≧２）により秘密分散され、非公開値とされた上で、Ｗｉｔｎｅｓｓを入力値に取るＰｒｏｖｅの手続きは秘密分散ベースのマルチパーティ計算（ＭＰＣ）により行われる。なおセキュリティパラメータｌに基づく、素数ｑ、生成元ｇ、ｉ ∈ ｛０，１，…，ｎ－１｝、ｎはＭＰＣ参加パーティの数、とし、これらを公開値とする。またＷｉｔｎｅｓｓはｗで表され、ｗがｋ－ｏｕｔ－ｏｆ－ｎ閾値型秘密分散法により秘密分散されたシェアは｛ｗ_０，ｗ_１， … ｗ_ｎ－１｝で表される。ｗ_ｉはＭＰＣ参加パーティＰ_ｉへ配布されているものとする。ｋ－ｏｕｔ－ｏｆ－ｎ閾値型秘密分散法においてはｎのうちｋ以上のＭＰＣ参加パーティが保持するシェアによりＲｅｃｏｎｓｔｒｕｃｔが可能であり、ｎ≧ｋ≧２とする。ＦｕｎｃｔｉｏｎａｌＣｏｍｐｌｅｔｅｎｅｓｓを満たすＭＰＣにより、あらゆるＺＫＰを実現可能である。
ｚｋ－ＳＮＡＲＫｓやＧｒｏｔｈ－ＳａｈａｉはＴｒｕｓｔｅｄＳｅｔｕｐを求める。ＴｒｕｓｔｅｄＳｅｔｕｐは、ある命題に関するゼロ知識証明の準備（Ｓｅｔｕｐ）を、信頼できるパーティに要求する形態のことである。たとえば参加したパーティは乱数を秘匿化し、この値をＣＲＳとして公開する。この乱数が証明者に知られると、偽証が可能になってしまう弱点を持つ（Ｓｏｕｎｄｎｅｓｓが脅かされる）。そのためＴｒｕｓｔｅｄＳｅｔｕｐにあたっては複数のパーティが参加・協力し、準同型性などの性質を用いて、各パーティの乱数を足し合わせたＣＲＳを発行する。これにより参加した全パーティのうち１パーティでも乱数の提供を拒否すれば、偽証を防ぐことが可能になる。特にｚｋ－ＳＮＡＲＫｓのサブクラスであるＬｉｇｅｒｏやＳｏｎｉｃなどの一部の実装では、求められるＴｒｕｓｔを小さくすることが可能である。
本発明において、ＭＰＣ参加パーティは秘密のシェアを保持する立場として信頼されており、複数のパーティ（ｎ≧２）が配置されているため、ＭＰＣ参加パーティの全部または一部が信頼されたパーティの役割を兼ねることができる。
例として、ｚｋ－ＳＮＡＲＫｓの手続き（以下１．～３．）を示す。
１．ＭＰＣ参加パーティ同士によるＴｒｕｓｔｅｄＳｅｔｕｐの計算
ＱＡＰ＜－Ｃｏｍｐｉｌｅ（ｒｅｌａｔｉｏｎ）
ＣＲＳ＜－Ｓｅｔｕｐ（ＱＡＰ）
なおｒｅｌａｔｉｏｎは検証のロジックに対応する検証ロジック式、ＱＡＰはｒｅｌａｔｉｏｎ（検証ロジック式）に対応するＱｕａｄｒａｔｉｃＡｒｉｔｈｍｅｔｉｃＰｒｏｇｒａｍ（あるいはＲ１ＣＳとしても良い）、ＣＲＳはＣｏｍｍｏｎＲｅｆｅｒｅｎｃｅＳｔｒｉｎｇ、ＣＲＳ＝｛ｐｋ，ｖｋ｝、ｐｋはＰｒｏｖｉｎｇＫｅｙ、ｖｋはＶｅｒｉｆｉｃａｔｉｏｎＫｅｙである（以下、ＣＲＳを追加情報と記載することもある）。
２．ＭＰＣによるＰｒｏｖｅ
π_ｉ＜－Ｐｒｏｖｅ（ＣＲＳ，ｘ，ｗ_ｉ）
なおｘはＩｎｓｔａｎｃｅである。
ＭＰＣ参加パーティＰ_ｉはπ_ｉを検証者へ提供する。
３．検証者によるＶｅｒｉｆｙ
π ＜－Ｒｅｃｏｎｓｔｒｕｃｔ（π_０， π_１， …， π_ｎ－１）
｛ａｃｃｅｐｔ，ｒｅｊｅｃｔ｝＜－Ｖｅｒｉｆｙ（ＣＲＳ，ｘ， π）
なおａｃｃｅｐｔは証明の受理、ｒｅｊｅｃｔは証明の拒否である。

データ主体４は本例では患者であり、提供するデータの持ち主、あるいはプライバシー権を持つ本人である。データ主体４は個人に限られず、組織であってもよい。

データ生成者６は、事象を観測して、データ化する役割の者である。データ主体４が最初にデータを預ける第一のデータ管理者でもある。本例ではデータ生成者６は患者を診察したり、検体を入手・解析し、データ化する医師・病院である。また別の例では、データ生成者６は、端末やセンサ等で検知した事象を観測し、データ化を行うサービス運営者である。

サービス提供者７はＭＰＣ－ＺＫＰシステム２を用いたサービスの運営者である。サービス提供者７はＭＰＣ参加パーティ群１０を運用するか、または運用を第三者に委託する。サービス提供者７は、データ生成者６（第一のデータ管理者）からデータ主体４を経てデータのシェアを預かることから第二のデータ管理者と言いうる。後述の第三者提供版ではデータ処理者であるとも言いうる。

ＭＰＣ参加パーティ９は、秘密計算と、証言（命題関数）或いは証拠（ＺＫＰ）を計算（データ処理）するサーバであり、ＭＰＣ参加パーティ群１０を構成する個々のサーバである。ＭＰＣ参加パーティ群１０では、複数のＭＰＣ参加パーティ９を含み、同一組織が管轄するサーバ間でＭＰＣされる場合と、異なる複数の組織が管轄するサーバ間（あるいはノード間）でＭＰＣされる場合がある。

検証者８は、第二のデータ管理者（サービス提供者、ＭＰＣ参加パーティ）が作った証拠・証言（ＺＫＰ、命題関数の出力）を利用する者であり、本例では国境・県境等の管理局である。検証者８は、証明・証言を検証したい者である。サービス提供者７が検証者８となる場合もある。

管理サーバ２２は、ＭＰＣ－ＺＫＰシステム２における秘密計算及びゼロ知識照明のスキームを利用するサービス提供者が管理するサーバであり、ＭＰＣ参加パーティ群１０を管轄する。管理サーバ２２は、検証者８によって生成された検証ロジック式（論理・算術演算回路ともいう場合がある）を登録、保持し、データ主体端末１２やデータ生成者端末２４、ＭＰＣ参加パーティ９からの要求に応じて、検証ロジック式を要求元に提供する。

図１を参照し、ＭＰＣ－ＺＫＰシステム２における検証内容の登録から、検証に用いるデータの生成、証明の計算、検証までの処理の流れを説明する。なおデータ主体４と検証者８は、あらかじめサービス提供者７の管理サーバ２２に利用者登録を済ませ、それぞれデータ主体ＩＤと検証者ＩＤを発行し終えているものとする。
（１）検証者８は検証者端末１６から検証ロジック式をＭＰＣ参加パーティ群１０を管轄とする管理サーバ２２へ登録する。このとき検証ロジック式には管理サーバ２２により検証ロジックＩＤが付与される。
（２）データ主体端末１２は検証者８が求める検証ロジックＩＤを確認し、ＭＰＣ参加パーティ群１０を管轄とする管理サーバ２２から検証ロジックＩＤに紐づく検証ロジック式を読み込む。検証ロジック式から証明に用いられるデータとデータクラス（データの形式と要件）と計算方法（命題関数、ＺＫＰの計算方法）が一意になる。これによりデータ主体４は、事象を観測し必要なデータを生成してくれるデータ生成者６（例えば、医師・病院、公的機関）を特定する。
（３）データ主体４（患者）は（データ主体端末１２を介して）データ生成者６（例えば医師・病院、公的機関）に検証ロジックＩＤを伝える。データ生成者端末２４は検証ロジックに紐づく検証ロジック式を管理サーバ２２から読み込む。検証ロジック式から証明に用いられるデータとデータクラス（データの形式と要件）が一意になる。データ主体４（患者）がデータ生成者６（例えば医師・病院、公的機関）の観測（例えば、診察・検査、本人確認）を受けつけて、評価を行うと、評価結果のデータがデータ生成者端末２４に読み込まれる。
（４）データ生成者端末２４は、読み込んだデータをデータクラスの形式に加工し、データ生成者６の公開鍵暗号方式の秘密鍵ｓｋによりデジタル署名を施す。なお、データ生成者６の公開鍵ｐｋは、例えばＰＫＩ等により入手可能である。生成されたデータをｗとする。データへのデジタル署名をｗｓとする。（ｗ、ｗｓ）の組を署名付きウィットネス（Ｗｉｔｎｅｓｓ）と呼ぶ。データ生成者端末２４は、生成された署名付きウィットネス（ｗ、ｗｓ）をデータ生成者ＤＢ１４に格納する。
（５）データ主体端末１２は、データ生成者ＤＢ１４から署名付きウィットネス（ｗ、ｗｓ）を取得し、読み込む。データ主体端末１２は、受信した署名付きウィットネス（ｗ、ｗｓ）の妥当性を検証するため、ＰＫＩ等から取得したデータ生成者の公開鍵ｐｋにより、デジタル署名による完全性の検証が成功することを確認する。データ主体端末１２は、署名付きウィットネス（ｗ、ｗｓ）をｋ－ｏｕｔ－ｏｆ－ｎ閾値型秘密分散する（ｎ≧ｋ≧２）。ｗを秘密分散したシェアを｛ｗ_０、ｗ_１、…、ｗ_ｎ－１｝とする。同様にｗｓを秘密分散したシェアを｛ｗｓ_０、ｗｓ_１、…、ｗｓ_ｎ－１｝とする。（ｗ_ｉ、ｗｓ_ｉ）の組を署名付きウィットネスのシェアと呼ぶ。なおｉ∈｛０，１，…，ｎ｝、ｎはＭＰＣ参加パーティ群１０のパーティ数である。
（６）データ主体端末１２は、データ主体４が検証ロジックＩＤに紐づく処理内容（＝検証ロジック式、プライバシーポリシー）に合意したことを示す操作を受け付けると、、ＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティＰ_ｉへ、署名付きウィットネスのシェア（ｗ_ｉ、ｗｓ_ｉ）を送信する。
（７）ＭＰＣ参加パーティ群１０は、各ＭＰＣ参加パーティＰ_ｉにおける署名付きウィットネスのシェア（ｗ_ｉ、ｗｓ_ｉ）とＰＫＩ等から取得したデータ生成者６の公開鍵ｐｋにより、検証ロジックＩＤに紐づく検証ロジック式に基づき、ＭＰＣによる証言（命題関数）の計算を行う。各ＭＰＣ参加パーティＰ_ｉは、証言のシェアτ_ｉを得る。
（８）検証者８はデータ主体４からデータ主体ＩＤの通知を受ける。検証者８の検証者端末１６は、ＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティＰ_ｉから認証を受けて、ＭＰＣ参加パーティ群１０から検証ロジックＩＤとデータ主体ＩＤの両方に紐づく証言の出力シェア｛τ_０、τ_１、…、τ_ｉ｝を取得（ＭＰＣ参加パーティＰ_ｉからτ_ｉを取得）し、Ｒｅｃｏｎｓｔｒｕｃｔ（すなわち秘密分散した値を集めて元の値を復元する）して証言τを得る。検証者８は証言τを不服とする場合、その旨を検証者端末１６に入力する。検証者端末１６は、証言に対する不服を表す入力を受け付けると、ＭＰＣ参加パーティ群１０に対し、ゼロ知識証明による証拠（Ｐｒｏｏｆ）を要求する。あるいは検証者８がτを不服としない場合も、検証者端末１６は無作為に、ＭＰＣ参加パーティ群１０に対してゼロ知識証明を要求することができる。
（９）ゼロ知識証明による証拠（Ｐｒｏｏｆ、すなわち上記Ｐｒｏｖｅ手続の出力）の要求を受け付けた場合、ＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティＰ_ｉは、検証ロジックＩＤに紐づく検証ロジック式に基づき、ＭＰＣによるＺＫＰの計算を行う。検証ロジックＩＤに紐づく検証ロジック式に登録されたＺＫＰスキーム（ＺＫＰの種類）が、例えばＮＩＺＫ（ＮｏｎＩｎｔａｒａｃｔｉｖｅＺＫ）である場合、ＭＰＣ参加パーティＰ_ｉは、証明結果である証拠（Ｐｒｏｏｆ）の出力シェア｛π_０、π_１、…、π_ｎ－１｝を得る。一方、検証ロジックＩＤに紐づく検証ロジック式に登録されたＺＫＰスキームが、例えばＩｎｔｅｒａｃｔｉｖｅＺＫである場合、ＭＰＣ参加パーティＰ_ｉは(1)検証者８の検証者端末１６へコミットメントを送付し、(2)検証者８の検証者端末１６はＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティＰ_ｉへチャレンジを送付した後に、(3)ＭＰＣ参加パーティＰ_ｉは、証明結果である証拠（Ｐｒｏｏｆ）の出力シェア｛π_０、π_１、…、π_ｎ－１｝を得る。ここで、(2)と(3)は繰り返されることがある（ＳｏｕｎｄｎｅｓｓＡｍｐｌｉｆｉｃａｔｉｏｎ）。
（１０）検証者８の検証者端末１６は、クレデンシャル等によりＭＰＣ参加パーティ群１０から認証を受けて、ＭＰＣ参加パーティ群１０から検証ロジックＩＤとデータ主体ＩＤの両方に紐づく証拠（Ｐｒｏｏｆ）の出力シェア｛π_０、π_１、…、π_ｎ－１｝を取得（ＭＰＣ参加パーティＰ_ｉからπ_ｉを取得）し、Ｒｅｃｏｎｓｔｒｕｃｔして、証拠（Ｐｒｏｏｆ）であるπを得る。また検証ロジック式に登録されたＺＫＰのスキームに応じ、ＭＰＣ参加パーティ群１０から上述のＶｅｒｉｆｙに必要なＣＲＳ（追加情報）を取得する。Ｖｅｒｉｆｙを計算し、検証者８の検証端末１６は検証した内容を受理（Ａｃｃｅｐｔ）または拒否（Ｒｅｊｅｃｔ）する。

図１のＭＰＣ－ＺＫＰシステム２において、ＭＰＣ参加パーティ群１０が、複数のデータ生成者が生み出した同じ個人に帰属するデータを集めることができれば、同じ個人に関する多角的な証明が可能となる。従来はデータ生成者が発行した書類を集めて検証者に提出し、検証してもらう必要があった。この書類には、本来は検証者が知らなくても良い余計な情報が含まれていることが多々ある。図１のＭＰＣ－ＺＫＰシステム２では、ＭＰＣ参加パーティ群１０が、プライバシーを保護しながら、目的の証明を一括して実施する。
またＭＰＣ参加パーティ群１０が、異なる人物のデータを秘匿したまま集めることで、プライバシーを漏らすことなく、異なる人のデータを組み合わせた証明を可能にできる。従来のＺＫＰで同様のことを実施するためには、平文を同じ計算機へ配置して計算する必要があった。これでは２人のうち少なくとも一方のプライバシーが本人以外の誰かに漏れてしまう。この点についても、図１のＭＰＣ－ＺＫＰシステム２では、ＭＰＣ参加パーティ群１０が、複数の人々のプライバシーを保護しながら、目的の証明を一括して実施する。
なおデータ主体４は古いデータ主体ＩＤと別に、新しいデータ主体ＩＤを発行した上で、後者のデータ主体ＩＤを使って証明を実施する可能性がある。これにより、検証者が過去の検証内容との名寄せを出来ないようコントロール可能になる。

図１のＭＰＣ－ＺＫＰシステム２の適用例として、コロナウイルスが蔓延し、地域間の移動が制限されたときの移動の許否の判断に適用する場合を考える。地域間の移動時、管理局は本人の感染確率が極めて低いことを検証してから、移動を許可したいと考える。「感染確率が極めて低い」の定義はまちまちなので、管理局が以下のような検証ロジック式（署名付きＣＲＳ）を用意する。
検証ロジック式：病院でＰＣＲ検査を受けて陰性、かつ、過去１週間以内にクラスタ発生地域に近づいていないならば、感染確率が極めて低い。

別地域に移動したい人は、事前に以下のようなアクションを取ってもよい。
１．管理局から検証ロジック式を受け取ったサービス提供者またはＭＰＣ参加パーティは、検証ロジック式（例：Ｒａｎｋ１ＣｏｎｓｔｒａｉｎｔＳｙｓｔｅｍ、ＱｕａｄｒａｔｉｃＡｒｉｔｈｍｅｔｉｃＰｒｏｇｒａｍ）と、検証ロジックの演算に必要なデータのＣＲＳ（追加情報）を算出する。
２．データ主体はこの検証ロジック式・ＣＲＳ（追加情報）を端末にダウンロードすると、データ生成者へ必要なデータをリクエスト（例：病院で受診、位置情報サービスを起動）し、受け取る。
３．ダウンロード済みの検証ロジック式とデータにより計算結果（Ｐｒｏｏｆ）を導く。
４．管理局に計算結果を提示することで、証明を実施する。このときデータ主体がサービス提供者またはＭＰＣ参加パーティの署名付きの検証ロジック式とＣＲＳ（追加情報）を取得しておくか、あるいは管理局が事前にサービス提供者またはＭＰＣ参加パーティから検証ロジック式と追加情報（ＣＲＳ）を受け取っておくことで、この証明はオフライン（ローカル、閉域網）でも可能になる。

本実施の形態に係るＭＰＣ－ＺＫＰシステム２は、上記２．のデータをＭＰＣ参加パーティ群１０に秘密分散させたまま登録し、それらのＭＰＣ参加パーティの間でＭＰＣにより計算することで証明を実施する委託証明を可能とするものである。またサービス提供者またはＭＰＣ参加パーティがロジックを仲介することで、証明の基準を共通化し、ＺＫＰに必要な回路設計やＳｅｔｕｐを一本化することで、目的を同じくする証明の乱立を避けることが可能である。

図２は、図１のＭＰＣ－ＺＫＰシステム２を利用するメリットである秘匿性を具体的に説明するための模式図である。ＭＰＣ－ＺＫＰシステム２により秘匿性、すなわち不要な情報開示の排除が実現される。従来では、病院、地図サービス業者などの異なる複数種類のデータ生成者が患者などの評価対象を観測し、それぞれ観測結果を生成する（例えば、診察結果の陰性／陽性を示すｘａ、クラスタ発生地域に近づいていない根拠ｘｂなど）。そしてこれらのデータｘａ、ｘｂを一箇所に集めて判断し、移動の許否を決定する。この従来技術の問題点は、プライバシーの問題、すなわち生データを一箇所に集めなくてはならないことにある。評価対象としては、必要以上の自己の情報を検証者に見せたくないという思いがあり、またこの従来技術ではデータのやりとりは書面によるので、事務手続きが冗長となっている。

これに対して本実施の形態に係るＭＰＣ－ＺＫＰシステム２を利用する場合、例えば、データ生成者側（データ主体が行ってもよい）でデータをシェア化し、生データではなくシェアをＭＰＣ－ＺＫＰシステム２に提供する。例えば、診察結果の陰性／陽性を示すｘａはｘａ１、ｘａ２の二つのシェアに分割され、それぞれ別のサーバ（すなわちＭＰＣ参加パーティ）に送信される。クラスタ発生地域に近づいていない根拠ｘｂも同様にｘｂ１、ｘｂ２の二つのシェアに分割され、それぞれ別のサーバに送信される。ＭＰＣ－ＺＫＰシステム２（のＭＰＣ参加パーティ群１０）はシェア化されたデータ（生データそのものでない）を引き受け、検証結果を（検証者端末１６を介して）検証者８に提供する。このように、ＭＰＣ（シェア化）によりプライバシーを保護したまま、検証が可能となる。

図３は、図１のＭＰＣ－ＺＫＰシステム２を利用するメリットであるロジックの透明性を説明するための模式図である。ＭＰＣ－ＺＫＰシステム２によりロジックの透明性が担保され、ねつ造が排除される。従来では、医者・専門家などの評価者（証人）が患者などの評価対象を観測し、観測結果のデータｘを評価ロジックにしたがって評価し、評価結果である結論ｙを国境・県境等の管理局などの検証者に提供する。結論は、大抵の場合、感染の有無など、Ｙｅｓ／Ｎｏに圧縮されるものである。この従来技術の問題点は以下の２つである。
（１）能力の問題
評価者が結論を出すまでの評価ロジックに妥当性があるかが問題となる。評価者と検証者との観点の違いで「受理（Ａｃｃｅｐｔ）」の基準にバラツキが生じうる。
（２）意図の問題
評価者が証拠を改ざんする可能性があり、また、嘘の証言をする可能性がある。

これに対して本実施の形態に係るＭＰＣ－ＺＫＰシステム２を利用する場合、データｘはシェア化（図３に示す例では２－ｏｕｔ－ｏｆ－２秘密分散を想定し、シェアをｘ１、ｘ２であらわす）されるのでデータの秘匿性が保持される。検証ロジック式は評価者を離れ、検証者によりチェックおよびデプロイされ、かつ、評価対象により合意されるものとなる。この検証ロジック式はＣＲＳで縛られるので検証ロジック式の改ざんは不可能となる。検証ロジック式とシェアとはＭＰＣ－ＺＫＰシステム２に提供され、そこで証言が作成される。検証者は、ＭＰＣ－ＺＫＰシステム２が出力する出力シェア（例えば、ｙ１、ｙ２）を集めて結論ｙを復元することで、非感染者の証明を得ることができる。このように、データそのものが改ざんされない限り、客観性のある証言が可能となる。データそのものの改ざんについても、データ生成者によるシェアに対する署名などで部分的な改ざん対策が可能である。

図１の例ではデータ生成者６がデータ主体４からデータ（のシェア）の第三者提供について合意を取得しない場合について説明したが、これに限られず、データ生成者６はデータ主体４からデータのシェアの第三者提供について合意を取得できることがある。図１９は、データ生成者６が第三者提供について合意取得済みの場合のＭＰＣ－ＺＫＰシステム２の構成を示す模式図である。署名付きウィットネス（ｗ、ｗｓ）はデータ生成者６によりシェア化（ｗ_ｉ、ｗｓ_ｉ）され、データ主体端末１２を介することなく、データ生成者ＤＢ１４からＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティ９に提供される。

次に、ＭＰＣ－ＺＫＰシステム２の詳細を説明する。図４は、ＭＰＣ－ＺＫＰシステム２で実装される証明モードの特徴を表形式で示す図である。ＭＰＣ－ＺＫＰシステム２には(1)ユーザ端末によるゼロ知識証明モード、(2)ＭＰＣによる命題関数証言モード、(3)ＭＰＣによるゼロ知識証明モード、の３つの証明モードがあり、ユーザである検証者８は要件に応じてこれら３つのモードを使い分けることができる。それぞれのモードの特徴は図４に示されるとおりである。図中の通り、ＭＰＣによる命題関数証言モードは検証ロジックの透明性を備えないが、検証者が無作為あるいは任意に、ＭＰＣによるゼロ知識証明モードあるいはユーザ端末によるゼロ知識証明モードによる証明を請求できるため、ＭＰＣによる命題関数証言モードの出力において偽証がなされることへの抑止力として働く。ＭＰＣによるゼロ知識証明モードは計算量が膨大であるため、このモードの実行回数を減らすことができれば、総計算時間の短縮に寄与する。ＭＰＣによる命題関数証言モードには検証ロジックの透明性はないが、ＭＰＣによるゼロ知識証明モードに比べて迅速に結論（証言）を出力できる。したがって、ＭＰＣによるゼロ知識証明モードによる証明を、検証者の任意または無作為に実行させることで、計算負荷がかかるシーンを減らしつつ、ＭＰＣによる命題関数証言モードによる証言（命題関数の結果）において偽証がなされることを抑制できる。

次に、図１の検証者端末１６の構成について説明する。検証者端末１６のハードウェア構成については、図５を参照して後述するように、図５に記載のハードウエア構成と同様のハードウエア構成を有してよい。
検証者端末１６の機能構成例について、図１６を参照して説明する。なお、この図および以下で説明されるブロック図に示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
検証者端末１６は、検証ロジック式取得部１６２と、検証ロジック式デプロイ部１６４と、証言要求部１６５と、検証ロジック式ＤＢ１６６と、証拠要求部１６８と、検証部１７０と、を備える。検証者端末１６において、ＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティ９から集められた出力シェアにより、ＺＫＰあるいは証言による命題の検証が可能となる。

検証ロジック式取得部１６２は、検証ロジック式に利用可能な入力データクラスを管理サーバ２２から読み込むとともに、検証者８による入力に従って、検証ロジック式における（１）証明したい対象の関係式および（２）適用するＺＫＰスキームを取得する。検証ロジック式取得部１６２は、取得した検証ロジック式を検証ロジック式ＤＢ１６６に登録する。
検証ロジック式デプロイ部１６４は、検証ロジック式ＤＢ１６６に登録された検証ロジック式を管理サーバ２２にデプロイする。具体的には、検証ロジック式デプロイ部１６４は、検証ロジック式（Ｒｅｌａｔｉｏｎを表す式）およびＺＫＰスキームをサービス提供者７の管理サーバ２２に登録し、デプロイした検証ロジック式に関連付けられた検証ロジックＩＤを取得する。検証ロジック式取得部１６２は、検証ロジック式ＤＢ１６６へ検証ロジック式と検証ロジックＩＤを紐づけて登録する。

検証ロジック式ＤＢ１６６は、検証ロジック式を管理する。図１７には、検証ロジック式ＤＢ１６６に格納されるデータを示している。検証ロジック式ＤＢ１６６に格納されるデータは、例えば、検証ロジックＩＤと、検証ロジック式と、ＺＫＰスキームとを含む。なお、検証ロジック式ＤＢ１６６は、更に、登録を行った検証者ＩＤと関連付けられてもよいが、後述する管理サーバ２２に備わる検証ロジック式ＤＢ１１８のデータと同様の形式であってもよい。検証者８は任意のタイミングで検証ロジック式ＤＢ１６６のデータを閲覧することができる。

証言要求部１６５は、（検証者８による操作に応じて）検証ロジックＩＤとデータ主体ＩＤ対応値（詳細は後述する）とに関する証言（命題関数）を要求するための証言要求を、ＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティ９に送信する。なお、本実施形態では、証言要求をＭＰＣ参加パーティ９に送信する場合を例に説明しているが、証言要求を管理サーバ２２に送信し、管理サーバ２２から各ＭＰＣ参加パーティ９に証言を要求するようにしてもよい。
証拠要求部１６８は、ＭＰＣ参加パーティ９に対して、まず、検証ロジックＩＤとデータ主体ＩＤ対応値に紐づく追加情報を要求する。その後、ＭＰＣ参加パーティ９に対して、ＭＰＣ－ＺＫＰシステムにより計算された証拠（Ｐｒｏｏｆの出力シェア（π_ｉ））を要求する。例えば、証拠要求部１６８は、検証者８による操作による要求、または証拠要求部１６８における所定の判定に基づいて、証拠要求を生成し、ＭＰＣ参加パーティ９に送信する。証拠要求部１６８は、所定の判定を以下のように行なってもよい。例えば、証拠要求部１６８は、命題関数の出力シェアを取得した直後に、ローカルで生成した乱数、又は、シェア取得時点以降の（所定のブロックチェーンアルゴリズムを用いた）パブリックチェーンにおいて、あるブロックハイトにおけるトランザクションハッシュを乱数として捉え、これが所定の閾値を超えたかを判定する。証拠要求部１６８は、上記の乱数又はトランザクションハッシュが所定の閾値を超えた場合に、（検証者８による操作による要求を待つこと無く）証拠要求を生成する。なお、本実施形態では、追加情報の要求および証拠要求をＭＰＣ参加パーティ９に送信する場合を例に説明しているが、証拠要求を管理サーバ２２に送信し、管理サーバ２２から各ＭＰＣ参加パーティ９に追加情報や証拠を要求するようにしてもよい。

検証部１７０は、ＭＰＣ参加パーティ９から出力される証言（命題関数）の出力シェアを取得して、Ｒｅｃｏｎｓｔｒｕｃｔし、証言τを取得する。
また、検証部１７０は、証拠を要求した場合、ＭＰＣ参加パーティ９から、証拠（ＺＫＰ）の出力シェア（π_ｉ）と、検証ロジック式に紐づく追加情報とを取得する。検証部１７０は、取得した出力シェアを集めることで、ＺＫＰ（Ｐｒｏｏｆ）を復元する。例えば、検証部１７０は、管理サーバ２２の公開鍵を用いて、署名付きの出力シェアと、検証ロジック式と、（ＴｒｕｓｔｅｄＳｅｔｕｐを用いる場合は）ＣＲＳ（特に、ＶｅｒｉｆｉｃａｔｉｏｎＫｅｙ）とを認証する。また、検証部１７０は、復元されたＺＫＰ（Ｐｒｏｏｆ）と、検証ロジック式と、（ＴｒｕｓｔｅｄＳｅｔｕｐが用いられる場合は）認証されたＣＲＳのＶｅｒｉｆｉｃａｔｉｏｎＫｅｙとを用いて検証を行う。検証部１７０は、検証結果として、例えば、受理（Ａｃｃｅｐｔ）又は拒否（Ｒｅｊｅｃｔ）のいずれかを出力する。
なお、図１６には明示していないが、検証者端末１６は、検証者８の登録を行って、それぞれの検証者を一意に特定する検証者ＩＤを取得するための検証者登録部を更に有してもよい。例えば、検証者ＩＤをデータ主体４に提供することにより、データ主体８が（データの扱いに関する個別のポリシーを運用する際に）検証者に対する所望のアクセス制御を実現することができる。
ここで、上述したデータ主体ＩＤ対応値について説明する。データ主体ＩＤ対応値は、検証ロジック式における個人のデータを入れ替え可能にして、検証ロジック式を、異なる個人の組み合わせの証明に使いまわすことを可能にするためのデータである。
例えば、検証ロジック式として以下のものを用いる場合を考える。なお、以下の検証ロジック式におけるＳｉｇＶｅｒｉｆｙ関数は、第一引数の公開鍵を用いて、第二引数の値について第三引数のデジタル署名で完全性を検証する関数を表す。
－－＜検証ロジック式＞－－
ＤＣ００８［０］＋ＤＣ００８［１］＞１０００００００
＆＆ＳｉｇＶｅｒｉｆｙ（ＤＣ０１２，ＤＣ００８［０］，ＤＣ０１３［０］］＝＝ｔｒｕｅ
＆＆ＳｉｇＶｅｒｉｆｙ（ＤＣ０１２，ＤＣ００８［１］，ＤＣ０１３［１］］＝＝ｔｒｕｅ
－－－－－－－－－－－－－－
この検証ロジック式において、ＤＣｘｘｘはデータクラスを表しており、ＤＣ００８は年収を、ＤＣ０１２は市役所の公開鍵を、ＤＣ０１３は年収に対する市役所の署名を、それぞれ表している。「［０］，［１］，．．」は添え字であり、各データクラスの具体的な対象を識別する。例えば、ＤＣ００８［０］はＡさんの年収であり、ＤＣ００８［１］はＢさんの年収を指す。これは検証ロジック式のＡＳＴｓ（ＡｂｓｔｒａｃｔＳｙｎｔａｘＴｒｅｅｓ）において、変数から添え字を抽出することにより実装可能である。ただし、添え字を囲うブラケット（［］）は異なる表現を用いても良い。たとえば既存のプログラミング言語（Ｃ言語など）の表現を検証ロジック式の文法として踏襲する場合、配列表現と衝突することから、異なる記号、異なる配置により、表現を別にしてもよい。
データ主体ＩＤ対応値は、データクラスの対象を代入により指定可能にする仕組みであり、例えば、データ主体ＩＤ対応値を［ＤＳ００３，ＤＳ００４］の配列形式で指定すると、ＤＣ００８［０］及びＤＣ００８［１］のデータ主体を、
ＤＣ００８［０］＝ＤＳ００３、及びＤＣ００８［１］＝ＤＳ００４
のように割り当てることができる。
この場合、上記の検証ロジック式は、「同じ市役所から署名を受けたデータ主体の二人の年収の合計が１千万円を超えているか」を意味する式となる。このように、データ主体ＩＤ対応値に並べるデータ主体ＩＤの順番（配列の添え字）を変えたり、他のＩＤを指定すれば、作成された検証ロジック式を、異なる個人の組み合わせの証明に再利用することが可能になる。なお、検証ロジック式が、一人のデータ主体を対象とする証明である場合、上記の添え字は省略可能であり、データ主体ＩＤ対応値は単体のデータ主体ＩＤがそのまま指定されてよい。

次に、ＭＰＣ参加パーティ９（ＭＰＣ参加サーバともいう）の構成について説明する。図５は、図１のＭＰＣ参加パーティ９のハードウエア構成図の一例である。他のＭＰＣ参加パーティ、検証者端末１６、データ主体端末１２、データ生成者端末２４も、図５に記載のハードウエア構成と同様のハードウエア構成を有してよい。ＭＰＣ参加パーティ９は、メモリ１３０と、プロセッサ１３２と、通信インタフェース１３４と、ディスプレイ１３６と、入力インタフェース１３８と、を含む。これらの要素はそれぞれバス１４０に接続され、バス１４０を介して互いに通信する。

メモリ１３０は、データやプログラムを記憶するための記憶領域である。データやプログラムは、メモリ１３０に恒久的に記憶されてもよいし、一時的に記憶されてもよい。プロセッサ１３２は、メモリ１３０に記憶されているプログラムを実行することにより、ＭＰＣ参加パーティ９における各種機能を実現する。通信インタフェース１３４は、ＭＰＣ参加パーティ９の外部との間でデータの送受信を行うためのインタフェースである。例えば、通信インタフェース１３４はネットワークにアクセスするためのインタフェースを含み、該ネットワークを介して他のＭＰＣ参加サーバやデータ主体端末１２や検証者端末１６とデータの授受を行う。ディスプレイ１３６は、各種情報を表示するためのデバイスであり、例えば、液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどである。入力インタフェース１３８は、ユーザからの入力を受け付けるためのデバイスである。入力インタフェース１３８は、例えば、マウスやキーボードやディスプレイ１３８上に設けられたタッチパネルを含む。

図６は、図１のＭＰＣ参加パーティ９の機能構成例を示すブロック図である。それぞれのＭＰＣ参加パーティ９（すなわちＰ_ｉ）は、入力データ取得部１０２と、インスタンス保持部１０３と、計算部１０４と、データ提供部１０６と、シェア削除部１０８と、シェア保持部１０９と、を備える。

入力データ取得部１０２は、証明したい事項に係るデータを取得する。データには２種類あり、Ｉｎｓｔａｎｃｅと、署名付きウィットネスのシェア（Ｗｉｔｎｅｓｓのシェア）である。シェア取得部１０２は、データ主体端末１２またはデータ生成者端末２４からネットワークを介して、Ｉｎｓｔａｎｃｅと、秘密分散された署名付きウィットネスのシェア（ｗ_ｉ、ｗｓ_ｉ）を取得する。なお各種シェアは｛Ｐ_ｉ、ｗ_ｉ、ｗｓ_ｉ、ｖ_ｉ、τ_ｉ、π_ｉ｜ｉ∈｛０，１，…、ｎ－１｝｝で表現され、ｎはＭＰＣ参加パーティ群１０におけるＭＰＣ参加パーティ９の数、すなわちＭＰＣに参加するパーティ数であり、ｉは個々のＭＰＣ参加パーティ９を一意にするものとする（Ｐ_ｉ）。なお、入力データ取得部１０２は、Ｉｎｓｔａｎｃｅが参照で渡される場合には、その実体（例えばデータ生成者６の公開鍵）をネットワークを介して更に取得する。

入力データ取得部１０２は、ＭＰＣ参加パーティ群１０のＭＰＣ参加パーティ９同士で通信し、署名付きウィットネスのシェア（Ｗｉｔｎｅｓｓのシェア）を入力としたデジタル署名の完全性の検証アルゴリズムをＭＰＣ処理する。そして、結果として得られた出力シェア（ｖ_ｉ）をＭＰＣ参加パーティ９同士で共有し、検証の結果（ｖ）をＲｅｃｏｎｓｔｒｕｃｔ（復元）する。入力データ取得部１０２は、検証が成功したことを確認すると、署名付きウィットネスのシェアをシェア保持部１０９に登録する。更に、入力データ取得部１０２は、Ｉｎｓｔａｎｃｅをインスタンス保持部１０３に登録する。シェアデータ保持部１０９及びインスタンス保持部１０３は、図２２に示す形式（例えばデータ主体ＩＤ、データクラスＩＤ及び値の組）でこれらのデータを保持する。

計算部１０４は、検証者端末１６からの証言要求を受けつけたことに応じて命題関数の計算を行うほか、検証者端末１６から証拠要求を受け付けたことに応じてＺＫＰの計算を行う。
（１）検証者端末１６からの証言要求を受けつける場合について説明する。計算部１０４は、検証者端末１６からデータ主体ＩＤ対応値と検証ロジックＩＤとに関する証言要求を受け付ける。計算部１０４は、証言要求を受け付けると、当該データ主体ＩＤ対応値と検証ロジックＩＤとに基づく命題関数実行に向けた処理を開始する。
計算部１０４は、まず、管理サーバ２２から検証ロジック式と検証ロジックＩＤとを取得する。更に、（管理サーバ２２から得られる）データ主体ＩＤ対応値に含まれるデータ主体ＩＤ全ての個別ポリシーについて、個別ポリシーＤＢのデータに示される保護範囲を満たすかを判定する。計算部１０４は、すべてのデータ主体ＩＤについて保護範囲を満たすと判定した場合に、検証ロジック式に含まれるデータクラスのシェアと、Ｉｎｓｔａｎｃｅの値とに基づいて、検証ロジック式に従う命題関数を計算する。
計算部１０４は、計算に用いたデータ主体ＩＤ対応値に関連するデータ（すなわちデータ主体ＩＤの漏れたプライバシー）を、管理サーバ２２に送信し、検証履歴ＤＢ１４２に登録させることができる。すなわち、計算部１０４は、データ主体ＩＤ対応値に関するどのようなデータが命題計算に用いられたのかを管理サーバ２２に管理させ、必要なプライバシーコントロールを実現する。
（２）次に、検証者端末１６からの証拠要求を受けつけてＺＫＰを計算する場合について説明する。この場合、計算部１０４は、事前に、検証者端末１６からデータ主体ＩＤ対応値と検証ロジックＩＤとに関する追加情報の要求を受け付けて、データ主体ＩＤ対応値と検証ロジックＩＤとに紐づく追加情報を取得する。計算部１０４は、取得した追加情報或いは計算した追加情報を検証者端末１６へ送信する。
検証者端末１６は、追加情報を受信したことに応じて取得に応じて証拠要求を送信するため、計算部１０４は、検証者端末１６から証拠要求を受け付ける。なお、検証者端末１６から要求されるＺＫＰのＺＫＰスキームがＩｎｔａｒａｃｔｉｖｅＺＫである場合、計算部１０４は、データ主体ＩＤ対応値と検証ロジックＩＤに加えて、検証者端末１６からチャレンジ情報を受信する。計算部１０４は、証拠要求（或いは証拠要求とチャレンジ情報）を受け付けると、当該データ主体ＩＤ対応値と検証ロジックＩＤに基づくＺＫＰ実行に向けた処理を開始する。
計算部１０４は、まず、管理サーバ２２から検証ロジック式と検証ロジックＩＤとを取得する。また、計算部１０４は、検証者端末１６に送信した追加情報を読み出しておく。ここで、計算部１０４は、（管理サーバ２２から得られる）データ主体ＩＤ対応値に含まれるデータ主体ＩＤ全ての個別ポリシーについて、管理サーバ２２の個別ポリシーＤＢのデータに示される保護範囲を満たすかを判定する。計算部１０４は、すべてのデータ主体ＩＤについて保護範囲を満たすと判定した場合に、検証ロジック式に含まれるデータクラスのシェアと、Ｉｎｓｔａｎｃｅの値と、追加情報とに基づいて、検証ロジック式に従うＺＫＰを計算する。その後、計算部１０４は、ＺＫＰの計算後に得られる出力シェア（Ｐｒｏｏｆであるπのシェア、π_ｉ）をシェア保持部１０９に格納する。
なお、上述の追加情報は、例えば、図２３に示すデータ形式で、不図示の追加情報ＤＢに格納されてもよいし、所定期間の間、メモリに格納されていてもよい。追加情報のデータは、例えば、図２３に示すように、検証ロジックＩＤと、データ主体ＩＤ対応値とに関連付けられてよい。追加情報には、ＣＲＳやコミットメントが含まれることがある。追加情報は、ＺＫＰスキームに応じて異なり、ＺＫＰスキームがＳｃｈｎｏｒｒ’ｓＰｒｏｔｏｃｏｌ、ＳｉｇｍａＰｒｏｔｏｃｏｌなどのＩｎｔｅｒａｃｔｉｖｅＺＫに属す場合、追加情報は例えばコミットメントを含む。ＺＫＰスキームが、ｚｋ－ＳＮＡＲＫｓやＧｒｏｔｈＳａｈａｉなどの、特定パーティにＴｒｕｓｔを求めるＮＩＺＫ（ＮｏｎＩｎｔａｒａｃｔｉｖｅＺＫ）に属す場合、追加情報は例えばＣＲＳ（ＣｏｍｍｏｎＲｅｆｅｒｅｎｃｅＳｔｒｉｎｇ）を含む。また、ＺＫＰスキームが、ＲＯ仮定のｚｋ‐ＳＴＡＲＫｓなどの、特定パーティにＴｒｕｓｔを求めないＮＩＺＫに属す場合、追加情報は例えばコミットメント（ＭｅｒｋｌｅＴｒｅｅ、ＭｅｒｋｌｅＴｒｅｅＲｏｏｔ）を含む。
また、命題関数またはＺＫＰによって得られる出力シェアは、例えば、図２４に示すデータ形式でシェア保持部１０９に格納されてよい。図２４に示すデータ形式では、例えば、データ主体ＩＤ対応値と、検証ロジックＩＤとに関連付られた命題関数及びＺＫＰの出力シェアと計算開始日時とを格納する。

データ提供部１０６は、計算部１０４が命題関数を実行した場合、計算の結果として得られた出力シェアを検証者端末１６に出力する。また、計算部１０４がＺＫＰを実行した場合、計算の結果として得られた出力シェアと計算部１０４で用いられた追加情報とを検証者端末１６に出力する。また、このとき、データ提供部１０６は、（管理サーバ２２から得られる）データ主体ＩＤ対応値に含まれるデータ主体ＩＤ全ての個別ポリシーについて、個別ポリシーＤＢのデータに示される保護範囲を満たすかを判定し、すべてのデータ主体ＩＤについて保護範囲を満たすと判定した場合に、出力シェア（ＺＫＰの場合には更に追加情報）を出力するようにしてもよい。

シェア削除部１０８は、データ主体４が用いるデータ主体端末１２および／またはデータ生成者６の用いるデータ生成者端末２４から削除要求を受け取ると、対象となるシェアをシェア保持部１０９から削除する。

図７は、図１のＭＰＣ参加パーティ群１０を管理するためにサービス提供者７が運用する管理サーバ２２の機能構成例を示すブロック図である。管理サーバ２２は、管理情報制御部１１０と、セットアップ部１１２と、検証要求取得部１１４と、判定部１１６と、検証ロジック式ＤＢ１１８と、データクラスＤＢ１２０と、データ主体ＤＢ１２２と、検証者ＤＢ１２４と、個別ポリシーＤＢ１２８と、検証履歴ＤＢ１４２と、を備える。

管理情報制御部１１０は、管理サーバ２２の各種ＤＢに登録されるデータ（例えば、データ主体、検証者、検証ロジック式、データクラスなど）を一意にするＩＤを発行する。データ主体ＩＤは、データ主体を一意に特定する情報であり、管理情報制御部１１０がデータ主体の登録時に当該ＩＤを発行する。なお、データ主体は、個人に限らず、組織であってもよい。検証者ＩＤは、検証者を一意に特定する情報であり、管理情報制御部１１０が検証者の登録時に当該ＩＤを発行する。なお、サービス提供者が検証者として登録される場合があってもよい。検証ロジックＩＤは、検証ロジック式とＺＫＰスキーム（ＺＫＰの種類）とを含む。検証ロジックＩＤは、検証ロジック式とＺＫＰの種類との組み合わせを一意に特定する。本実施形態では、命題関数もＺＫＰも、同一の形式の検証ロジック式に基づいて計算可能である。データクラスＩＤは、データクラスを一意に特定する情報であり、データクラスはデータのクラス名（例えば「年齢」）とデータの型（例えばブール型やビット数など）を含み、データクラスＩＤが指定されると、データのクラスとその公開・非公開の別（すなわちウィットネスかインスタンスか）とが一意に特定される。データクラスＩＤは、管理情報制御部１１０がデータクラスの登録時に発行する。
また、管理情報制御部１１０は、システム２における検証者端末１６やデータ主体端末１２或いはＭＰＣ参加パーティ９などとの間でデータの送受信を行って、各種ＤＢへのデータの書き込み及び読み出しを制御する。以下、管理情報制御部１１０による各種データの登録等について説明する。
（１）データ主体情報の登録制御
管理情報制御部１１０は、データ主体端末１２においてデータ主体の情報が登録される際に、データ主体端末１２から、データ主体の名前・住所等の身元情報と、身元情報に対する認証機関からの署名とを取得して、データ主体ＤＢ１２２にデータを登録する。このとき、管理情報制御部１１０は、新規データ主体に対してデータ主体ＩＤを発行し、データ主体端末１２に送信する。データ主体ＤＢ１２２は、例えば図９に示すように、データ主体を特定するデータ主体ＩＤと、データクラスを特定するデータクラスＩＤと、データ主体に対して公開されているデータとを関連付けたデータを記録する。なお、データ主体ＤＢ１２２に記録されるＩＤの情報は、公開されてもよく、公開される場合にはＩｎｓｔａｎｃｅとして扱われる。データ主体ＤＢ１２２に記録されるデータ主体の情報は、ＭＰＣパーティ９のそれぞれにシェアとして記録され、秘匿される。データ主体が、複数のデータ主体ＩＤを取得して、目的ごとにデータ主体ＩＤの情報を使い分ければ、情報が分散化され、１つのデータ主体の情報を複数収集することで当該データ主体の身元情報の全体が把握されることを防止することもできる。
（２）検証者情報の登録制御
管理情報制御部１１０は、検証者端末１６において検証者の情報が登録される際に、検証者端末１６から、検証者の身元情報を取得して、検証者ＤＢ１２４にデータを登録する。このとき、管理情報制御部１１０は、新規検証者に対して検証者ＩＤを発行し、検証者端末１６に送信する。検証者ＤＢ１２４は、例えば、図１１に示すように、検証者ＩＤと、検証者組織名と、特権照会フラグとを関連付けたデータを記録する。特権照会フラグは、設定されたプライバシーポリシーとは無関係に、証言や証拠の出力シェアを得ることができる特権を有する検証者を示すフラグである。フラグが「Ｔｒｕｅ」に設定されている場合（例えばサービス提供者や権限を有する行政機関など）、当該特権を有することを示す。
（３）データクラスの参照制御
管理情報制御部１１０は、検証者が検証者端末１６において検証ロジック式を生成・編集する際に、検証者端末１６からデータクラスの参照を受け付けて、データクラスの情報を検証者端末１６に送信する。データクラスの情報は、例えば、サービス提供者或いはデータ生成者６等によって登録され、管理情報制御部１１０は、当該データクラスが登録されると、データクラスＩＤを発行してデータクラスＤＢ１２０に情報を登録する。データクラスＤＢ１２０は、例えば図１０に示すように、データクラスＩＤと、データクラス名と、そのデータクラスのデータ形式と、データ形式をより詳細に説明するデータ形式詳細と、公開区分とを関連付けたデータを記録する。データ型は例えばＢｏｏｌ値やビット数などである。データクラスの形式が定まれば、そのデータのシェアの種類（形式）も定まるから、データクラスＤＢ１２０にはデータのシェアの形式が登録されているとも言える。なお、公開区分が非公開に設定されたデータクラスはウィットネスであり、公開区分が公開に設定されたデータクラスはインスタンスとなる。
（４）検証ロジック式の登録・参照制御
管理情報制御部１１０は、検証ロジック式が検証者端末１６から送信されてきたときに、当該検証ロジック式を検証ロジック式ＤＢ１１８に登録する。このとき、管理情報制御部１１０は、検証ロジックＩＤを発行して、発行した検証ロジックＩＤを検証者端末１６に送信する。検証ロジック式ＤＢ１１８は、図８に示すように、検証ロジック式を特定する検証ロジックＩＤと、検証ロジック式と、ＺＫＰを実行する場合にどのＺＫＰアルゴリズム（スキーム）を用いるかを識別するＺＫＰスキームと、を関連付けて記録する。検証ロジックＩＤは、処理内容（計算式）と入力データ形式（ｊｓｏｎ、ｙａｍｌ、ｔｏｍｌなど）をハッシュ値にした値であり、検証ロジック式と署名付き検証ロジック式を一意に特定する。検証ロジック式は、疑似コードであってよい。また、検証ロジック式は、「＃」などの予め定められた特定の記号を、疑似コード内のコメント文を識別するための記号として用いてもよい。
管理情報制御部１１０は、検証者端末１６が検証ロジックＩＤと検証ロジック式をＭＰＣ参加パーティ９に提供するために、検証ロジックＩＤと検証ロジック式にアクセスした場合、検証者端末１６に検証ロジックＩＤと検証ロジック式を提供する。或いは、検証者端末１６から、ＭＰＣ参加パーティ９に検証ロジックＩＤと検証ロジック式を提供するよう要求があった場合に、検証ロジックＩＤと検証ロジック式をＭＰＣ参加パーティに提供するようにしてもよい。
また、管理情報制御部１１０は、必要に応じて又はデータ主体端末１２からの要求に応じて、検証ロジックＩＤと検証ロジック式とをデータ主体端末１２へ送信する。
（５）個別ポリシーの登録制御
データ主体端末１２から、検証者ＩＤに対するプライバシーポリシーの登録要求を受けたことに応じて、管理情報制御部１１０は、当該プライバシーポリシーを個別ポリシーＤＢ１２８に登録する。個別ポリシーＤＢ１２８は、図１２に示すように、例えば、プライバシーポリシーを設定したデータ主体を特定するデータ主体ＩＤと、当該プライバシーポリシーに係るデータクラスを特定するデータクラスＩＤと、検証ロジックＩＤと、当該プライバシーポリシーの対象となる検証者を特定する検証者ＩＤと、当該プライバシーポリシーの有効期間と、当該プライバシーポリシーの保護範囲とが関連付けられたデータを記録する。
有効期間は、当該プライバシーポリシーが適用される期間を示し、図１２の例では分単位で示されている。指定した期間を経過すると保護されないこととなる。保護範囲は、複数の証明の実行により真の値がどの範囲にあるかを、どこまで絞り込むことを許容するかを示す範囲を表す。具体的には、１９８０年１０月１日を示す生年月日のデータを例に説明する。例えば、データ主体の生年月日が１９７５年以降（＞１９７４１２３１）であることの証明(1)と、当該生年月日が１９９６年以前（＜１９９６０１０１）であることの証明(2)とが実行された時点で、データ主体の生年月日が１９７５年から１９９６年の間であるというプライバシーが漏れている。しかし、例えば、プライバシーが漏れる期間が、保護範囲で指定された値よりも大きい場合には、証明(1)及び証明(2)は許容される。これに対し、更に、当該データ主体の生年月日が１９８３年以前（＜１９８４０１０１）であることの証明を行う場合に、プライバシーが漏れる範囲が保護範囲で指定された値より小さくなる（すなわち、狭い範囲まで絞り込まれる）場合には、当該証明の実行は拒否される。
なお、データクラスの有する値の尺度には、名義尺度（概念を区別するために用いられる尺度）、順序尺度（大小関係に意味がある尺度）、間隔尺度（間隔の大きさすなわち通知の差）に意味がある尺度、比例尺度（数値の差とともに数値の比にも意味がある尺度）などがある。上述の保護範囲は、これらの尺度のうち、順序削除、間隔尺度および比例尺度に対して設定可能である。
（６）検証履歴の登録・参照制御
ＭＰＣ参加パーティ９による命題関数又はＺＫＰの実行時において、ＭＰＣ参加パーティ９が証明を実行しても個別ポリシーに反しないか判定する際に、検証履歴ＤＢのデータが参照される。このとき、管理情報制御部１１０は、ＭＰＣ参加パーティ９による参照要求に応じて、対応する検証履歴ＤＢのデータをＭＰＣ参加パーティ９に送信する。また、ＭＰＣ参加パーティ９による命題関数又はＺＫＰの実行後に、ＭＰＣ参加パーティ９から検証履歴の登録を受け付ける。具体的には、ＭＰＣ参加パーティ９が命題関数又はＺＫＰの実行に用いた検証ロジック式に含まれる（データ主体ＩＤ対応値に関連する）各データクラスについて、データの使用可能な上限値や下限値を登録する要求を管理サーバ２２に送信する。この場合、管理情報制御部１１０は当該履歴情報を検証履歴ＤＢ１４２に登録する。検証履歴ＤＢ１４２は、例えば、図１３に示すように、例えば、データ主体ＩＤと、データクラスＩＤと、検証者ＩＤと、下限値、上限値およびそれぞれの最終証明日時等とが関連付けられたデータを記録する。下限値および上限値の記録として、検証ロジックにおけるインスタンスとの比較（証明）を記録することで、個別ポリシーを用いた証明の実行可否の判定を実現することができる。なお、最終証明日時に係る項目は、ＮＩＺＫによりＺＫＰを実行する場合、最終証明日時を証明実行時点よりも将来の値として扱うための所定の値（例えば９９９９９９９９）で埋められてもよい。
上述した管理情報制御部１１０による登録や参照等の処理の順番は、上記に記載のとおり、データ主体情報の登録制御、検証者情報の登録制御、データクラスの参照制御、検証ロジック式の登録・参照制御、個別ポリシーの登録制御、検証履歴の登録・参照制御の純に制御されてよい。或いは、管理情報制御部１１０は、個別ポリシーの登録制御を任意のタイミングで行うようにしてもよいし、ＭＰＣ参加パーティ９から、検証者による証明の要求を受けた旨の通知を受信したことに応じて、個別ポリシーの登録制御を行うようにしてもよい。

セットアップ部１１２は、アルゴリズムと署名付きＣＲＳとを生成する。セットアップ部１１２は、検証ロジック式がデプロイされたとき、その検証ロジック式に対応するＺＫＰをＭＰＣで計算するためのＭＰＣ用のプロトコルを生成する。併せてセットアップ部１１２はＣＲＳを算出する。ＺＫＰスキームがＴｒｕｓｔｅｄＳｅｔｕｐを求める場合、管理サーバ２２だけでなくＭＰＣ参加パーティ９全てが協力することで談合を難化させることができる。セットアップ部１１２は、生成されたＣＲＳにデジタル署名する。セットアップ部１１２は、生成されたプロトコルおよび署名付きＣＲＳを各ＭＰＣ参加パーティ９に配布する。

図７に戻り、検証要求取得部１１４は、検証者８の検証者端末１６からネットワークを介して、証言要求または証拠要求を取得する。証言要求及び証拠要求は、例えば、データ主体ＩＤ対応値と、検証者８が求める証明ロジック式の検証ロジックＩＤと、を含む。

判定部１１６は、取得された検証要求に応じて、出力プライバシー保護の観点から、検証要求を拒否するか否かを判定する。判定部１１６による、検証要求を拒否するか否かの判定は、個別ポリシーＤＢ１２８及び検証履歴ＤＢ１４２に格納されたデータを用いることにより実現される。

（上述のクエリ監査法による）出力プライバシー保護の観点について、より具体的に説明する。一般に、命題関数或いはＺＫＰにより直接的には元のデータが検証者に知られることはない。しかし、（個別ポリシーの登録制御において示したように）検証者による同一データクラスのデータに対する検証に制限がない場合、検証を繰り返すことで結果的に元のデータが漏れる可能性がある。例えば、選択平文への対処が問題となることがあり、特に取り得る値の範囲が狭いクラスを使った計算は問題化しやすい。

例えば、年齢について、
●５０歳以上ですか？→Ｆａｌｓｅ
●２５歳以上ですか？→Ｔｒｕｅ
●３７歳以上ですか？→Ｆａｌｓｅ
●３１歳以上ですか？→Ｔｒｕｅ
●３４歳以上ですか？→Ｔｒｕｅ
●３５歳以上ですか？→Ｆａｌｓｅ
のように検証を繰り返すことで、それぞれの検証結果からは正確な年齢は分からないものの、複数の検証結果を統合することで、実年齢の取りうる範囲を絞り込むことができたり、データ主体が３４歳であることが特定されてしまう。

本実施の形態に係る出力プライバシーの保護では、ＭＰＣ－ＺＫＰでは守り切れないプライバシー（出力プライバシー）の保護を最大化するため、サーキットブレーカーの役割をＭＰＣ参加パーティ９またはサービス提供者７が担う。検証者８がリクエストしてきた検証ロジックにより、プライバシーが著しく危殆化する命題関数又はＺＫＰの計算は、ＭＰＣ参加パーティ９またはサービス提供者７が拒否する。その意味でＭＰＣ参加パーティ９またはサービス提供者７は出力プライバシーの保護におけるサーキットブレーカーの役割を果たす。なお、危殆化の基準はサービスの性質、消費者との合意により決定されてもよい。

管理サーバ２２により実現される出力プライバシーの保護機能は、個別ポリシーＤＢ１２８によってデータ主体４が検証者８に知られてよいプライバシーの範疇を決定づけ、判定部１１６によって順序尺度以上のデータについて、データ主体４を出力プライバシーへの脅威から保護するものである。判定部１１６は、検証要求取得部１１４によって取得された検証要求の内容と、個別ポリシーＤＢ１２８に保持されるプライバシーポリシーと、検証履歴ＤＢ１４２に保持される検証の履歴と、に基づいて、検証要求を拒否するか否かを判定する。

より具体的には、プライバシーポリシーに反する命題関数又はＺＫＰが検証者８によって要求された場合、判定部１１６は計算を拒否する（または、判定部１１６はＭＰＣ参加パーティ９に計算を拒否させる）。個別ポリシーＤＢ１２８に保持されうるプライバシーポリシーの具体例は以下のとおりである。
●ポリシー１：ある期間内（例：２年以内）に、特定の検証者に対し、一定以上のプライバシーが漏れることを避ける。
●ポリシー２：特定の検証者に対し、一定以上のプライバシーが漏れることを避ける。
●ポリシー３：ある期間内に、すべての検証者に対し、一定以上のプライバシーが漏れることを避ける。
●ポリシー４：すべての検証者に対し、一定以上のプライバシーが漏れることを避ける。

上記のプライバシーポリシーの説明中に表される「一定以上のプライバシー」は、データ主体毎に個別に設定可能である。例えば「年齢が１０年単位の誤差で特定されたくない（例：４０歳未満でかつ３０歳以上）」、「貯蓄が１００万円単位の誤差で特定されたくない」といった条件により定まる。

このようなプライバシーポリシーを、データ主体とデータ（データクラス）の種類（例：年齢、所得など）毎に個別ポリシーＤＢ１２８において管理する。これに反する命題関数又はＺＫＰが要求された場合、出力プライバシーへの脅威からデータ主体４を保護するよう、判定部１１６が検証要求を拒否する。

判定部１１６は、検証要求を承認した場合、ＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティ９に命題関数又はＺＫＰを実行させ、その結果得られる出力シェアを検証者端末１６に提供させる。あるいはまた、判定部１１６は、検証要求を承認した場合、検証者ＤＢ１２４に保持される対応する出力シェアを検証者端末１６に提供する。

図２１は、データ主体４のデータ主体端末１２のディスプレイに表示される出力プライバシー漏洩通知画面９００の代表画面図である。出力プライバシー漏洩通知画面９００は、検証履歴ＤＢ１４２を参照することで生成され、命題関数或いはＺＫＰにより漏れたプライバシー範囲をデータ主体４に提示する。図２１に示す例では、年齢のうち検証の判断に用いられた範囲が斜線で示されている。なお、図２１では一次元的表示を採用したが、ベン図などの二次元的表示を採用してもよい。

図１４は、図１のデータ主体端末１２の機能構成例を示すブロック図である。データ主体端末１２は、管理情報要求部１４４と、データ取得部１４６と、データ提供部１４８と、個別ポリシー部１５０と、データ削除要求部１４５と、を備える。

管理情報要求部１４４は、サービス提供者７の管理サーバ２２に対して、管理情報（特に検証ロジック式）を要求する。管理情報要求部１４４は、検証ロジックＩＤに対応付けられた管理情報を取得して、ディスプレイに表示させる。データ主体４は、検証者８の要求する検証ロジック式を閲覧、確認することができ、データ生成者６に対して必要なデータの生成（例えば病院の診察を受けるなど）を依頼することができる。

データ取得部１４６は、（データ生成者６或いはデータ生成者端末２４により）データ生成者６のデータ生成者ＤＢ１４に署名付きウィットネス（ｗ、ｗｓ）が格納されると、当該データ生成者ＤＢ１４から、署名付きウィットネスを取得し、キャッシュ保持部１５２に登録する。また、データ取得部１４６は、外部から必要なインスタンス（例：データ生成者６の公開鍵）を取得して、キャッシュ保持部１５２に登録する。

データ提供部１４８は、キャッシュ保持部１５２に格納されている署名付きウィットネス（ｗ、ｗｓ）をシェアにして、各署名付きウィットネスのシェア（ｗ_ｉ、ｗｓ_ｉ）（ｉ＝０～ＭＰＣ参加パーティ数－１）を、ＭＰＣ参加パーティ群１０の各ＭＰＣ参加パーティ９に提供する（すなわち秘密分散させる）。データ提供部１４８は、署名付きウィットネスのシェアのほか、インスタンスも各ＭＰＣ参加パーティ９に提供する。

個別ポリシー設定部１５０は、管理サーバ２２よりデータクラスを読み込んで、データクラスごとにプライバシーポリシーを設定する。例えば、データ主体４による操作に従って、データクラスごとにプライバシーポリシーを設定して、管理サーバに対してプライバシーポリシーを設定する。また、個別ポリシー設定部１５０は、データ主体４による操作に従って、いずれの検証者（検証者ＩＤ）に証明許可を与えるかを設定することができる。
データ削除要求部１４５は、ＭＰＣ参加パーティ群１０のＭＰＣ参加パーティ９に保持されるシェアの削除を要求することができる。
なお、図１４には明示していないが、データ主体端末１２は、データ主体の登録（データ主体の氏名や住所）を行って、それぞれの検証者を一意に特定するデータ主体ＩＤを取得するためのデータ主体登録部を更に有してもよい。このとき、データ主体ＩＤの情報への署名（例：公的機関による認証を確認可能な情報）を提供してよい。

図１５は、データ生成者端末２４の機能構成例を示すブロック図である。データ生成者端末２４は、検証ロジック取得部１５６と、データ観測部１５４と、デジタル署名部１５８と、データ提供部１６０と、シェア提供部１６１と、データ生成者ＤＢ１４と、を備える。

検証ロジック取得部１５６は、管理サーバ２２から検証ロジックを読み込んで、例えばディスプレイに表示させる。これにより、データ生成者８は、必要なデータとその形式を確認・理解することができる。
データ観測部１５４は、証明したい事項に係るデータを生成する。データ生成者６が医師・病院である例では、生成されるデータは診察結果や検体の解析結果などである。データ観測部１５４は、生成されたデータ（例えば生成されたデータのうちのウィットネス（秘密情報））を、データ生成者ＤＢ１４に登録する。なお、生成データのうちのインスタンス（公開情報）もデータ生成者ＤＢ１４に格納されてよい。データ観測部１５４は、更にデータ主体ＩＤ、各データのデータクラスＩＤを合わせて登録してよい。

デジタル署名部１５８は、データ観測部１５４により生成されたデータ（ウィットネス）にデジタル署名（例えばデータ生成者の秘密鍵で署名）を施すことで署名付きウィットネスを生成して、データ生成者ＤＢ１４に登録する。また、デジタル署名部１５８は、インスタンスへの署名を生成して、データ生成者ＤＢ１４に登録してもよい。

シェア提供部１６１は、デジタル署名部１５８によって生成された署名付きウィットネスをシェア化することで署名とデータのシェアを生成し、さらに各シェアにも署名を施す。シェア提供部１６１は生成された署名付きシェアをＭＰＣ参加パーティ９に提供することができる。なお、シェア提供部１６１は、データ主体端末１２からＭＰＣ参加パーティ９へシェアが提供される場合には、無効化されてよい。一方、図１９に示すように、データ生成者端末２４及びデータ生成者ＤＢ１４からＭＰＣ参加パーティ９にシェアを提供する構成では、有効化される。

データ提供部１６０は、データ主体端末１２からの要求に応じて、データ主体４のデータおよび対応する署名付きシェアをデータ主体端末１２に提供する。データ提供部１６０は、データ主体４から事前に合意があった場合、生成されたデータを他者・他社に提供することができる。

以上の構成によるＭＰＣ－ＺＫＰシステム２の動作を説明する。
図１８は、ＭＰＣ－ＺＫＰシステム２における証明のシーケンスの流れを示すチャートである。図１８はＺＫＰのアルゴリズムとしてｚｋ－ＳＮＡＲＫｓを採用する場合を説明する。図１８のシーケンスは上述のＭＰＣによるゼロ知識証明モードおよびユーザ端末によるゼロ知識証明モードに対応する。図１８のシーケンスはステップＳ８０２、Ｓ８０４、Ｓ８０６、Ｓ８０８、Ｓ８１０、Ｓ８１２を含み、そのうちステップＳ８０２、Ｓ８０４はサービス提供者７または検証者８による検証ロジックの定義の流れを示し、ステップＳ８０６、Ｓ８０８、Ｓ８１０、Ｓ８１２はＺＫＰの流れを示し、ステップＳ８０８、Ｓ８１０はＭＰＣの流れを示す。なお、ステップＳ８０８、Ｓ８１０はＭＰＣによるゼロ知識証明モードの場合に実行され、ユーザ端末によるゼロ知識証明モードでは行われない。

本シーケンスではまず、証明したい（検証したい）内容を規定し（ステップＳ８０２）、その検証ロジック式を生成する（ステップＳ８０４）。検証ロジックは検証者８が用意するか、あるいは「よく検証される内容」として、サービス提供者７が事前に用意してもよい。検証ロジック式には計算式（処理内容）と、入力データの形式（ｊｓｏｎ、ｙａｍｌ、ｔｏｍｌなど）が含まれる。また、検証ロジック式には、ＺＫＰスキームが関連付けられる。検証ロジックには、命題関数用とＺＫＰ用が存在する。本シーケンスではＺＫＰ用を想定し、命題関数用は後述する。検証ロジック式を受け取った管理サーバ２２は検証ロジックＩＤを発行する。

検証者８の検証者端末１６あるいはＭＰＣ参加パーティ９は、検証ロジックの証明に必要な検証ロジック式と、（ＴｒｕｓｔｅｄＳｅｔｕｐを用いる場合は）ＣＲＳとを計算する（ステップＳ８０６）。ＣＲＳの計算は、ＭＰＣ参加パーティ９による通常の計算で行ってもよい（シェア化された値を用いたＭＰＣを実施しなくてもよい）。しかしながら、採用するＺＫＰスキームがＴｒｕｓｔｅｄＳｅｔｕｐを求める場合、ＭＰＣ参加パーティ９（および検証者８）が協働してＳｅｔｕｐフェーズを行う。

ただし、ｚｋ‐ＳＴＡＲＫｓなど、ハッシュ関数の安全性（ランダムオラクル仮定）に依拠したスキームを採用する場合、ＴｒｕｓｔｅｄＳｅｔｕｐは不要である。

ステップＳ８０８において、証明に必要なデータを取得する。
＜ＭＰＣでＺＫＰを計算する場合、かつデータの第三者提供を前提としている場合＞
検証に必要な署名付きシェアが未登録の場合、ＭＰＣ参加パーティ９は、データ主体４またはサービス提供者７の依頼により、データ生成者６のデータ生成者端末２４へ署名付きシェアを要求する。あるいはまた、データ生成者６のデータ生成者端末２４から自動的に以下のデータ提供を進めてもよい。

データ生成者６のデータ生成者端末２４は、検証ロジック式をサービス提供者７の管理サーバ２２より取得し、入力データのフォーマットに従い、要求されたデータの署名付きシェア、すなわち平文の秘密分散（シェア化）した値と、平文への署名の秘密分散（シェア化）した値と、各シェアへ署名した値と、を用意する。データ生成者端末２４は、各署名付きシェアを１つずつＭＰＣ参加者９のＭＰＣ参加サーバ２０へ配布する。

ＭＰＣ参加パーティ９は、データ生成者６の公開鍵を取得し、それぞれが受け取った署名のシェアと署名付きシェアの完全性を検証する。

＜ＭＰＣでＺＫＰを計算する場合、かつデータの第三者提供を前提としていない場合＞
検証に必要なデータが未登録の場合、データ主体端末１２は、検証ロジック式をサービス提供者７の管理サーバ２２より取得し、入力データのフォーマットに従い、証明に必要なデータの平文と平文への署名をデータ生成者端末２４に要求する。

データ生成者端末２４は、要求されたデータの平文と、平文への署名と、を用意する。データ生成者端末２４は、これらをデータ主体端末１２へ提供する。

データ主体端末１２は、データ生成者６の公開鍵を使い、デジタル署名による完全性を検証する。

データ主体端末１２は、データ生成者端末２４から取得した平文と平文への署名のデータを秘密分散（シェア化）して、署名付きシェア（例えば署名付きウィットネスのシェア）を生成し、各署名付きシェアを１つずつＭＰＣ参加パーティ９へ配布する。

ＭＰＣ参加パーティ９は、データ生成者６の公開鍵を取得し、それぞれが受け取った署名付きシェア（例えば署名付きウィットネスのシェア）の完全性を検証する。

＜データ主体４のデータ主体端末１２上でＺＫＰを計算する場合＞
検証ロジックＩＤに対応付けられた入力データＩＤに基づいて、ローカルのデータ主体端末１２上でデータの登録（保存済みか否か）を確認する。未登録の場合、データ主体端末１２は、証明に必要なデータをデータ生成者端末２４に要求する。データ生成者端末２４は要求されたデータの平文と、平文への署名を用意する。データ生成者端末２４は、これらをすべてデータ主体端末１２へ提供する。データ主体端末１２は、データ生成者６の公開鍵を使い、署名が正しく認証できることを確認する。データ主体端末１２は、データをローカルのデータ主体端末１２上に登録する。

ステップＳ８１０において、証明者はＺＫＰを計算する。
＜証明者＝ＭＰＣ参加パーティ９の場合＞
ＭＰＣ参加パーティ９は、目的の検証ロジックＩＤに対応付けられた検証ロジック式、あるいはＴｒｕｓｔｅｄＳｅｔｕｐを用いる場合はＣＲＳに基づきＺＫＰを計算する。なお、ＺＫＰを計算するのは、上述のように検証ロジック式が個別プライバシーのプライバシーポリシーの条件を満たすに場合に限定されてよい。

計算結果のＺＫＰは出力シェアとしてシェア化された状態のままで、各出力シェアはＭＰＣ参加パーティ９が保持する。このとき、管理サーバ２２はまた、ＺＫＰのシェアである出力シェアの取得に対する認証のためのクレデンシャルを発行し、クレデンシャルＩＤを発行した上で対応付けるようにしてもよい。この場合、サービス提供者７はこのクレデンシャルＩＤに対応付けられた情報を検証者に、データ主体の事前・事後の承諾を得たうえで、直接通知する。あるいはクレデンシャルＩＤに対応付けられた情報をデータ主体４に通知し、データ主体４が証明したい相手（検証者８）のみにクレデンシャルＩＤに対応付けられた情報を知らせて、本人の属性に対応付けられた証明を提供可能にすることもできる。

このように、クレデンシャルを用いることにより、証明ＩＤに対応付けられたデータ主体４は、ＺＫＰの計算後に、クレデンシャルの情報の登録・削除により、証拠（ＺＫＰ）への検証者８のアクセス可否を制御することができる（許可／不許可を判断し、システムに指示できる）。ＭＰＣ参加パーティ９はデータ主体４の許可を受けた検証者８のみにＺＫＰの出力シェアをオンライン提供する（オンライン証明）。ただし捜査関係事項照会など、データ主体に照会が認知された場合に不都合があるような特例の状況においては、対処はサービス提供者の判断に基づき、この限りではない。

計算結果はデータ主体端末１２に配布され、データ主体４が検証者８に参照させてもよい（オフライン証明）。

＜証明者＝データ主体４（のデータ主体端末１２）の場合＞
データ主体端末１２からＭＰＣ参加パーティ９あるいは管理サーバ２２に、目的の検証ロジックＩＤに対応付けられた検証ロジック式、あるいはＴｒｕｓｔｅｄＳｅｔｕｐが用いられる場合はＣＲＳを要求する。

データ主体端末１２は、取得した検証ロジック式、あるいはＣＲＳに基づきＺＫＰを計算する。

計算結果はデータ主体端末１２に残し、自らの意思で検証者８に参照させる（オフライン証明）。またはサービス提供者７に預けて、検証者８がオンラインで検証可能にしてもよい（オンライン証明）。オンライン証明を可能にした場合、証明ＩＤに対応付けられたデータ主体４は、クレデンシャルＩＤに対応付けられた情報の登録・削除により、証拠（ＺＫＰ）への検証者８のアクセス可否を制御することができる（許可／不許可を判断し、システムに指示できる）。ＭＰＣ参加パーティ９はデータ主体４の許可を受けた検証者８のみにＺＫＰの出力シェアをオンライン提供する（オンライン証明）。

ステップＳ８１２において、検証者８はＺＫＰを検証する。
＜ＺＫＰ保有者＝ＭＰＣ参加パーティ９の場合＞
検証者８の検証者端末１６は、ＭＰＣ参加パーティ９から証拠（ＺＫＰの出力シェア）を取得する。なお、ＺＫＰの出力シェアが提供されるのは、上述のように検証ロジック式が個別プライバシーのプライバシーポリシーの条件を満たす場合や、検証者８がクレデンシャルにより出力シェアへのアクセスが許可されている場合に限定されてよい。例えば、クレデンシャルによってアクセス制御を行う場合、サービス提供者はクレデンシャルＩＤに対応付けられた情報を検証者に、データ主体の事前・事後の承諾を得たうえで、直接通知する。あるいはデータ主体４はあらかじめ検証者８に対し、クレデンシャルＩＤに対応付けられた情報を提供する。検証者８の検証者端末１６は、通知を受けたクレデンシャルＩＤに対応付けられたクレデンシャルと、検証者ＩＤの認証をもって、証拠（ＺＫＰの出力シェア）と、検証ロジック式、あるいはＴｒｕｓｔｅｄＳｅｔｕｐが用いられる場合はＣＲＳとを入手する。検証者端末１６は出力シェアからＺＫＰ（Ｐｒｏｏｆ）を復元し、復元したＺＫＰに対する検証手続き（Ｖｅｒｉｆｙ）により、検証結果を得る。

＜ＺＫＰ保有者＝データ主体４（のデータ主体端末１２）の場合＞
データ主体４は証拠（ＺＫＰの出力シェア）と署名付き検証ロジック式、あるいはＴｒｕｓｔｅｄＳｅｔｕｐが用いられる場合は署名付きＣＲＳとを検証者８へ提供する。検証者８の検証者端末１６はＣＲＳの真正性を検証する。検証者端末１６は出力シェアからＺＫＰ（Ｐｒｏｏｆ）を復元し、復元したＺＫＰに対する検証手続き（Ｖｅｒｉｆｙ）により、検証結果を得る。

図２０は、ＭＰＣ－ＺＫＰシステム２における命題関数による証明（証言）のシーケンスの流れを示すチャートである。図２０のシーケンスは上述のＭＰＣによる命題関数証言モードに対応する。図２０のシーケンスはステップＳ８２０、Ｓ８２２、Ｓ８２４、Ｓ８２６を含み、そのうちステップＳ８２０、Ｓ８２２はサービス提供者７または検証者８による検証ロジックの定義の流れを示し、ステップＳ８２４、Ｓ８２６はＭＰＣの流れを示す。

本シーケンスではまず、証明したい（検証したい）内容を規定し（ステップＳ８２０）、その検証ロジック式を生成する（ステップＳ８２２）。検証ロジックは検証者８が用意するか、あるいは「よく検証される内容」として、サービス提供者７が事前に用意してもよい。検証ロジックには計算式（処理内容）と、入力データの形式（ｊｓｏｎ、ｙａｍｌ、ｔｏｍｌなど）が含まれる。検証ロジックには、命題関数用とＺＫＰ用が存在する。本シーケンスでは命題関数用を想定する。検証ロジックを受け取った管理サーバ２２は検証ロジックＩＤを発行する。

ステップＳ８２４において、証明に必要なデータを取得する。
＜ＭＰＣで計算する場合、かつデータの第三者提供を前提としている場合＞
検証に必要なデータが未登録の場合、データ生成者端末２４は検証ロジックをサービス提供者７の管理サーバ２２より取得し、入力データのフォーマットに従い、要求されたデータの署名付きシェア、すなわち平文の秘密分散（シェア化）した値と、平文への署名のシェアと、各シェアへの署名（署名付きシェア）とを用意する。データ生成者端末２４は、各シェアを１つずつＭＰＣ参加パーティ９へ配布する。

＜ＭＰＣで計算する場合、かつデータの第三者提供を前提としていない場合＞
検証に必要なデータが未登録の場合、データ主体端末１２は検証ロジック式をサービス提供者７の管理サーバ２２より取得し、入力データのフォーマットに従い、証明に必要なデータの平文と平文への署名をデータ生成者端末２４に要求する。

ステップＳ８２６において、証明者は命題関数を計算し、検証者８は結果を検証する。
ＭＰＣ参加パーティ９は、目的の検証ロジックＩＤに対応付けられた検証ロジック式に基づいてＭＰＣを行い、検証結果のシェアを得る。なお、ＭＰＣを計算するのは、上述のように検証ロジック式が個別プライバシーのプライバシーポリシーの条件を満たす場合に限定されてよい。或いは、管理サーバ２２は、検証結果のシェア取得の認証のためのクレデンシャルを発行し、クレデンシャルＩＤを発行した上で対応付けるようにしてもよい。管理サーバ２２は、このクレデンシャルＩＤに対応付けられた情報をデータ主体４に通知し、データ主体４が証明したいときにそれらの情報を検証者８に知らせることで、本人の属性に対応付けられた証明を検証者８に提供可能にすることもできる。

クレデンシャルを用いる場合、サービス提供者はクレデンシャルＩＤに対応付けられた情報を検証者に、データ主体の事前・事後の承諾を得たうえで、直接通知する。あるいはデータ主体４はあらかじめ検証者８に対し、クレデンシャルＩＤに対応付けられた情報を提供する。検証者８はクレデンシャルを用いて検証結果（Ｔｕｒｅ／Ｆａｌｓｅ）を得る。

図１８及び図２０に示したフローチャートでは、ＭＰＣ－ＺＫＰシステム全体における、ＭＰＣによるゼロ知識証明モードにおける動作と、ＭＰＣによる命題関数証言モードにおける動作とを別々に説明した。しかし、上述のように、ＭＰＣによるゼロ知識証明モードは、ＭＰＣ参加パーティ９において、ＭＰＣによる命題関数証言モードと適宜組み合わせて実行されることにより、ＭＰＣによる命題関数証言モードによる偽証を抑制することができる。また、ＭＰＣ参加パーティ９が命題関数或いはＺＫＰの計算を実行する際に、プライバシーポリシーを考慮することにより、漏れ出すプライバシーを適正に制御することが可能になる。以下、これらの機能を実現するＭＰＣ参加パーティ９における動作例について、図２５を参照して説明する。なお、ＭＰＣ参加パーティ９における動作は、ＭＰＣ参加パーティ９のメモリに格納されたプログラムを、プロセッサが実行することにより実現される。
Ｓ２５０１において、ＭＰＣ参加パーティ９のプロセッサは、データ主体端末１２又はデータ生成者端末２４から、署名付きウィットネスのシェアを取得したうえで、データ生成者端末２４の公開鍵を用いて、取得した署名付きウィットネスのシェアが部分的に改ざんされていないことを検証する。
Ｓ２５０２において、ＭＰＣ参加パーティ９のプロセッサは、証言要求と証拠要求のいずれかである検証要求を検証者端末１６から受け付ける。このとき、検証要求に係るデータ主体ＩＤ対応値と検証ロジックＩＤを特定する。そして、Ｓ２５０３において、当該検証ロジックＩＤに基づいて、（管理サーバ２２から）検証ロジック式を取得する。
Ｓ２５０４において、ＭＰＣ参加パーティ９のプロセッサは、検証ロジック式の実行がプライバシーポリシーの保護範囲内かを判定する。具体的には、上述した検証履歴ＤＢと個別ポリシーＤＢのデータのうち、検証要求に係るデータ主体ＩＤ対応値に関連付けられた比較結果やデータクラスの保護範囲の情報を取得して、今回の検証ロジック式の実行により、プライバシーポリシーとして設定されるデータクラスの保護範囲以内までデータの絞り込みが行われないかを判定する。Ｓ２５０５において、プロセッサは、検証ロジック式が保護範囲内であると判定した場合には、Ｓ２５０６に進み、そうでない場合には本処理を終了する。
Ｓ２５０６において、ＭＰＣ参加パーティ９のプロセッサは、要求された検証要求が証拠要求（すなわちＺＫＰの実行要求）であるかを判定する。例えば、プロセッサは、検証者端末１６から受け付けた検証要求が証拠要求なのか証言要求なのかに応じて本ステップの判定を行う。プロセッサは、検証要求が証拠要求である場合にはＳ２５０８でＺＫＰを実行し、検証要求が証言要求である場合にはＳ２５０７で命題関数を実行する。
Ｓ２５０９において、ＭＰＣ参加パーティ９のプロセッサは、命題関数又はＺＫＰの処理結果として得られる出力シェアを検証者端末１６に提供する。検証者端末１６では各ＭＰＣ参加パーティ９から送信される出力シェアをＲｅｃｏｎｓｔｒｕｃｔして結果を復元する。ＭＰＣ参加パーティ９のプロセッサは、出力シェアを検証者端末１６に提供すると、本一連の動作を終了する。
上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。

本実施の形態に係るＭＰＣ－ＺＫＰシステム２によると、ＭＰＣとＺＫＰとを組み合わせて用いることで、プライバシー保護を伴う委託属性証明器を実現することができる。特に、データ主体本人が不在の場合も、データ主体の生データ（プライバシー情報）に基づいた証明を、生データを明かさずに実行することができる。

ユーザ自身の端末上で計算した証明は説得力に欠ける場合がある。このような場合、本実施の形態に係るＭＰＣ－ＺＫＰシステム２によると、ＭＰＣ－ＺＫＰシステム２がデータ生成者（例：病院、役所など）の公開鍵でデータの真正性を検証した上で証明するので、第三者による証言に相当するため説得力が高まる。

本実施の形態に係るＭＰＣ－ＺＫＰシステム２では、データ生成者６がデータを作成し、それにデジタル署名を付す。データ生成者６は複数いる場合がある。例えば、（１）ＰＣＲ検査をした病院と、（２）位置情報サービスのサービス提供者と、がいずれもデータ生成者６である場合を考える。検査結果と、位置情報（クラスタ発生場所に近づいていないか？）の両方をＺＫＰで検証して、いずれもＦａｌｓｅ（陰性であり、クラスタ場所にも近づいていない）だったことによって、はじめて「この人は入国してＯＫだ」と国境・県境等の管理局が認める。ＭＰＣ－ＺＫＰシステム２では、異なる性質の情報（検査結果、位置情報）に対して、それぞれの情報（データ）を作ったデータ生成者６自身が、個別に署名をすることで、ＭＰＣ－ＺＫＰシステム２による証明の信頼性を高めることができる。

上述したように証言方法は２種あってよい。
１．ＭＰＣによる命題関数の結果のみ提供（ＺＫＰは作らない）
真偽値を返す関数（命題関数）の実行リクエストに対して、ＴｒｕｅあるいはＦａｌｓｅを返す。データ主体から実行許可を受けている関数のみ実行可能とする。この場合、計算過程が正しく踏まれたことの証拠は作られないので根拠としては弱い。ＭＰＣによりＺＫＰを行う計算コストの大きさや、通信帯域、記録領域の不足が懸念される場合、ＭＰＣによる命題関数によりＴｒｕｅ／Ｆａｌｓｅのみを予備的に審査するのに適する。この結果が疑わしい場合や、抜き打ち的（無作為）にＺＫＰを要求することで、証明者（サービス提供者、ＭＰＣ計算者）にとっては、命題関数とＺＫＰの結論に矛盾が発生する可能性を鑑みると、命題関数へのリクエストに対する結論を安易に捏造することは困難になる。
２．ＭＰＣで計算したＺＫＰを提供
結論を導くまでの計算過程の妥当性を証明内容に含められるので根拠としては強い。１．で挙げた命題関数の証言において捏造が起こることへの抑止力になる。またＺＫＰの証明内容に署名への認証成否など諸条件を付与できる。

以上、実施の形態に係るＭＰＣ－ＺＫＰシステム２の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解される。

実施の形態では、データ主体４とデータ生成者６とが別である場合について説明したが、これに限られない。例えば、データ生成者端末２４の機能は、データ主体端末１２のＴＥＥ（ＴｒｕｓｔｅｄＥｘｅｃｕｔｉｏｎＥｎｖｉｒｏｎｍｅｎｔ）で動作するアプリケーションによって実現されてもよい。

データ生成者端末２４の機能をデータ主体端末１２のローカルで動作するアプリケーションで実現する場合、通常のアプリケーションでは、データ主体４がデータを簡単に改ざんできてしまう。そのため、ここではＴＥＥ上で動作するアプリケーションを用いる。

通常のアプリケーションは、ＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）によりプログラムやデータへアクセスされる可能性がある。この場合、プログラムやデータに改ざんが容易に起きる可能性がある。一方、ＴＥＥで動作するアプリケーションは、プログラムやデータの改ざんが非常に困難となっている。困難である根拠は、ＴＥＥはＯＳからハードウェア的に隔離された環境で、そこで動作するアプリケーションでは、プログラムやデータの改ざんが起こりにくくなるからである。すなわち、コードとデータの完全性が守られる。データ主体端末１２がローカル端末である以上、完璧な防御ではないが、サイドチャネル攻撃が成功しない限りは安全である。

このＴＥＥ上で動作するアプリケーションが、ＴＥＥから操作可能な外部デバイス（ペリフェラル）、すなわち無線インターフェースで繋がれたセンサ（ＧＰＳ受信機、体温計など）の情報を取得し、これを整形、解析、解釈する。

その取得・計算結果をＴＥＥ上のアプリケーションがシェア化、署名し、ＭＰＣ参加パーティ９へ配布する。シェア配布直前に、アプリケーションからユーザに、プライバシーポリシーを添えて、「配布して良いか？」の確認を行ってもよい。こうすれば「データ生成者６」を「データ主体端末１２上のアプリケーション」に置き換えることができる。

２ＭＰＣ－ＺＫＰシステム、４データ主体、６データ生成者、８検証者、１０ＭＰＣ参加パーティ群、１２データ主体端末、１４データ生成者ＤＢ。

Claims

秘密分散ベースのマルチパーティ計算でゼロ知識証明を行うためのプロトコルが実装された、マルチパーティ計算に参加する複数の装置のうちのひとつの装置であって、
証明したい事項に係るデータのシェアを取得する取得手段と、
取得されたシェアを入力としてプロトコルにしたがい計算を行った結果得られた出力シェアを出力する出力手段と、を備え、
マルチパーティ計算に参加する複数の装置から集められた出力シェアにより、ゼロ知識証明における検証が可能である装置。
取得されたシェアに付随するデジタル署名を用いて、当該シェアの元のデータが改ざんされていないことを検証する手段をさらに備える請求項１に記載の装置。
ゼロ知識証明は検証ロジック式、またはコモンリファレンスストリング（ＣｏｍｍｏｎＲｅｆｅｒｅｎｃｅＳｔｒｉｎｇ、ＣＲＳ）を用いる種類のものである請求項１または２に記載の装置。
ＴｒｕｓｔｅｄＳｅｔｕｐする場合のＣＲＳはマルチパーティ計算に参加する複数の装置、または検証者の端末が協働することにより生成される請求項３に記載の装置。
前記ゼロ知識証明における検証は、検証者による無作為あるいは任意の要求に応じて実行される請求項１から４のいずれか一項に記載の装置。
前記ゼロ知識証明における検証は、マルチパーティ計算に参加する複数の装置から集められた出力シェアにより命題関数の計算による検証が行われた後に、実行される請求項５に記載の装置。
ゼロ知識証明を行うシステムであって、
プライバシーポリシーを保持するポリシー保持手段と、
検証の履歴を保持する履歴保持手段と、
検証者から検証要求を取得する手段と、
取得された検証要求の内容と、前記ポリシー保持手段に保持されるプライバシーポリシーと、前記履歴保持手段に保持される検証の履歴と、に基づいて、検証要求を拒否するか否かを判定する手段と、を備えるシステム。