Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Privacy on Blockchain
Search
Osuke
November 13, 2019
Technology
1
1.2k
Privacy on Blockchain
Osuke
November 13, 2019
Tweet
Share
More Decks by Osuke
See All by Osuke
特許データを使ったマルチモーダルAIの検証事例@LLMProd#4
osuke
0
130
dbtを中心に据えた データ分析とプロダクト開発
osuke
1
920
LayerX Privacy Tech事業部紹介 Tech編
osuke
0
130
(SCIS2021) Anonify: プライバシーを保護した 検証可能な状態遷移モジュール
osuke
1
330
Rustで実装された AWS Nitro Enclaves CLIを読む
osuke
0
310
Rustのパフォーマンスに関するTips
osuke
3
2.6k
ARM TrustZone入門 / ARM TrustZone intro
osuke
3
8k
Anonify
osuke
3
960
Rustのasync/awaitとスケジューラの話 / rust-async-await
osuke
9
3.7k
Other Decks in Technology
See All in Technology
プロダクトエンジニアが活躍する環境を作りたくて 事業責任者になった話 ~プロダクトエンジニアの行き着く先~
gimupop
1
480
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
160
初心者に Vue.js を 教えるには
tsukuha
5
390
GitHub Universe: Evaluating RAG apps in GitHub Actions
pamelafox
0
180
【若手エンジニア応援LT会】AWSで繋がり、共に成長! ~コミュニティ活動と新人教育への挑戦~
kazushi_ohata
0
180
IaC運用を楽にするためにCDK Pipelinesを導入したけど、思い通りにいかなかった話
smt7174
1
110
MAMを軸とした動画ハンドリングにおけるAI活用前提の整備と次世代ビジョン / abema-ai-mam
cyberagentdevelopers
PRO
1
120
国土交通省 データコンペ参加者向け勉強会
takehikohashimoto
0
120
独自ツール開発でスタジオ撮影をDX!「VLS(Virtual LED Studio)」 / dx-studio-vls
cyberagentdevelopers
PRO
1
180
プロダクトチームへのSystem Risk Records導入・運用事例の紹介/Introduction and Case Studies on Implementing and Operating System Risk Records for Product Teams
taddy_919
1
170
[AWS JAPAN 生成AIハッカソン] Dialog の紹介
yoshimi0227
0
150
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
27
12k
Featured
See All Featured
Scaling GitHub
holman
458
140k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Fontdeck: Realign not Redesign
paulrobertlloyd
81
5.2k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Side Projects
sachag
452
42k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Become a Pro
speakerdeck
PRO
24
5k
A Modern Web Designer's Workflow
chriscoyier
692
190k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Designing for Performance
lara
604
68k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Transcript
情報経済 ソリューション公開講座
• でソフトウェアエンジニア • ブロックチェーンのプライバシーを 保護するためのシステムを研究開 発 • •
• の概要 ◦ • ブロックチェーンのプライバシーについて • 対処手法 ◦ ◦ ◦
• ゼロ知識証明 •
• 全ノードがブロックチェーンのデータのコピーを保持 • トランザクションをブロックごとにまとめ、前ブロックのハッシュ値を参照 ◦ トランザクションにより状態遷移 • コンセンサスプロトコルによりどのブロックを正とするか合意 状態 状態
ブロック ブロック
トランザクションのデータ構造 https://en.bitcoin.it/wiki/Transaction
• 現金のようなイメージ • 自身の をかき集 めて、トランザクションの で参照し、消費す る。 • 宛先とお釣り用の
が生成。 https://en.bitcoin.it/wiki/Transaction
• 銀行口座のようなイメージ • アカウントごとの残高が状態として遷移していく • 最新状態を知っていれば最新残高が分かる アカウント 残高 アリス 100
ボブ 50 アカウント 残高 アリス 70 ボブ 80 Tx
なぜプライバシーが必要か • ブロックチェーン上のデータの所有者とその個人情報との結びつきを防ぐ必要性 • 例えば、トランザクションのデジタル署名検証から送信者のアドレスが分かり、オフ チェーンで管理しているデータベースから個人と紐づく • 株式をブロックチェーン上のデータとして取引 ◦ どの投資家がいつ何に投資したか全て明らか
◦ 誰がどのくらい投資を受けているか全て明らか
プライバシー問題 • 第三者が検証可能なデータとしてブロックチェーンを扱いたいが、個人に紐付く データは隠したい。 • 監査性(検証可能性)とプライバシーのトレードオフ • 監査性 ◦ アリスが
持っている状態を全員で合意 ◦ アリスがボブに 送る状態遷移を全員で合意 • プライバシー ◦ 秘匿性:残高 ・送金額 を隠したい ◦ 匿名性:送り手アリス・受け手ボブを隠したい
プライバシー問題 • 秘匿性の欠如 ◦ トランザクションのデータを誰でも見ることができる ◦ のようなイメージ ▪ 送信データを隠す ◦
例)アリス ボブに 送金 ▪ というデータが誰でも見ることが可能 ◦ データを暗号化して送る手法? ▪ 送られてきた暗号文が を暗号化したデータであるかもしれない ▪ 完全性を持たせる方法が別途必要
プライバシー問題 • 匿名性の欠如 ◦ トランザクションが誰から誰に送られたのか見ることができる ◦ のようなイメージ ▪ 階層的に暗号化を施すオニオンルーティングをベースに アドレスを隠す
◦ 例)アリス ボブに 送金 ▪ ブロックチェーン上の全ての状態を全員が見ることができる ▪ 注)アドレスを暗号化することは意味ない • 仮名としてのアドレス値が一意に変わるだけ ▪ トランザクションの を断ち切る必要性
• での • ゼロ知識証明 •
毎回新しいアドレス • 根本的な解決ではない • 例えば、以下の一つのトランザクションだけで 、 、 の が同じアカウント所 有である確率がかなり高いと分かる。
ゼロ知識証明とは • インプットとなるデータを明らかにせずに、ある関数の結果に を持たせる暗 号学的手法 • において ◦ を明らかにせずに、 が
のハッシュ値であることを証明 ◦ 例えば、 が負の値ではないこと、 にあることを証明 証明者 CreateProof(x, y) 検証者 Verify(Proof, y)
証明者 CreateProof(x, y) 検証者 Verify(Proof, y) Setup(f) オンチェーン 証明鍵 検証鍵
• 約 • 検証コストは に対し 。
を算術回路をベースに、 で記述する • 上のアセンブリ言語のようなイメージ • 上の線型結合で表現 ◦ ◦ ・ ・
◦ 定数、 変数 • 例えば、 の 操作 ◦ 愚直にやると だが、線型結合を工夫し に可能
• 通常の とコストモデルが大きく異なる ◦ ビット演算は高コスト、楕円曲線上の演算は低コスト ◦ 例) よりも の方が低コスト ▪
▪ • などにより多項式へエンコードし、 で検証可能な証明を生成 • 効率の良い は という強い仮定に基づく • 効率よく汎用な を証明するために ◦ 通常、 時のパラメタを用いると の を破ることが可能 ◦ や などによる解決策
楕円曲線暗号 楕円曲線上のスカラー倍算は比較的低コスト。 秘密鍵を とし楕円曲線上の を とし て、 しかし、除算はとてもつもなく高コストなので と を知っていても
を求めることはできない。 (楕円曲線上の離散対数問題) よって、 を公開鍵として扱える
• ◦ する値 ◦ 乱数 ◦ 、 :楕円曲線上の • ◦
送り手が を指定し を生成、送信 • ◦ 送り手が と を明らかにすることで受け手が答え合わせ • 秘匿性:受け手はコミットされた値を知りえない • 拘束性:送り手が異なる値を公開しても成功しない • ゼロ知識証明と相性がいい ◦ 比較的小さい計算コストで、 に制限を与えられる
• https://github.com/monero-project/monero • • 秘匿性 ◦ ▪ 秘匿性、束縛性 ◦ ▪
ゼロ知識証明の一種で をもたらす • 匿名性 ◦ リング署名 ▪ メンバー公開鍵のうちの1つに対応する秘密鍵により署名 ▪ 送り手の匿名化 ◦ ステルスアドレス ▪ 送り手指定の新しいアドレスを受け手のアドレスに。 ▪ 受け手の匿名化
None
キーイメージ • 匿名性が得られる反面、どの が消費されたか第三者から分からないため の二重支払いが可能になってしまう • これを防ぐために、消費する に紐付く秘密鍵から一意に定まるキーイメージ をトランザクションインプットに加える •
◦ キーイメージ ◦ 秘密鍵 ◦ 公開鍵 • キーイメージがこれまでに存在していないかチェックする。
• https://github.com/zcash/zcash • セットのように、送金額のコミットメントをグ ローバルに存在するマークルツリーに追加 ◦ で送金するごとに の数だけ追加される • マークルツリーには
のみ ◦ 特定コミットメントとアカウントが紐づかないように
• 二重支払いを防ぐためにコミットメントに対し、 かつ な を管理。 • コミットメントが消費されるたびに に追加。 • 同じ
が2つあるということは同じコミット メントを 回消費しようとしていること。 Nullifier Set
• 生成コミットメントと消費コミットメントの が暗号学的に断ち切られている ので送金時の秘匿性・匿名性が保証される • ゼロ知識証明( により、一連の計算に を与える • 新しいコミットメントの生成
◦ コミットメントと暗号文の生成は正しいか ◦ 受け手だけが消費できるコミットメントか ◦ • コミットメントの消費 ◦ コミットメントがマークルツリーに属しているか ◦ 送り手が所有しているコミットメントか ◦ 正しく を生成しているか ◦
• アカウントベースのプライバシーを考慮したブロックチェーン • 加法準同型暗号( 暗号)によりオンチェーン上で暗号化したまま演算 • ゼロ知識証明( )により 。
None
• 送金額が正しい範囲にあるか • 残高以上の送金をしようとしていないか • 正しい公開鍵により暗号化されているか • ・・・
匿名性 • 送り手、受け手の他にダミーとなるデータを加えることで識別困難に。 アドレスデータ [Address1, .... Address n], 暗号化送金額 [Enc(0),...,
Enc(3), .., Enc(-3),.. Enc(0)] • 証明の検証 • 送り手、受け手、ダミーアドレス全て の暗号化残高をアップデート トランザクション オンチェーン
匿名性に対する証明生成コスト
監査性( ) • プライバシーは重要だが 絶対に誰からも見ることができない データは実社会では 扱いにくい • 「誰が誰にいくら」送金したのかを秘匿できることは、不正に得られた資金の流用に もつながる
• 特定の主体・機関が特定のユーザーの資金の流れを監査できる仕組みが必要
• 送金額・残高は で暗号化 • で復号化可能。 • 送金のためには が必要 • ユーザーが監査機関に
を 渡すことで監査可能に
• プライバシーを考慮したブロックチェーン • で実装し • https://github.com/LayerXcom/zero-chain
• ◦ ◦ は第 世代 以降 • メモリ上に保護された領域を生成することでセンシティブなデータを保護しつつプロ グラムを実行するための の拡張機能。
• 上の が 実際の保護領域 https://eprint.iacr.org/2016/086.pdf
• マルウェアなどを用いた機密情報の流出を防ぐ ◦ 秘密鍵、パスワード、 • 脅威モデル ◦ メモリ破壊 ▪ 不正なメモリ書き換え、操作
◦ システムソフトウェアからの攻撃 ▪ ◦ コールブート攻撃 ▪ 強制的な揮発遅延による メモリの読み取り • 一方で、サイドチャネル攻撃 には弱い ◦ 物理的な特性を外部から測定 https://www.usenix.org/system/files/conference/atc17/atc17-tsai.pdf
特有の特殊な命令セット • 命令 ◦ 保護領域の作成 ◦ にページの追加 ◦ 保護領域の初期化 •
命令 ◦ 暗号鍵の取得 ◦ へ入る ◦ から出る
• は揮発性メモリしか持たない ◦ 電源状態の遷移だけでデータが消えてしまう • 機密性の高いデータを暗号化して 外でストレージに保存する仕組みが必要 • 暗号鍵は 内に閉じていて、
固有のコンテキストに依存 ◦ の設定環境、 イメージなどに依存 • 暗号鍵は により初回利用時に生成し、 内の に保持
• 正当な であるか認証するための機能 ◦ が製造した なのか? ◦ 脆弱性はないか? ◦ の比較
実行プログラムの比較 • が認証 • が生成する を に送信 ◦ : (ハッシュ値) ▪ 実行環境と 内プログラム • をレスポンス ◦ 証明書で認証 IAS ISV
ブロックチェーンと • ( )と ( )の性質を応用 • 、 などのプロジェクト •
例えば、状態遷移を行う を 上で実行することで状態を秘匿化 • ネットワークに参加する マシンは互いに することで正当性を保証
まとめ • ブロックチェーンの実利用において、あるデータが一個人に結びつくことが問題にな りうる • データに対して検証可能な性質を維持しつつ、プライバシーを保護する仕組みが必 要 • 暗号学的アプローチやハードウェアレベルでブロックチェーンのプライバシー保護 に対する研究開発が
・ で盛んに取り組まれている