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
160
dbtを中心に据えた データ分析とプロダクト開発
osuke
1
950
LayerX Privacy Tech事業部紹介 Tech編
osuke
0
150
(SCIS2021) Anonify: プライバシーを保護した 検証可能な状態遷移モジュール
osuke
1
340
Rustで実装された AWS Nitro Enclaves CLIを読む
osuke
0
320
Rustのパフォーマンスに関するTips
osuke
3
2.8k
ARM TrustZone入門 / ARM TrustZone intro
osuke
3
8.1k
Anonify
osuke
3
980
Rustのasync/awaitとスケジューラの話 / rust-async-await
osuke
9
3.8k
Other Decks in Technology
See All in Technology
普通のエンジニアがLaravelコアチームメンバーになるまで
avosalmon
0
110
継続的にアウトカムを生み出し ビジネスにつなげる、 戦略と運営に対するタイミーのQUEST(探求)
zigorou
0
610
Microsoft Azure全冠になってみた ~アレを使い倒した者が試験を制す!?~/Obtained all Microsoft Azure certifications Those who use "that" to the full will win the exam! ?
yuj1osm
2
110
1等無人航空機操縦士一発試験 合格までの道のり ドローンミートアップ@大阪 2024/12/18
excdinc
0
170
第3回Snowflake女子会_LT登壇資料(合成データ)_Taro_CCCMK
tarotaro0129
0
200
多領域インシデントマネジメントへの挑戦:ハードウェアとソフトウェアの融合が生む課題/Challenge to multidisciplinary incident management: Issues created by the fusion of hardware and software
bitkey
PRO
2
110
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
170
オプトインカメラ:UWB測位を応用したオプトイン型のカメラ計測
matthewlujp
0
180
なぜCodeceptJSを選んだか
goataka
0
160
権威ドキュメントで振り返る2024 #年忘れセキュリティ2024
hirotomotaguchi
2
760
MLOps の現場から
asei
7
650
サービスでLLMを採用したばっかりに振り回され続けたこの一年のあれやこれや
segavvy
2
500
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Designing for Performance
lara
604
68k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
Writing Fast Ruby
sferik
628
61k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Designing for humans not robots
tammielis
250
25k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
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
ブロックチェーンと • ( )と ( )の性質を応用 • 、 などのプロジェクト •
例えば、状態遷移を行う を 上で実行することで状態を秘匿化 • ネットワークに参加する マシンは互いに することで正当性を保証
まとめ • ブロックチェーンの実利用において、あるデータが一個人に結びつくことが問題にな りうる • データに対して検証可能な性質を維持しつつ、プライバシーを保護する仕組みが必 要 • 暗号学的アプローチやハードウェアレベルでブロックチェーンのプライバシー保護 に対する研究開発が
・ で盛んに取り組まれている