ゼロ知識証明とブロックチェーン

Road to Devcon 4.0

Transcript

1. © Hitachi, Ltd. 2019. All rights reserved. Road to Devcon 4.0 〜 Security & Privacy ゼロ知識証明とブロックチェーン 日立製作所 長沼健
2. © Hitachi, Ltd. 2019. All rights reserved. 1 目次 • 自己紹介 • ゼロ知識証明とは？ • ブロックチェーンでどうやってゼロ知識証明を使うのか？ • 実例：ZcashというかZerocoinプロトコル
3. © Hitachi, Ltd. 2019. All rights reserved. 2 目次 • 自己紹介 • ゼロ知識証明とは？ • ブロックチェーンでどうやってゼロ知識証明を使うのか？ • 実例：ZcashというかZerocoinプロトコル
4. © Hitachi, Ltd. 2019. All rights reserved. 3 自己紹介 名前：長沼 健 日立製作所社会システム研究部所属 東京大学大学院複雑理工学専攻博士課程在学中 日立製作所入社以来、モバイルアプリケーション、GPS利活用, 車載無線セキュリティ、生体認証、医療データ分析の研究開発に取り組む。 2014年より暗号通貨, ブロックチェーンの研究開発に携わる。 受賞歴 2012年 暗号と情報セキュリティシンポジウム論文賞 2017年 辻井重男セキュリティ論文賞特別賞 2018年 情報処理学会業績賞 2019年 IWSEC2019 Best poster award 趣味はフットサルとビール
5. © Hitachi, Ltd. 2019. All rights reserved. 4 目次 • 自己紹介 • ゼロ知識証明とは？ • ブロックチェーンでどうやってゼロ知識証明を使うのか？ • 実例：ZcashというかZerocoinプロトコル
6. © Hitachi, Ltd. 2019. All rights reserved. 5 ゼロ知識証明とは？ ゼロ知識証明（zero-knowledge proof）とは、証明者(Prover)が検証者(Verifier)に、 自分の持っている命題が真であることを伝えるのに、真であること以外、 何の知識も伝えることなく証明できるような対話(非対話)知識証明プロトコルである。 by Wikipedia Alice (Prover)は命題Pが真(True)である事を誰かに証明したい 命題P: 私は二十歳以上だ 命題P: 私はある暗号の秘密鍵 を知っている ちょっと何いってるのか わからない
7. © Hitachi, Ltd. 2019. All rights reserved. 6 ゼロ知識証明とは？ Alice (Prover)は命題Pが真(True)である事をBob(Verifier)にゼロ知識証明したい 命題P: 私は二十歳以上だ 命題Pの証明(真である証拠)出せ 運転免許証提示 運転免許証提示でAlice (Prover)は命題Pが真(True)である事をBobに証明 できるがゼロ知識ではない。生年月日から年齢などが漏れている。 どんなものがゼロ知識証明と言えるのか？ Alice Bob
8. © Hitachi, Ltd. 2019. All rights reserved. 7 ゼロ知識証明とは？ Alice (Prover)は命題Pが真(True)である事をBob(Verifier)にゼロ知識証明したい Enc(pk, r) 乱数[r]を生成 Bob(Verifier)は自分で生成した乱数[r]を貰うだけなので、 対話終了後に秘密鍵に関する知識をゲットしていない⇒ゼロ知識っぽい 命題P: 私は公開鍵[pk]に対する 秘密鍵を知っている r 秘密鍵を知っているのでEnc(pk, r) を復号して平文[r]を計算可能 ※当然、AliceがBobに秘密鍵を渡せばPが真である事は 証明できるが、ゼロ知識でない(Bobは秘密鍵に関する情報を得ているので)。
9. © Hitachi, Ltd. 2019. All rights reserved. 8 目次 • 自己紹介 • ゼロ知識証明とは？ • ブロックチェーンでどうやってゼロ知識証明を使うのか？ • 実例：ZcashというかZerocoinプロトコル
10. © Hitachi, Ltd. 2019. All rights reserved. 9 プラバシー vs 透明性 Blockchain data Tx Data ID:101のbitcoinは Aliceが持っています Tx Data ID:100のbitcoinは Tomが持っています Tx Data ID:101のbitcoinは AliceからBobに送金 されました Aliceの署名 Tx Data ID:101のbitcoinは BobからTomに送金 されました Bobの署名 参照可能 参照可能 参照可能 透明性 プライバシ Public Blockchainの台帳データはネットワーク上の誰でも参照可能 ⇒透明性maxでプライバシーなし トランザクションデータを暗号化したら、確かにプライバシーは保たれるが、 マイナーがトランザクションの正当性を確認不能になる
11. © Hitachi, Ltd. 2019. All rights reserved. 10 もしトランザクションが暗号化されていると・・・ プライバシ保護のためUTXOで送金額が暗号化されたとすると・・・ [inputの金額の合計]=[outputの金額の合計] (手数料は0とする) また、送金額は0以上の値 BCネットワーク TX data [input] 100coin from: Tom to: Alice [output] Enc(80coin) from: Alice to: Bob [output] Enc(50coin) from: Alice to: Alice 悪いAlice Aliceは100coin分のunspent transactionのうち80をBobに送金、20をAliceに送金(おつ り)するが、送金額が暗号化されている事をいいことに、おつりを50にちょろまかした。 マイナーは復号化鍵をもっていないので金額不正に気付かない！ 困るわ～ Miner Miner
12. © Hitachi, Ltd. 2019. All rights reserved. 11 ブロックチェーンとゼロ知識証明の関係 一般的なゼロ知識証明の使い方 トランザクション内のプライバシ情報を秘匿化した際に正当性をゼロ知識で与える 秘匿化されたTx +ゼロ知識証明 Tx Data ID:101のbitcoinは Aliceが持っています Tx Data ID:100のbitcoinは Tomが持っています Tx Data From: ??? To: ??? Amount: ??? Aliceの署名 プライバシ情報は秘匿化されているが、 正当性を示すゼロ知識証明が付いている Miner 不正は無さそう だな！！
13. © Hitachi, Ltd. 2019. All rights reserved. 12 目次 • 自己紹介 • ゼロ知識証明とは？ • ブロックチェーンでどうやってゼロ知識証明を使うのか？ • 実例：ZcashというかZerocoinプロトコル
14. © Hitachi, Ltd. 2019. All rights reserved. 13 Zerocoin その１ Bitcoin上のoverlayプロトコルで、送信者/受信者のリンクを秘匿化(金額は固定) Carol Alice Bob 原像値：xを渡す Zerocoinプロトコル 1. Aliceはあて先を空欄にしてSHA(x)付のコインをBCに登録(Zerocoin mint) 2. Carolも同様にあて先空欄SHA(y)付のコインをBCに登録(mint) 3. AliceはBobからピザを購入、その支払いとしてSHA(x)のシード値xを渡す 4. BobはAorBの現像を知っている事を示すトランザクションを送信 5. マイナーがBobのゼロ知識証明が正しい事を確認しBCに登録(Bobは1coin get) Block [Zerocoin引出し] From:------ To: Bob Amount: 1btc ZK:(SHA(x) or SHA(y)の シードを知っている) Block [Zerocoin発行] From: Carol To: ------- Amount: 1btc Commit: SHA(y) ・・・ ・・・ Block [Zerocoin発行] From: Alice To: ------- Amount: 1btc Commit: SHA(x)
15. © Hitachi, Ltd. 2019. All rights reserved. 14 Zerocoin その2 Zerocoinのイメージ Alice Bob Carol Zerocoin Pool(宛先ブランクcoinたち) Commit: SHA(x) Commit: SHA(y) A or Bのシード を知ってるよ 1コインGet!! シード値：x ？ BC上の別ユーザは リンクが分からない Zerocoinでは、Pedersen commitmentを利用して Bobの2重引き落しを防いでいる！！
16. © Hitachi, Ltd. 2019. All rights reserved. まとめ
17. © Hitachi, Ltd. 2019. All rights reserved. 16 まとめ ブロックチェーンでは台帳情報は丸裸 暗号化したらいいじゃん マイナーがトランザクションの正当性を確認不可 ゼロ知識証明で正当性を確認
18. © Hitachi, Ltd. 2019. All rights reserved. 付録：zk-SNARK
19. © Hitachi, Ltd. 2019. All rights reserved. 18 zk-SNARKとは？ zk-SNARKとは Zero-Knowledge Succinct Non-Interactive Argument of Knowledge ゼロ知識で 簡潔な 非対話型 知識証明 (安全性証明中に攻撃者の計算量仮定があるためargument) 一般的に非対話型ゼロ知識証明で簡潔なものをzk-SNARKと言う Pinocchio方式(Zcashに利用)はArithmetic回路に対する代表例なzk-SNARK ※簡潔とは証明のサイズが回路のサイズによらない定数(セキュリティパラメータのみに依存)、 例えばBullet proofsは回路サイズに証明のサイズが依存するので簡潔でない 回路のサイズによってはBullet proofsの方が証明長が短い場合もある
20. © Hitachi, Ltd. 2019. All rights reserved. 19 Pinocchioで出来ること パブリックなArithmetic回路(関数)：F(-)、とそのパブリックな出力値：yに対して ゼロ知識証明： [私はF(x)=yとなる入力値：xを知ってる] Aliceは命題P:私はF(x)=yとなる入力値：xを知っている をマイナーなどに証明できる。 ※Fとしてハッシュ関数とかを考えると分かりやすいかも その他応用として、パブリックなプロトコルに対して、 トランザクションをそのプロトコル従って生成した：honest性を証明できる。 要は、Aliceがトランザクションデータを暗号化しても、その中身をズルせず ちゃんと作った事を証明できる。
21. © Hitachi, Ltd. 2019. All rights reserved. 20 Pinocchioベースのzk-SNARKをブロックチェーンで使うには？ まず、信頼できる第3者機関がset upを行います！(Single point of trust) CRS(Common reference string)と呼ばれるsystem parameterを生成 BCネットワーク マイナー Alice 第3者機関 EK Step1. ゼロ知識証明したい命題PをArithmetic回路：Cで表現 Step2. QAP(後述)を用いて、Cに対応するCRSを生成・公開 CRSは証明を生成するためのevaluation key: EKと、 証明を検証するためのverification key: VKとを含む また命題P、回路Cもみんな知っている。 VK
23. © Hitachi, Ltd. 2019. All rights reserved. 補足資料 共通鍵暗号、公開鍵暗号、電子署名
24. © Hitachi, Ltd. 2019. All rights reserved. 23 共通鍵暗号 暗号化：平文データを暗号文データに変換すること (Enc関数で表す) 復号化：暗号化データを平文データに変換すること (Dec関数で表す) 平文全体 (長さ256のbit列) 暗号文全体 (長さ256のbit列) Enc(K, -) Dec(K, -) 共通鍵暗号方式では、暗号化と復号化に同じ鍵Kを用いる。 Message: M Enc(K, M)
25. © Hitachi, Ltd. 2019. All rights reserved. 24 公開鍵暗号 一方、公開鍵暗号方式では暗号化と復号化に異なる鍵を利用する 暗号化の鍵を公開鍵：Pk、復号化の鍵を秘密鍵：Skという 平文全体 (長さ256のbit列) 暗号文全体 (長さ256のbit列) Enc(Pk, -) Dec(Sk, -) 公開鍵を公開する事で暗号化関数(Enc(Pk,-))は誰でも計算可能になる これを応用する事で電子署名が実現出来る。 ※公開鍵から秘密鍵を算出するのは計算量的に困難 Message: M Enc(Pk, M)
26. © Hitachi, Ltd. 2019. All rights reserved. 25 電子署名 平文全体 (長さ256のbit列) 暗号文全体 (長さ256のbit列) Enc(Pk, -) Dec(Sk, -) AliceがBobにメッセージMを送信する際に、Mのハッシュ値D(256bit)に対して、Aliceの秘 密鍵を用いて、Dec(Sk, D)=sigを生成し、Mと一緒に送信する。 (M, sig)を受け取ったBobはEnc(Pk, sig)=D’を計算して、Mのハッシュ値Dと一致するか確 認する。メッセージが通信路上で改ざんされているとDとD’が一致しない M D sig=Dec(Sk, D) D’ = ? この電子署名プロトコルにおいて、AliceはBobに対して、公開鍵Pkに対する秘密 鍵Skの知識を持っている事を証明している。しかも、秘密鍵の情報を渡す事なく。 (Bobは秘密鍵に関する情報を得ていない、つまりゼロ知識っぽい雰囲気)
27. © Hitachi, Ltd. 2019. All rights reserved. 26 参考1︓離散対数のゼロ知識証明 by Schnorr 離散群：G=<g>、生成元：g、元A∈Gが与えられた際に(G, g, A) prover：Pはverifier：Vに対して”A=g^x”となる”x”を知っている事をゼロ知識証明したい。 ※以下の全ての話はHVZKIP: Honest Verifier Zero Knowledge Interactive Proofモデル つまりVerifierは正しく乱数を生成する P V r ∈ Z|G| ：乱数を生成 T=g^r T=g^r c∈ Z|G| ：乱数を生成 c s=cx+rを計算 s Check!! g^s=(A^c)・T Zero Knowledge proofの3要素 1. Completeness：正しい知識を持っているPはプロトコルを成功させる(negligibleな失敗はOK) 2. Soundness：逆に正しい知識を持っていないPは失敗する(negligibleな成功はOK) 3. Zero Knowledge：verifier Vが対話証明中に得られるデータは、正しいPなしでもsimulateできる ※simulateのレベルは色々あるがsimulatorからget出来る情報の分布がPから得られる情報の分布と完全に一致する事が望ましい
28. © Hitachi, Ltd. 2019. All rights reserved. 27 参考2︓離散対数のゼロ知識証明の⾮対話化 先ほどのゼロ知識証明の非対話化(Fiat-Shamir Heuristic) Vが生成していた乱数cをPが生成 ※乱数cはTが生成された後に生成しないとダメ！！ T=A^(-c) (g^s)としてしまえば良いので⇒cはTを入力とするランダム関数の出力とする P V r ∈ Z|G| ：乱数を生成 T=g^r T=g^r H(T, sys-para)=c∈ Z|G| 乱数を生成 c s=cx+rを計算 s Check!! g^s=(A^c)・T 実は上のプロトコルでTを送信する必要はない (c, s)からT=A^(-c) (g^s)を計算し、H(T, sys-para)=cをチェックする ゼロ知識証明であることの証明はやや難しい(soundnessにforking lemmaを使う)
29. © Hitachi, Ltd. 2019. All rights reserved. 28 参考3︓⾮対話化の応⽤ Schnorr署名 M: 署名対象のメッセージ x: 秘密鍵(Pが持っている) pk=g^x: 署名検証用の公開鍵(Vが持っている) P V r ∈ Z|G| ：乱数を生成 T=g^r H(T, M)=c∈ Z|G| r=s+cxとなるsを計算 Pはxを知っている！ メッセージMの署名値として (s, c)を送信 Check!! H(g^s・pk^c, M) = H(T, M) =c gx 安全性の証明にはforking lemmaを使うのでやや難しい 安全な事の直感的な理解： 秘密鍵xを知らない人がメッセージMに対して「自己言及型」の式H(gs・pkc, M)=c をみたす組(s, c)を見つけるのは難しい(入力、出力どっちにもcが入っている)
30. © Hitachi, Ltd. 2019. All rights reserved. 29 参考4︓Pedersenコミットメントのゼロ知識証明 離散群：G=<g>=<h>, 生成元：g, h, 元A∈Gが与えられた際に(G, g, h, A) prover：Pはverifier：Vに対して”A=(gx)・(hy)”となる”(x, y)”を知っている事をゼロ知識証明したい。 ※通常Pedersen commitmentでは(g, h)の離散対数関係は誰も知らないと仮定する P V r, s∈ Z|G| ：乱数を生成 T=(gr)・(hs) T=(gr)・(hs) c∈ Z|G| ：乱数を生成 c u=cx+r v=cy+sを計算 (u, v) Check!! (gu)・(hv)=(Ac)・T 非対話型＆Tを送信しないバージョンにするには・・・ ⇒PがH(T, sys-para)=cを計算し(c, u, v)を送信 (c, u, v)からT=A-c (gu)・(hv)を計算し、H(T, sys-para)=cをチェックする
31. © Hitachi, Ltd. 2019. All rights reserved. 30 参考5︓OR回路のゼロ知識証明 離散群：G=<g>=<h>, 生成元：g, h, 元A, B∈Gが与えられた際に(G, g, h, A, B) prover：Pはverifier：Vに対して[”A=gx”となる”x”を知っている]or [B=hy”となる”y”を知っている]事を ゼロ知識証明したい。 ※A, Bどちらの離散対数を知っているかは秘匿したい。 P V PはA=gxを知っているとする r, s2, c2∈ Z|G| ：乱数を生成 T1 =gr T2 =hs2/Bc2 (fake proof for y) を計算 T1 =gr T2 =hs2/Bc2 c∈ Z|G| ：乱数を生成 c c1=c-c2 s1=xc1+r を計算 (s1, s2, c1, c2) Check!! gs1=Ac1・T1 hs2=Bc2・T2 c1+c2=c 証明のイメージ 通常の離散対数のゼロ知識証明でVの生成する乱数cの値をPが事前に知っていたら fake proofを作るのは容易(T=gs/AcとしてしまえばOK) 上の証明ではc1, c2の内、どちらかはPが選べるので、x or y を知っていれば、 もう一つのfake proofを作れる。 同様にk out of nのゼロ知識証明も出来る！！
32. © Hitachi, Ltd. 2019. All rights reserved. 31 参考6：ゼロ知識証明のちゃんとした定義 ゼロ知識証明（zero-knowledge proof）とは、証明者(Prover)が検証者(Verifier)に、自分の持っている命 題が真であることを伝えるのに、真であること以外、何の知識も伝えることなく証明できるような interactiveな知識証明プロトコルである。 by Wikipedia ゼロ知識証明（zero-knowledge proof）定義 ・Completeness: 命題が真であれば、必ずProverはVerifierとの対話を完遂できる ・Soundness: 命題が偽であれば、negligibleな確率を除いてProverはVerifierとの対話を完遂できない ・Zero-knowledge: Verifierはやり取りにおいて命題が真であること意外の情報をゲットできない ⇒Zero-knowledge性は、実際には以下のようにformulate PとVのやり取り(view)を知識を全く持たない(＝Pと通信しない)シミュレーターSが生成可能 (やり取りでVがゲットできる情報は知識ソースがないSでも生成可能⇒やり取りで秘密は漏れてない) 例)離散対数のゼロ知識証明においてPは生成したcに対してg^s=(A^c)・Tとなる (s, T)をゲットしているが、知識を持たないSでも生成可能(sを生成してT=g^s/A^c) 安全性証明において攻撃者の計算能力に仮定(離散対数仮定など)を置く場合を zero-knowledge argumentという(詳細は専門書を読んで)
33. © Hitachi, Ltd. 2019. All rights reserved. 32 ブロックチェーンとゼロ知識証明の関係 先の例では送金額が暗号化されていたのでマイナーは以下の2点が心配 1. [inputの金額の合計]=[outputの金額の合計]だろうか？ 2. 送金額は[0～最大送金額]のインターバルに入っているか？ Aliceは 命題P1 ：input金額=output金額となる。 命題P2 ：暗号文は[0～最大送金額]インターバルに入る。 に対するゼロ知識証明をトランザクションに付与する BCネットワーク TX data [input] 100coin from: Tom to: Alice [output] Enc(80coin) from: Alice to: Bob [output] Enc(50coin) from: Alice to: Alice Alice π1 , π2 : P1 , P2 に 対するゼロ知識証明 マイナーは、送金額は分から ないが、Aliceが不正していな い事は確認出来る
34. © Hitachi, Ltd. 2019. All rights reserved. 33 なぜ非対話型ゼロ知識証明が必要か？ ☆zk-SNARKのNはNon interactiveのN ゼロ知識証明の方式によってはProverとVerifier間で複数回の通信が発生するも のがある(例：Schnorrによる離散対数のゼロ知識証明)。 Public型ブロックチェーンではVerifierはネットワーク上のPoWを行っている 不特定多数のMinerなので、それら全てと対話する事は不可能 ⇒Non-interactiveが必須条件 やってらんないよ～