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

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

Info

Publication number
JP2022158677A
JP2022158677A JP2021063738A JP2021063738A JP2022158677A JP 2022158677 A JP2022158677 A JP 2022158677A JP 2021063738 A JP2021063738 A JP 2021063738A JP 2021063738 A JP2021063738 A JP 2021063738A JP 2022158677 A JP2022158677 A JP 2022158677A
Authority
JP
Japan
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
JP2021063738A
Other languages
English (en)
Inventor
将司 川口
Shoji Kawaguchi
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
Priority to JP2021063738A priority Critical patent/JP2022158677A/ja
Priority to CN202111030539.8A priority patent/CN115174087A/zh
Priority to US17/466,588 priority patent/US20220329432A1/en
Priority to EP21195253.6A priority patent/EP4068678A1/en
Priority to AU2021229174A priority patent/AU2021229174A1/en
Priority to IL286318A priority patent/IL286318A/en
Publication of JP2022158677A publication Critical patent/JP2022158677A/ja
Priority to AU2023226639A priority patent/AU2023226639A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3218Cryptographic 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting 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/6245Protecting personal data, e.g. for financial or medical purposes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085Secret sharing or secret splitting, e.g. threshold schemes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46Secure 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)
  • Storage Device Security (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)

Abstract

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

Description

本発明は、マルチパーティ計算で行われるゼロ知識証明のための装置およびシステムに関する。
近年、ゼロ知識証明に係る技術が知られている。ゼロ知識証明(Zero-Knowledge Proof、ZKP)は、自分が持っている知識(秘密)を相手に開示することなく、自分が知識(秘密)を知っていること、あるいはその知識(秘密)がある性質を備えること、条件を満たすことを相手に証明するための技術である。ただし、ZKPは以下3つの性質を備えていなければならない:完全性(Compeleteness、証明者が証明を試みる命題が真であれば検証者を必ず説得できる性質)、健全性(Soundness、証明者が証明を試みる命題が偽である場合は高い確率で説得が失敗に終わる性質)、ゼロ知識性(Zero-Knowledge、証明者がある命題を証明した結果から検証者が得られる知識は、その命題が真であること以外に皆無である性質。つまり検証者が知識を持たなくても、証明の妥当性をシミュレーションすることが可能である性質)。ZKPに関する用語、各手法の特徴に関する標準化が推進されており、当文書も原則これに従う(非特許文献1参照)。
一方、マルチパーティ計算(Multi-Party Computation、MPC)は、入力値を秘匿したまま計算結果を導くことのできる暗号技術である。特にk-out-of-n閾値型秘密分散法(n≧k≧2)により、秘密にあたる入力値を複数のシェアに秘密分散させたまま、各シェアを預かるパーティが所定の手続き(プロトコル)をこなし、計算結果を導く計算手法を、秘密分散ベースのマルチパーティ計算と呼ぶ。この計算手法はFunctional Completenessを備えることができ、2パーティ計算による各種プロトコルの実装例は非特許文献2に記載される。
社会基盤のデジタル化が叫ばれ、プライバシー保護が喫緊の課題となる昨今、ZKPとMPCは有効な対策手段として注目を集めている。
ZKProof Community Reference, Version 0.2, 2019年12月31日、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
個人または組織に、外部の検証者に対する証明が要求されるケースは多数ある。現代の証明行為の多くは、第三者機関が発行した証明書、あるいは当人(当組織)が備える情報を、検証者に公開することで果たされる。
しかし証明行為の過程で、検証者に与える情報には、量と質ともに不必要なものが含まれることが多々ある。たとえば酒類を購入する際に「当人が成人であること」を証明する手段は、証明者である当人の免許証を提示することで、検証者である酒類の売り手へ生年月日を通知することにより、果たされるかもしれない。この例では「当人が成年であること」の事実のほか、量(実年齢)と質(住所など)ともに余計な情報が含まれる。
すなわち、上述した不必要なプライバシー情報(証明を要求される命題の結論以上の情報)の漏洩を制限し、また利便性を損なうこともなく、検証者に対する十分な説得力を備えた証明手段が望まれつつある。
上述の問題は、既知のゼロ知識証明により条件付きで解消可能である。ただし、ゼロ知識証明でProveを計算する者は、プライバシー情報(平文の知識)を取り扱い、計算することが求められる。そのため証明行為を他者へ委託する場合、プライバシー情報を委託先へ明かすことが求められる。典型例として、2人のプライバシー情報に基づく証明を行う場合、2人のうちいずれか、あるいは第三者に証明行為を委託することとなり、少なくとも2人のうちいずれかのプライバシー情報が、本人以外の誰かに知られることが前提となる。不必要なプライバシー情報を漏らしたくない者が、そのプライバシー情報に基づいた証明を要求された際に問題となる。
本発明は上述した課題を鑑みてなされたものである。その目的は、よりユーザ利便性の高い証明サービスを実現するか、または、プライバシー情報の漏洩リスクを小さくすることができる技術を実現することである。
本発明のある態様は、装置に関する。この装置は、秘密分散ベースのマルチパーティ計算で命題関数とゼロ知識証明とを行うためのプロトコルが実装された、マルチパーティ計算に参加する複数の装置のうちのひとつの装置であって、証明したい事項に係るデータのシェアを取得する取得手段と、取得されたシェアを入力としてプロトコルにしたがい計算を行った結果得られた出力シェアを出力する出力手段と、を備える。マルチパーティ計算に参加する複数の装置から集められた出力シェアにより、命題関数における検証、またはゼロ知識証明における検証が可能である。
本発明の別の態様は、システムである。このシステムは、ゼロ知識証明を行うシステムであって、プライバシーポリシーを保持するポリシー保持手段と、検証の履歴を保持する履歴保持手段と、検証者から検証要求を取得する手段と、取得された検証要求の内容と、前記ポリシー保持手段に保持されるプライバシーポリシーと、前記履歴保持手段に保持される検証の履歴と、に基づいて、検証要求を拒否するか否かを判定する手段と、を備える。
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
本発明によれば、よりユーザ利便性の高い証明サービスを実現するか、または、プライバシー情報の漏洩リスクを小さくすることができる。
実施の形態に係るMPC-ZKPシステムの構成を示す模式図である。 図1のMPC-ZKPシステムを利用するメリットである秘匿性を説明するための模式図である。 図1のMPC-ZKPシステムを利用するメリットであるロジックの透明性を説明するための模式図である。 MPC-ZKPシステムで実装される証明モードの特徴を表形式で示す図である。 図1のMPC参加パーティのMPC参加パーティ(MPC参加サーバともいう)のハードウエア構成図である。 図1のMPC参加パーティのMPC参加パーティの機能構成例を示すブロック図である。 図1のMPC参加パーティ群を管理するためにサービス提供者が運用する管理サーバの機能構成例を示すブロック図である。 図7の検証ロジック式DBの一例を示すデータ構造図である。 図7のデータ主体DBの一例を示すデータ構造図である。 図7のデータクラスDBの一例を示すデータ構造図である。 図7の検証者DBの一例を示すデータ構造図である。 図7の個別ポリシーDBの一例を示すデータ構造図である。 図7の検証履歴DBの一例を示すデータ構造図である。 図1のデータ主体端末の機能構成例を示すブロック図である。 データ生成者の端末であるデータ生成者端末の機能構成例を示すブロック図である。 図1の検証者端末の機能構成例を示すブロック図である。 検証者端末16の検証ロジック式DBの一例を示すデータ構造図である。 MPC-ZKPシステムにおける証明のシーケンスの流れを示すチャートである。 データ生成者が第三者提供について合意取得済みの場合のMPC-ZKPシステムの構成を示す模式図である。 MPC-ZKPシステムにおける命題関数による証明(証言)のシーケンスの流れを示すチャートである。 データ主体のデータ主体端末のディスプレイに表示される出力プライバシー漏洩通知画面の代表画面図である。 MPC参加パーティ9における入力値DBの一例を示すデータ構造図である。 MPC参加パーティ9における追加情報DBの一例を示すデータ構造図である。 MPC参加パーティ9のシェア保持部におけるシェアDBの一例を示すデータ構造図である。 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参加パーティに委託し、一本化できる。結果として「検証者:証明者」の組み合わせは「多:1」の関係に変換される。
8.2人以上のデータ主体のWitnessを用いた証明
平文のWitnessを用いる従来のZKPでは、複数のデータ主体の秘密(Witness)に基づく証明を行いたいとき、以下いずれかの方策を採る必要があった。
(1) 各データ主体のWitnessを信頼できる第三者の環境に集め、そこでZKPを計算してもらう。この場合、信頼できる第三者の環境(TTP、Trusted Third Party)からのプライバシー保護はあきらめる必要がある。
(2) 個々のデータ主体が自身のWitnessのみに基づく証明を計算する。ただしこの場合は2者の情報を合わせた(例:合計)情報に基づく証明が困難になり、また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つの手続きに分類可能である。本実施の形態では、このうちのProveをMPCで実施する。すなわちWitnessはk-out-of-n閾値型秘密分散法(n≧k≧2)により秘密分散され、非公開値とされた上で、Witnessを入力値に取るProveの手続きは秘密分散ベースのマルチパーティ計算(MPC)により行われる。なおセキュリティパラメータlに基づく、素数q、生成元g、i ∈ {0,1,…,n-1}、nはMPC参加パーティの数、とし、これらを公開値とする。またWitnessはwで表され、wがk-out-of-n閾値型秘密分散法により秘密分散されたシェアは{w, w, … wn-1}で表される。wはMPC参加パーティPへ配布されているものとする。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はProving Key、vkはVerification Keyである(以下、CRSを追加情報と記載することもある)。
2.MPCによるProve
π <- Prove(CRS, x, w
なおxはInstanceである。
MPC参加パーティPはπを検証者へ提供する。
3.検証者によるVerify
π <- Reconstruct(π, π, …, π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を秘密分散したシェアを{w、w、…、wn-1}とする。同様にwsを秘密分散したシェアを{ws、ws、…、wsn-1}とする。(w、ws)の組を署名付きウィットネスのシェアと呼ぶ。なおi∈{0,1,…,n}、nはMPC参加パーティ群10のパーティ数である。
(6) データ主体端末12は、データ主体4が検証ロジックIDに紐づく処理内容(=検証ロジック式、プライバシーポリシー)に合意したことを示す操作を受け付けると、、MPC参加パーティ群10の各MPC参加パーティPへ、署名付きウィットネスのシェア(w、ws)を送信する。
(7) MPC参加パーティ群10は、各MPC参加パーティPにおける署名付きウィットネスのシェア(w、ws)とPKI等から取得したデータ生成者6の公開鍵pkにより、検証ロジックIDに紐づく検証ロジック式に基づき、MPCによる証言(命題関数)の計算を行う。各MPC参加パーティPは、証言のシェアτを得る。
(8) 検証者8はデータ主体4からデータ主体IDの通知を受ける。検証者8の検証者端末16は、MPC参加パーティ群10の各MPC参加パーティPから認証を受けて、MPC参加パーティ群10から検証ロジックIDとデータ主体IDの両方に紐づく証言の出力シェア{τ、τ、…、τ}を取得(MPC参加パーティPからτを取得)し、Reconstruct(すなわち秘密分散した値を集めて元の値を復元する)して証言τを得る。検証者8は証言τを不服とする場合、その旨を検証者端末16に入力する。検証者端末16は、証言に対する不服を表す入力を受け付けると、MPC参加パーティ群10に対し、ゼロ知識証明による証拠(Proof)を要求する。あるいは検証者8がτを不服としない場合も、検証者端末16は無作為に、MPC参加パーティ群10に対してゼロ知識証明を要求することができる。
(9) ゼロ知識証明による証拠(Proof、すなわち上記Prove手続の出力)の要求を受け付けた場合、MPC参加パーティ群10の各MPC参加パーティPは、検証ロジックIDに紐づく検証ロジック式に基づき、MPCによるZKPの計算を行う。検証ロジックIDに紐づく検証ロジック式に登録されたZKPスキーム(ZKPの種類)が、例えばNIZK(Non Intaractive ZK)である場合、MPC参加パーティPは、証明結果である証拠(Proof)の出力シェア{π、π、…、πn-1}を得る。一方、検証ロジックIDに紐づく検証ロジック式に登録されたZKPスキームが、例えばInteractive ZKである場合、MPC参加パーティPは(1)検証者8の検証者端末16へコミットメントを送付し、(2)検証者8の検証者端末16はMPC参加パーティ群10の各MPC参加パーティPへチャレンジを送付した後に、(3)MPC参加パーティPは、証明結果である証拠(Proof)の出力シェア{π、π、…、πn-1}を得る。ここで、(2)と(3)は繰り返されることがある(Soundness Amplification)。
(10) 検証者8の検証者端末16は、クレデンシャル等によりMPC参加パーティ群10から認証を受けて、MPC参加パーティ群10から検証ロジックIDとデータ主体IDの両方に紐づく証拠(Proof)の出力シェア{π、π、…、πn-1}を取得(MPC参加パーティPからπを取得)し、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で同様のことを実施するためには、平文を同じ計算機へ配置して計算する必要があった。これでは2人のうち少なくとも一方のプライバシーが本人以外の誰かに漏れてしまう。この点についても、図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によりシェア化(w、ws)され、データ主体端末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は、検証ロジック式DB166へ検証ロジック式と検証ロジックIDを紐づけて登録する。
検証ロジック式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の出力シェア(π))を要求する。例えば、証拠要求部168は、検証者8による操作による要求、または証拠要求部168における所定の判定に基づいて、証拠要求を生成し、MPC参加パーティ9に送信する。証拠要求部168は、所定の判定を以下のように行なってもよい。例えば、証拠要求部168は、命題関数の出力シェアを取得した直後に、ローカルで生成した乱数、又は、シェア取得時点以降の(所定のブロックチェーンアルゴリズムを用いた)パブリックチェーンにおいて、あるブロックハイトにおけるトランザクションハッシュを乱数として捉え、これが所定の閾値を超えたかを判定する。証拠要求部168は、上記の乱数又はトランザクションハッシュが所定の閾値を超えた場合に、(検証者8による操作による要求を待つこと無く)証拠要求を生成する。なお、本実施形態では、追加情報の要求および証拠要求をMPC参加パーティ9に送信する場合を例に説明しているが、証拠要求を管理サーバ22に送信し、管理サーバ22から各MPC参加パーティ9に追加情報や証拠を要求するようにしてもよい。
検証部170は、MPC参加パーティ9から出力される証言(命題関数)の出力シェアを取得して、Reconstructし、証言τを取得する。
また、検証部170は、証拠を要求した場合、MPC参加パーティ9から、証拠(ZKP)の出力シェア(π)と、検証ロジック式に紐づく追加情報とを取得する。検証部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を取得するための検証者登録部を更に有してもよい。例えば、検証者IDをデータ主体4に提供することにより、データ主体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対応値は、データクラスの対象を代入により指定可能にする仕組みであり、例えば、データ主体ID対応値を[DS003,DS004]の配列形式で指定すると、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(すなわちP)は、入力データ取得部102と、インスタンス保持部103と、計算部104と、データ提供部106と、シェア削除部108と、シェア保持部109と、を備える。
入力データ取得部102は、証明したい事項に係るデータを取得する。データには2種類あり、Instanceと、署名付きウィットネスのシェア(Witnessのシェア)である。シェア取得部102は、データ主体端末12またはデータ生成者端末24からネットワークを介して、Instanceと、秘密分散された署名付きウィットネスのシェア(w、ws)を取得する。なお各種シェアは{P、w、ws、v、τ、π|i∈{0,1,…、n-1}}で表現され、nはMPC参加パーティ群10におけるMPC参加パーティ9の数、すなわちMPCに参加するパーティ数であり、iは個々のMPC参加パーティ9を一意にするものとする(P)。なお、入力データ取得部102は、Instanceが参照で渡される場合には、その実体(例えばデータ生成者6の公開鍵)をネットワークを介して更に取得する。
入力データ取得部102は、MPC参加パーティ群10のMPC参加パーティ9同士で通信し、署名付きウィットネスのシェア(Witnessのシェア)を入力としたデジタル署名の完全性の検証アルゴリズムをMPC処理する。そして、結果として得られた出力シェア(v)をMPC参加パーティ9同士で共有し、検証の結果(v)をReconstruct(復元)する。入力データ取得部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は、データ主体ID対応値に関するどのようなデータが命題計算に用いられたのかを管理サーバ22に管理させ、必要なプライバシーコントロールを実現する。
(2)次に、検証者端末16からの証拠要求を受けつけてZKPを計算する場合について説明する。この場合、計算部104は、事前に、検証者端末16からデータ主体ID対応値と検証ロジックIDとに関する追加情報の要求を受け付けて、データ主体ID対応値と検証ロジックIDとに紐づく追加情報を取得する。計算部104は、取得した追加情報或いは計算した追加情報を検証者端末16へ送信する。
検証者端末16は、追加情報を受信したことに応じて取得に応じて証拠要求を送信するため、計算部104は、検証者端末16から証拠要求を受け付ける。なお、検証者端末16から要求されるZKPのZKPスキームがIntaractive 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であるπのシェア、π)をシェア保持部109に格納する。
なお、上述の追加情報は、例えば、図23に示すデータ形式で、不図示の追加情報DBに格納されてもよいし、所定期間の間、メモリに格納されていてもよい。追加情報のデータは、例えば、図23に示すように、検証ロジックIDと、データ主体ID対応値とに関連付けられてよい。追加情報には、CRSやコミットメントが含まれることがある。追加情報は、ZKPスキームに応じて異なり、ZKPスキームがSchnorr’s Protocol、Sigma ProtocolなどのInteractive ZKに属す場合、追加情報は例えばコミットメントを含む。ZKPスキームが、zk-SNARKsやGroth Sahaiなどの、特定パーティにTrustを求めるNIZK(Non Intaractive ZK)に属す場合、追加情報は例えばCRS(Common Reference String)を含む。また、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が検証ロジックIDと検証ロジック式をMPC参加パーティ9に提供するために、検証ロジックIDと検証ロジック式にアクセスした場合、検証者端末16に検証ロジックIDと検証ロジック式を提供する。或いは、検証者端末16から、MPC参加パーティ9に検証ロジックIDと検証ロジック式を提供するよう要求があった場合に、検証ロジックIDと検証ロジック式をMPC参加パーティに提供するようにしてもよい。
また、管理情報制御部110は、必要に応じて又はデータ主体端末12からの要求に応じて、検証ロジックIDと検証ロジック式とをデータ主体端末12へ送信する。
(5)個別ポリシーの登録制御
データ主体端末12から、検証者IDに対するプライバシーポリシーの登録要求を受けたことに応じて、管理情報制御部110は、当該プライバシーポリシーを個別ポリシー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は、検証ロジック式がデプロイされたとき、その検証ロジック式に対応するZKPをMPCで計算するための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により直接的には元のデータが検証者に知られることはない。しかし、(個別ポリシーの登録制御において示したように)検証者による同一データクラスのデータに対する検証に制限がない場合、検証を繰り返すことで結果的に元のデータが漏れる可能性がある。例えば、選択平文への対処が問題となることがあり、特に取り得る値の範囲が狭いクラスを使った計算は問題化しやすい。
例えば、年齢について、
●50歳以上ですか?→False
●25歳以上ですか?→True
●37歳以上ですか?→False
●31歳以上ですか?→True
●34歳以上ですか?→True
●35歳以上ですか?→False
のように検証を繰り返すことで、それぞれの検証結果からは正確な年齢は分からないものの、複数の検証結果を統合することで、実年齢の取りうる範囲を絞り込むことができたり、データ主体が34歳であることが特定されてしまう。
本実施の形態に係る出力プライバシーの保護では、MPC-ZKPでは守り切れないプライバシー(出力プライバシー)の保護を最大化するため、サーキットブレーカーの役割をMPC参加パーティ9またはサービス提供者7が担う。検証者8がリクエストしてきた検証ロジックにより、プライバシーが著しく危殆化する命題関数又はZKPの計算は、MPC参加パーティ9またはサービス提供者7が拒否する。その意味でMPC参加パーティ9またはサービス提供者7は出力プライバシーの保護におけるサーキットブレーカーの役割を果たす。なお、危殆化の基準はサービスの性質、消費者との合意により決定されてもよい。
管理サーバ22により実現される出力プライバシーの保護機能は、個別ポリシーDB128によってデータ主体4が検証者8に知られてよいプライバシーの範疇を決定づけ、判定部116によって順序尺度以上のデータについて、データ主体4を出力プライバシーへの脅威から保護するものである。判定部116は、検証要求取得部114によって取得された検証要求の内容と、個別ポリシーDB128に保持されるプライバシーポリシーと、検証履歴DB142に保持される検証の履歴と、に基づいて、検証要求を拒否するか否かを判定する。
より具体的には、プライバシーポリシーに反する命題関数又はZKPが検証者8によって要求された場合、判定部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は、検証要求を承認した場合、検証者DB124に保持される対応する出力シェアを検証者端末16に提供する。
図21は、データ主体4のデータ主体端末12のディスプレイに表示される出力プライバシー漏洩通知画面900の代表画面図である。出力プライバシー漏洩通知画面900は、検証履歴DB142を参照することで生成され、命題関数或いはZKPにより漏れたプライバシー範囲をデータ主体4に提示する。図21に示す例では、年齢のうち検証の判断に用いられた範囲が斜線で示されている。なお、図21では一次元的表示を採用したが、ベン図などの二次元的表示を採用してもよい。
図14は、図1のデータ主体端末12の機能構成例を示すブロック図である。データ主体端末12は、管理情報要求部144と、データ取得部146と、データ提供部148と、個別ポリシー部150と、データ削除要求部145と、を備える。
管理情報要求部144は、サービス提供者7の管理サーバ22に対して、管理情報(特に検証ロジック式)を要求する。管理情報要求部144は、検証ロジックIDに対応付けられた管理情報を取得して、ディスプレイに表示させる。データ主体4は、検証者8の要求する検証ロジック式を閲覧、確認することができ、データ生成者6に対して必要なデータの生成(例えば病院の診察を受けるなど)を依頼することができる。
データ取得部146は、(データ生成者6或いはデータ生成者端末24により)データ生成者6のデータ生成者DB14に署名付きウィットネス(w、ws)が格納されると、当該データ生成者DB14から、署名付きウィットネスを取得し、キャッシュ保持部152に登録する。また、データ取得部146は、外部から必要なインスタンス(例:データ生成者6の公開鍵)を取得して、キャッシュ保持部152に登録する。
データ提供部148は、キャッシュ保持部152に格納されている署名付きウィットネス(w、ws)をシェアにして、各署名付きウィットネスのシェア(w、ws)(i=0~MPC参加パーティ数-1)を、MPC参加パーティ群10の各MPC参加パーティ9に提供する(すなわち秘密分散させる)。データ提供部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からの要求に応じて、データ主体4のデータおよび対応する署名付きシェアをデータ主体端末12に提供する。データ提供部160は、データ主体4から事前に合意があった場合、生成されたデータを他者・他社に提供することができる。
以上の構成によるMPC-ZKPシステム2の動作を説明する。
図18は、MPC-ZKPシステム2における証明のシーケンスの流れを示すチャートである。図18はZKPのアルゴリズムとしてzk-SNARKsを採用する場合を説明する。図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スキームがTrusted Setupを求める場合、MPC参加パーティ9(および検証者8)が協働してSetupフェーズを行う。
ただし、zk‐STARKsなど、ハッシュ関数の安全性(ランダムオラクル仮定)に依拠したスキームを採用する場合、Trusted Setupは不要である。
ステップS808において、証明に必要なデータを取得する。
<MPCでZKPを計算する場合、かつデータの第三者提供を前提としている場合>
検証に必要な署名付きシェアが未登録の場合、MPC参加パーティ9は、データ主体4またはサービス提供者7の依頼により、データ生成者6のデータ生成者端末24へ署名付きシェアを要求する。あるいはまた、データ生成者6のデータ生成者端末24から自動的に以下のデータ提供を進めてもよい。
データ生成者6のデータ生成者端末24は、検証ロジック式をサービス提供者7の管理サーバ22より取得し、入力データのフォーマットに従い、要求されたデータの署名付きシェア、すなわち平文の秘密分散(シェア化)した値と、平文への署名の秘密分散(シェア化)した値と、各シェアへ署名した値と、を用意する。データ生成者端末24は、各署名付きシェアを1つずつMPC参加者9のMPC参加サーバ20へ配布する。
MPC参加パーティ9は、データ生成者6の公開鍵を取得し、それぞれが受け取った署名のシェアと署名付きシェアの完全性を検証する。
<MPCでZKPを計算する場合、かつデータの第三者提供を前提としていない場合>
検証に必要なデータが未登録の場合、データ主体端末12は、検証ロジック式をサービス提供者7の管理サーバ22より取得し、入力データのフォーマットに従い、証明に必要なデータの平文と平文への署名をデータ生成者端末24に要求する。
データ生成者端末24は、要求されたデータの平文と、平文への署名と、を用意する。データ生成者端末24は、これらをデータ主体端末12へ提供する。
データ主体端末12は、データ生成者6の公開鍵を使い、デジタル署名による完全性を検証する。
データ主体端末12は、データ生成者端末24から取得した平文と平文への署名のデータを秘密分散(シェア化)して、署名付きシェア(例えば署名付きウィットネスのシェア)を生成し、各署名付きシェアを1つずつ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に対応付けられた検証ロジック式、あるいはTrusted Setupを用いる場合はCRSに基づきZKPを計算する。なお、ZKPを計算するのは、上述のように検証ロジック式が個別プライバシーのプライバシーポリシーの条件を満たすに場合に限定されてよい。
計算結果のZKPは出力シェアとしてシェア化された状態のままで、各出力シェアはMPC参加パーティ9が保持する。このとき、管理サーバ22はまた、ZKPのシェアである出力シェアの取得に対する認証のためのクレデンシャルを発行し、クレデンシャルIDを発行した上で対応付けるようにしてもよい。この場合、サービス提供者7はこのクレデンシャルIDに対応付けられた情報を検証者に、データ主体の事前・事後の承諾を得たうえで、直接通知する。あるいはクレデンシャルIDに対応付けられた情報をデータ主体4に通知し、データ主体4が証明したい相手(検証者8)のみにクレデンシャルIDに対応付けられた情報を知らせて、本人の属性に対応付けられた証明を提供可能にすることもできる。
このように、クレデンシャルを用いることにより、証明IDに対応付けられたデータ主体4は、ZKPの計算後に、クレデンシャルの情報の登録・削除により、証拠(ZKP)への検証者8のアクセス可否を制御することができる(許可/不許可を判断し、システムに指示できる)。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に対応付けられた情報の登録・削除により、証拠(ZKP)への検証者8のアクセス可否を制御することができる(許可/不許可を判断し、システムに指示できる)。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は、各シェアを1つずつMPC参加パーティ9へ配布する。
MPC参加パーティ9は、データ生成者6の公開鍵を取得し、それぞれが受け取った署名のシェアと署名付きシェアの完全性を検証する。
<MPCで計算する場合、かつデータの第三者提供を前提としていない場合>
検証に必要なデータが未登録の場合、データ主体端末12は検証ロジック式をサービス提供者7の管理サーバ22より取得し、入力データのフォーマットに従い、証明に必要なデータの平文と平文への署名をデータ生成者端末24に要求する。
データ生成者端末24は、要求されたデータの平文と、平文への署名と、を用意する。データ生成者端末24は、これらをデータ主体端末12へ提供する。
データ主体端末12は、データ生成者6の公開鍵を使い、デジタル署名による完全性を検証する。
データ主体端末12は、データ生成者端末24から取得した平文と平文への署名のデータを秘密分散(シェア化)して、署名付きシェア(例えば署名付きウィットネスのシェア)を生成し、各署名付きシェアを1つずつMPC参加パーティ9へ配布する。
MPC参加パーティ9は、データ生成者6の公開鍵を取得し、それぞれが受け取った署名付きシェア(例えば署名付きウィットネスのシェア)の完全性を検証する。
ステップS826において、証明者は命題関数を計算し、検証者8は結果を検証する。
MPC参加パーティ9は、目的の検証ロジックIDに対応付けられた検証ロジック式に基づいてMPCを行い、検証結果のシェアを得る。なお、MPCを計算するのは、上述のように検証ロジック式が個別プライバシーのプライバシーポリシーの条件を満たす場合に限定されてよい。或いは、管理サーバ22は、検証結果のシェア取得の認証のためのクレデンシャルを発行し、クレデンシャルIDを発行した上で対応付けるようにしてもよい。管理サーバ22は、このクレデンシャルIDに対応付けられた情報をデータ主体4に通知し、データ主体4が証明したいときにそれらの情報を検証者8に知らせることで、本人の属性に対応付けられた証明を検証者8に提供可能にすることもできる。
クレデンシャルを用いる場合、サービス提供者はクレデンシャルIDに対応付けられた情報を検証者に、データ主体の事前・事後の承諾を得たうえで、直接通知する。あるいはデータ主体4はあらかじめ検証者8に対し、クレデンシャルIDに対応付けられた情報を提供する。検証者8はクレデンシャルを用いて検証結果(Ture/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のプロセッサは、命題関数又はZKPの処理結果として得られる出力シェアを検証者端末16に提供する。検証者端末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(陰性であり、クラスタ場所にも近づいていない)だったことによって、はじめて「この人は入国してOKだ」と国境・県境等の管理局が認める。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 Execution Environment)で動作するアプリケーションによって実現されてもよい。
データ生成者端末24の機能をデータ主体端末12のローカルで動作するアプリケーションで実現する場合、通常のアプリケーションでは、データ主体4がデータを簡単に改ざんできてしまう。そのため、ここではTEE上で動作するアプリケーションを用いる。
通常のアプリケーションは、OS(Operating System)によりプログラムやデータへアクセスされる可能性がある。この場合、プログラムやデータに改ざんが容易に起きる可能性がある。一方、TEEで動作するアプリケーションは、プログラムやデータの改ざんが非常に困難となっている。困難である根拠は、TEEはOSからハードウェア的に隔離された環境で、そこで動作するアプリケーションでは、プログラムやデータの改ざんが起こりにくくなるからである。すなわち、コードとデータの完全性が守られる。データ主体端末12がローカル端末である以上、完璧な防御ではないが、サイドチャネル攻撃が成功しない限りは安全である。
このTEE上で動作するアプリケーションが、TEEから操作可能な外部デバイス(ペリフェラル)、すなわち無線インターフェースで繋がれたセンサ(GPS受信機、体温計など)の情報を取得し、これを整形、解析、解釈する。
その取得・計算結果をTEE上のアプリケーションがシェア化、署名し、MPC参加パーティ9へ配布する。シェア配布直前に、アプリケーションからユーザに、プライバシーポリシーを添えて、「配布して良いか?」の確認を行ってもよい。こうすれば「データ生成者6」を「データ主体端末12上のアプリケーション」に置き換えることができる。
2 MPC-ZKPシステム、 4 データ主体、 6 データ生成者、 8 検証者、 10 MPC参加パーティ群、 12 データ主体端末、 14 データ生成者DB。

Claims (7)

  1. 秘密分散ベースのマルチパーティ計算でゼロ知識証明を行うためのプロトコルが実装された、マルチパーティ計算に参加する複数の装置のうちのひとつの装置であって、
    証明したい事項に係るデータのシェアを取得する取得手段と、
    取得されたシェアを入力としてプロトコルにしたがい計算を行った結果得られた出力シェアを出力する出力手段と、を備え、
    マルチパーティ計算に参加する複数の装置から集められた出力シェアにより、ゼロ知識証明における検証が可能である装置。
  2. 取得されたシェアに付随するデジタル署名を用いて、当該シェアの元のデータが改ざんされていないことを検証する手段をさらに備える請求項1に記載の装置。
  3. ゼロ知識証明は検証ロジック式、またはコモンリファレンスストリング(Common Reference String、CRS)を用いる種類のものである請求項1または2に記載の装置。
  4. Trusted Setupする場合のCRSはマルチパーティ計算に参加する複数の装置、または検証者の端末が協働することにより生成される請求項3に記載の装置。
  5. 前記ゼロ知識証明における検証は、検証者による無作為あるいは任意の要求に応じて実行される請求項1から4のいずれか一項に記載の装置。
  6. 前記ゼロ知識証明における検証は、マルチパーティ計算に参加する複数の装置から集められた出力シェアにより命題関数の計算による検証が行われた後に、実行される請求項5に記載の装置。
  7. ゼロ知識証明を行うシステムであって、
    プライバシーポリシーを保持するポリシー保持手段と、
    検証の履歴を保持する履歴保持手段と、
    検証者から検証要求を取得する手段と、
    取得された検証要求の内容と、前記ポリシー保持手段に保持されるプライバシーポリシーと、前記履歴保持手段に保持される検証の履歴と、に基づいて、検証要求を拒否するか否かを判定する手段と、を備えるシステム。
JP2021063738A 2021-04-02 2021-04-02 マルチパーティ計算で行われるゼロ知識証明のための装置およびシステム Pending JP2022158677A (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
JP2021063738A JP2022158677A (ja) 2021-04-02 2021-04-02 マルチパーティ計算で行われるゼロ知識証明のための装置およびシステム
CN202111030539.8A CN115174087A (zh) 2021-04-02 2021-09-03 用于用多方计算执行的零知识证明的装置和系统
US17/466,588 US20220329432A1 (en) 2021-04-02 2021-09-03 Apparatus and system for zero-knowledge proof performed in multi-party computation
EP21195253.6A EP4068678A1 (en) 2021-04-02 2021-09-07 Apparatus and system for zero-knowledge proof performed in multi-party computation
AU2021229174A AU2021229174A1 (en) 2021-04-02 2021-09-08 Apparatus and system for zero-knowledge proof performed in multi-party computation
IL286318A IL286318A (en) 2021-04-02 2021-09-12 A mechanism and system without prior knowledge that proves performance in a multi-party calculation
AU2023226639A AU2023226639A1 (en) 2021-04-02 2023-09-05 Apparatus and system for zero-knowledge proof performed in multi-party computation

Applications Claiming Priority (1)

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

Publications (1)

Publication Number Publication Date
JP2022158677A true JP2022158677A (ja) 2022-10-17

Family

ID=77666210

Family Applications (1)

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

Country Status (6)

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

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115499247B (zh) * 2022-11-16 2023-03-28 哈尔滨工业大学(深圳)(哈尔滨工业大学深圳科技创新研究院) 基于零知识证明的属性凭证的验证方法及装置
CN115694812B (zh) * 2022-12-28 2023-05-02 苏州浪潮智能科技有限公司 一种基于零知识的门限身份认证方法、装置及云计算系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110945831B (zh) * 2018-05-08 2021-04-27 维萨国际服务协会 抗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
JP2022546470A (ja) * 2019-08-30 2022-11-04 コーネル ユニヴァーシティ トランスポート層セキュリティおよび他のコンテキストでのデータの検証のための非集中型技術

Also Published As

Publication number Publication date
AU2021229174A1 (en) 2022-10-20
EP4068678A1 (en) 2022-10-05
IL286318A (en) 2022-11-01
US20220329432A1 (en) 2022-10-13
AU2023226639A1 (en) 2023-09-21
CN115174087A (zh) 2022-10-11

Similar Documents

Publication Publication Date Title
US11025419B2 (en) System for digital identity authentication and methods of use
Ricci et al. Blockchains for covid-19 contact tracing and vaccine support: A systematic review
US20190273607A1 (en) System for digital identity authentication and methods of use
CN105659559B (zh) 验证远程服务器的安全性
Alvi et al. DVTChain: A blockchain-based decentralized mechanism to ensure the security of digital voting system voting system
CN112073484B (zh) 一种基于联盟链的gdpr合规监管方法及系统
Ma et al. Blockchain-based mechanism for fine-grained authorization in data crowdsourcing
AU2023226639A1 (en) Apparatus and system for zero-knowledge proof performed in multi-party computation
Sullivan et al. Blockchain, digital identity, e-government
EP1465100A1 (en) A method of purchasing insurance ir validating an anonymous transaction
Beduschi Rethinking digital identity for post-COVID-19 societies: Data privacy and human rights considerations
Dash et al. Artificial intelligence models for blockchain-based intelligent networks systems: Concepts, methodologies, tools, and applications
Singh et al. A technical look at the indian personal data protection bill
Hicks et al. Vams: Verifiable auditing of access to confidential data
Balamurugan et al. A Survey on Privacy Preserving and Trust Building Techniques of Blockchain-Based Systems
Lohr et al. Ensuring genuineness for selectively disclosed confidential data using distributed ledgers: Applications to rail wayside monitoring
Liburd An n-version electronic voting system
Deep et al. Access Management of User and Cyber-Physical Device in DBaaS according to Indian IT Laws using Blockchain
Hicks Design and Usage of Transparency Enhancing Technologies
Zirui et al. A privacy-preserved and user self-governance blockchain-based framework to combat COVID-19 depression in social media
Kabira A Public Key Infrastructure Model for Verification of Court Documents: the Judiciary of Kenya
Thompson et al. A Secure Decentralized Privacy-Preserving Healthcare System Using Blockchain
Put et al. An anonymous, verifiable Internet service POLL system
Toreini et al. Fairness as a Service (FaaS): verifiable and privacy-preserving fairness auditing of machine learning systems
Bossuat et al. Belenios: the Certification Campaign

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20231219

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20240422