DID/Smart Contractとオラクル

2020.03.06 福岡ブロックチェーンエコノミー勉強会での、DECO（https://arxiv.org/pdf/1909.00938.pdf）の仕組みの解説資料です。

Transcript

1. 2020.03.06
 福岡ブロックチェーンエコノミー勉強会
 
 DID/Smart Contractとオラクル
 Shigeyuki Azuchi

2. Copyright © 2020 chaintope Inc. All rights reserved. • 従来の証明
 個人情報を明らかにすることで成立。 
 
 • DIDにおける証明
 個人が資格情報（Credential）をローカルで管理し、との当事者に何を公開するかを完全に 
 制御する。他の情報を明らかにすることなく資格をもつ者であることを暗号学的に証明する。 
 Decentralized Identity
 2 個人のデータは個人に帰属し、 
 個人がデータの公開範囲を管理する 
 • 名前
 • 生年月日
 • 性別
 • etc.. Financial Service
 e-Commerce
 SNS
 Identityの証明
 タバコ、アルコールの購入には年齢の証明
 https://agechecker.net/
 KYC済みの証明

3. Copyright © 2020 chaintope Inc. All rights reserved. Decentralized Identity
 3 https://identity.foundation/ より
 多くの企業が参加するも、検証可能な資格情報を認可するオーソリティはまだ少ない 

4. Copyright © 2020 chaintope Inc. All rights reserved. Smart Contractは直接 
 現実世界のデータを取得する 
 ことはできず、Oracleがデータを 
 中継する。
 Oracleを利用したSmartContract 
 4 Smart Contract
 マーケット価 格
 為替相場
 仮想通貨
 価格
 ※ Smart Contractで求められる現実世界のデータは、必ずしも公な情報とは限らない。 
 プライベートなデータが対象になることも十分考えられ 
 • ユーザーが◦歳以上であること 
 • ユーザーが金融サービスを利用するために十分な資金を持っていること 
 これらをプライバシーを保護した状態で誰がどう提供するかが課題 
 Oracle

5. Copyright © 2020 chaintope Inc. All rights reserved. DECO
 5 DECO: Liberating Web Data Using Decentralized Oracles for TLS
 https://arxiv.org/pdf/1909.00938.pdf
 
 TLSで保護された既存のWebサイトのデータを
 検証可能な資格情報＝分散Oracleとして利用するプロトコル
 
 • 金融機関のWebサイト
 ◦ 金融機関によってKYCチェック済みであることの証明
 ◦ 金融サービスを利用するために十分な資金を持っていることの証明
 • 社会保障機関のWebサイト
 ◦ ◦歳以上であることの証明
 • etc..

6. Copyright © 2020 chaintope Inc. All rights reserved. DECOでできること
 6 Verifier
 TLS Server
 xxx.bank.co.jp
 TLS Client
 Proover
 ① ID/Passwordで認証
 ② 口座残高を表示しているペー ジをレスポンス
 ③ xxx.bank.co.jp からの
 ユーザーの口座残高の証明
 • ユーザーは証明したい暗号データが、あるTLS Serverからの情報である
 ことを証明
 • 暗号データを復号 or ゼロ知識で平文に関するステートメントを証明
 
 TLSサーバーに手を加えること無く、任意のWebサイトが分散Oracleとして機能する 

7. Copyright © 2020 chaintope Inc. All rights reserved. 三者間のハンドシェイクの鍵交換
 7 Verifier
 TLS Server
 Prover
 P Server ＝x s G
 P P ＝x P G
 P V ＝x V G
 ② P V を送信
 ③ P Client ＝P P + P V を送信
 ④ 共有シークレット Z = x S ・P Client を計算。
 Zのx座標を使ってTLS-PRFを実行し、 
 KEnc、KMACを生成。
 　
 最初に三者間でハンドシェイクを行い、TLSデータの暗号化/復号化に使用するセッション鍵を生成する。 
 TLS Serverからみた場合、通常のハンドシェイクに見える。 
 Proverは Z P = x P ・P Server を保持
 Verifierは Z V = x V ・P Server を保持
 Z = Z P ＋ Z V (互いにZ P とZ V を明かせない)
 ⑤ 2PCによりKEnc、KMAC P 、KMAC V を生成 
 
 2PC + PRF
 KEnc、KMAC P
 KMAC V 
 ① P Server を送信

8. Copyright © 2020 chaintope Inc. All rights reserved. 2PC + PRF
 8 ProverとVerifierはお互いの秘密鍵を明らかにすることなく、 
 • Prover：KEnc、KMAC P を取得
 • Verifier：KMAC V を取得
 
 1. ECtFプロトコルを実行し、楕円曲線の点の加算シェアを有限体F P の加算シェアに変換 
 Z = Z P + Z V = (x, y) を x = x P + x V となるようなF P の要素に変換し、
 両者がZ P 、Z V を明らかにすることなく、Proverはx P をVerifierはx V を受け取るプロトコルを実行 
 実際の構築にはPaillier暗号などの加法準同型性のある暗号を使って計算。 
 2. 単一のbinary circuitを使って2PC PRFを実行し、K Enc、KMAC P 、KMAC V を計算
 
 KMAC = KMAC P + KMAC V
9. Copyright © 2020 chaintope Inc. All rights reserved. ハンドシェイク後
 9 ハンドシェイクが完了した時点でProverは データの出処を証明することができるよう になる。
 1. Proverはサイトへのクエリを作成し、Verifierと2PC-HMACでクエリ へのタグを計算し、クエリをServerに発行する。 
 2. Serverからレスポンスを受信すると、 
 Verifierは2PC-HMACでタグを検証する。 
 3. ProverはVerifierにクエリ、レスポンスとK MAC P を送り、
 VerifierはProverにK MAC V を送る。
 4. ProverはVaerifierに対して証明を生成し、Verifierは 
 その証明が正しいか検証する。 
 a. 復号が可能なKEncを公開する（プライバシー的には‥） 
 b. ゼロ知識技術を利用してデータに関する任意のステートメン トを証明する
 i. データを部分的に復号しi番目のチャンクであることを証明
 ii. ゼロ知識でデータの一部（平文）に関する
 ステートメントを証明（口座残高 > $10000）