Tweet
Tweet

Slide 1

Slide 1 text

情報経済 ソリューション公開講座

Slide 2

Slide 2 text

● でソフトウェアエンジニア ● ブロックチェーンのプライバシーを 保護するためのシステムを研究開 発 ● ●

Slide 3

Slide 3 text

● の概要 ○ ● ブロックチェーンのプライバシーについて ● 対処手法 ○ ○ ○ ● ゼロ知識証明 ●

Slide 4

Slide 4 text

● 全ノードがブロックチェーンのデータのコピーを保持 ● トランザクションをブロックごとにまとめ、前ブロックのハッシュ値を参照 ○ トランザクションにより状態遷移 ● コンセンサスプロトコルによりどのブロックを正とするか合意 状態 状態 ブロック ブロック

Slide 5

Slide 5 text

トランザクションのデータ構造 https://en.bitcoin.it/wiki/Transaction

Slide 6

Slide 6 text

● 現金のようなイメージ ● 自身の をかき集 めて、トランザクションの で参照し、消費す る。 ● 宛先とお釣り用の が生成。 https://en.bitcoin.it/wiki/Transaction

Slide 7

Slide 7 text

● 銀行口座のようなイメージ ● アカウントごとの残高が状態として遷移していく ● 最新状態を知っていれば最新残高が分かる アカウント 残高 アリス 100 ボブ 50 アカウント 残高 アリス 70 ボブ 80 Tx

Slide 8

Slide 8 text

なぜプライバシーが必要か ● ブロックチェーン上のデータの所有者とその個人情報との結びつきを防ぐ必要性 ● 例えば、トランザクションのデジタル署名検証から送信者のアドレスが分かり、オフ チェーンで管理しているデータベースから個人と紐づく ● 株式をブロックチェーン上のデータとして取引 ○ どの投資家がいつ何に投資したか全て明らか ○ 誰がどのくらい投資を受けているか全て明らか

Slide 9

Slide 9 text

プライバシー問題 ● 第三者が検証可能なデータとしてブロックチェーンを扱いたいが、個人に紐付く データは隠したい。 ● 監査性（検証可能性）とプライバシーのトレードオフ ● 監査性 ○ アリスが 持っている状態を全員で合意 ○ アリスがボブに 送る状態遷移を全員で合意 ● プライバシー ○ 秘匿性：残高 ・送金額 を隠したい ○ 匿名性：送り手アリス・受け手ボブを隠したい

Slide 10

Slide 10 text

プライバシー問題 ● 秘匿性の欠如 ○ トランザクションのデータを誰でも見ることができる ○ のようなイメージ ■ 送信データを隠す ○ 例）アリス ボブに 送金 ■ というデータが誰でも見ることが可能 ○ データを暗号化して送る手法？ ■ 送られてきた暗号文が を暗号化したデータであるかもしれない ■ 完全性を持たせる方法が別途必要

Slide 11

Slide 11 text

プライバシー問題 ● 匿名性の欠如 ○ トランザクションが誰から誰に送られたのか見ることができる ○ のようなイメージ ■ 階層的に暗号化を施すオニオンルーティングをベースに アドレスを隠す ○ 例）アリス ボブに 送金 ■ ブロックチェーン上の全ての状態を全員が見ることができる ■ 注）アドレスを暗号化することは意味ない ● 仮名としてのアドレス値が一意に変わるだけ ■ トランザクションの を断ち切る必要性

Slide 12

Slide 12 text

● での ● ゼロ知識証明 ●

Slide 13

Slide 13 text

毎回新しいアドレス ● 根本的な解決ではない ● 例えば、以下の一つのトランザクションだけで 、 、 の が同じアカウント所 有である確率がかなり高いと分かる。

Slide 14

Slide 14 text

ゼロ知識証明とは ● インプットとなるデータを明らかにせずに、ある関数の結果に を持たせる暗 号学的手法 ● において ○ を明らかにせずに、 が のハッシュ値であることを証明 ○ 例えば、 が負の値ではないこと、 にあることを証明 証明者 CreateProof(x, y) 検証者 Verify(Proof, y)

Slide 15

Slide 15 text

証明者 CreateProof(x, y) 検証者 Verify(Proof, y) Setup(f) オンチェーン 証明鍵 検証鍵 ● 約 ● 検証コストは に対し 。

Slide 16

Slide 16 text

を算術回路をベースに、 で記述する ● 上のアセンブリ言語のようなイメージ ● 上の線型結合で表現 ○ ○ ・ ・ ○ 定数、 変数 ● 例えば、 の 操作 ○ 愚直にやると だが、線型結合を工夫し に可能 　　　　　　　　　　　　

Slide 17

Slide 17 text

● 通常の とコストモデルが大きく異なる ○ ビット演算は高コスト、楕円曲線上の演算は低コスト ○ 例） よりも の方が低コスト ■ ■ ● などにより多項式へエンコードし、 で検証可能な証明を生成 ● 効率の良い は という強い仮定に基づく ● 効率よく汎用な を証明するために ○ 通常、 時のパラメタを用いると の を破ることが可能 ○ や などによる解決策

Slide 18

Slide 18 text

楕円曲線暗号 楕円曲線上のスカラー倍算は比較的低コスト。 秘密鍵を とし楕円曲線上の を とし て、 しかし、除算はとてもつもなく高コストなので と を知っていても を求めることはできない。 （楕円曲線上の離散対数問題） よって、 を公開鍵として扱える

Slide 19

Slide 19 text

● ○ する値 ○ 乱数 ○ 、 ：楕円曲線上の ● ○ 送り手が を指定し を生成、送信 ● ○ 送り手が と を明らかにすることで受け手が答え合わせ ● 秘匿性：受け手はコミットされた値を知りえない ● 拘束性：送り手が異なる値を公開しても成功しない ● ゼロ知識証明と相性がいい ○ 比較的小さい計算コストで、 に制限を与えられる

Slide 20

Slide 20 text

● https://github.com/monero-project/monero ● ● 秘匿性 ○ ■ 秘匿性、束縛性 ○ ■ ゼロ知識証明の一種で をもたらす ● 匿名性 ○ リング署名 ■ メンバー公開鍵のうちの１つに対応する秘密鍵により署名 ■ 送り手の匿名化 ○ ステルスアドレス ■ 送り手指定の新しいアドレスを受け手のアドレスに。 ■ 受け手の匿名化

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

キーイメージ ● 匿名性が得られる反面、どの が消費されたか第三者から分からないため の二重支払いが可能になってしまう ● これを防ぐために、消費する に紐付く秘密鍵から一意に定まるキーイメージ をトランザクションインプットに加える ● ○ キーイメージ ○ 秘密鍵 ○ 公開鍵 ● キーイメージがこれまでに存在していないかチェックする。

Slide 23

Slide 23 text

● https://github.com/zcash/zcash ● セットのように、送金額のコミットメントをグ ローバルに存在するマークルツリーに追加 ○ で送金するごとに の数だけ追加される ● マークルツリーには のみ ○ 特定コミットメントとアカウントが紐づかないように

Slide 24

Slide 24 text

● 二重支払いを防ぐためにコミットメントに対し、 かつ な を管理。 ● コミットメントが消費されるたびに に追加。 ● 同じ が２つあるということは同じコミット メントを 回消費しようとしていること。 Nullifier Set

Slide 25

Slide 25 text

● 生成コミットメントと消費コミットメントの が暗号学的に断ち切られている ので送金時の秘匿性・匿名性が保証される ● ゼロ知識証明（ により、一連の計算に を与える ● 新しいコミットメントの生成 ○ コミットメントと暗号文の生成は正しいか ○ 受け手だけが消費できるコミットメントか ○ ● コミットメントの消費 ○ コミットメントがマークルツリーに属しているか ○ 送り手が所有しているコミットメントか ○ 正しく を生成しているか ○

Slide 26

Slide 26 text

● アカウントベースのプライバシーを考慮したブロックチェーン ● 加法準同型暗号（ 暗号）によりオンチェーン上で暗号化したまま演算 ● ゼロ知識証明（ ）により 。

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

● 送金額が正しい範囲にあるか ● 残高以上の送金をしようとしていないか ● 正しい公開鍵により暗号化されているか ● ・・・

Slide 29

Slide 29 text

匿名性 ● 送り手、受け手の他にダミーとなるデータを加えることで識別困難に。 アドレスデータ [Address1, .... Address n], 暗号化送金額 [Enc(0),..., Enc(3), .., Enc(-3),.. Enc(0)] ● 証明の検証 ● 送り手、受け手、ダミーアドレス全て の暗号化残高をアップデート トランザクション オンチェーン

Slide 30

Slide 30 text

匿名性に対する証明生成コスト

Slide 31

Slide 31 text

監査性（ ） ● プライバシーは重要だが 絶対に誰からも見ることができない データは実社会では 扱いにくい ● 「誰が誰にいくら」送金したのかを秘匿できることは、不正に得られた資金の流用に もつながる ● 特定の主体・機関が特定のユーザーの資金の流れを監査できる仕組みが必要

Slide 32

Slide 32 text

● 送金額・残高は で暗号化 ● で復号化可能。 ● 送金のためには が必要 ● ユーザーが監査機関に を 渡すことで監査可能に

Slide 33

Slide 33 text

● プライバシーを考慮したブロックチェーン ● で実装し ● https://github.com/LayerXcom/zero-chain

Slide 34

Slide 34 text

● ○ ○ は第 世代 以降 ● メモリ上に保護された領域を生成することでセンシティブなデータを保護しつつプロ グラムを実行するための の拡張機能。 ● 上の が 実際の保護領域 https://eprint.iacr.org/2016/086.pdf

Slide 35

Slide 35 text

● マルウェアなどを用いた機密情報の流出を防ぐ ○ 秘密鍵、パスワード、 ● 脅威モデル ○ メモリ破壊 ■ 不正なメモリ書き換え、操作 ○ システムソフトウェアからの攻撃 ■ ○ コールブート攻撃 ■ 強制的な揮発遅延による メモリの読み取り ● 一方で、サイドチャネル攻撃 には弱い ○ 物理的な特性を外部から測定 https://www.usenix.org/system/files/conference/atc17/atc17-tsai.pdf

Slide 36

Slide 36 text

特有の特殊な命令セット ● 命令 ○ 保護領域の作成 ○ にページの追加 ○ 保護領域の初期化 ● 命令 ○ 暗号鍵の取得 ○ へ入る ○ から出る

Slide 37

Slide 37 text

● は揮発性メモリしか持たない ○ 電源状態の遷移だけでデータが消えてしまう ● 機密性の高いデータを暗号化して 外でストレージに保存する仕組みが必要 ● 暗号鍵は 内に閉じていて、 固有のコンテキストに依存 ○ の設定環境、 イメージなどに依存 ● 暗号鍵は により初回利用時に生成し、 内の に保持

Slide 38

Slide 38 text

● 正当な であるか認証するための機能 ○ が製造した なのか？ ○ 脆弱性はないか？ ○ の比較 実行プログラムの比較 ● が認証 ● が生成する を に送信 ○ ： （ハッシュ値） ■ 実行環境と 内プログラム ● をレスポンス ○ 証明書で認証 IAS ISV

Slide 39

Slide 39 text

ブロックチェーンと ● （ ）と （ ）の性質を応用 ● 、 などのプロジェクト ● 例えば、状態遷移を行う を 上で実行することで状態を秘匿化 ● ネットワークに参加する マシンは互いに することで正当性を保証

Slide 40

Slide 40 text

まとめ ● ブロックチェーンの実利用において、あるデータが一個人に結びつくことが問題にな りうる ● データに対して検証可能な性質を維持しつつ、プライバシーを保護する仕組みが必 要 ● 暗号学的アプローチやハードウェアレベルでブロックチェーンのプライバシー保護 に対する研究開発が ・ で盛んに取り組まれている