Recommended
More Related Content
Featured
Featured (20)
Cryptocurrency1
- 2. 目次 • 暗号理論 • 暗号学的ハッシュ関数 • 電子署名 • 識別情報としての公開鍵 • 非中央集権的な識別情報管理 • ハッシュポインタとデータ構造 • ブロックチェーン • Merkle木
- 3. 目次 • 2つの単純な仮想通貨 • Goofycoin • Scroogecoin
- 4. 暗号理論 • 仮想通貨は暗号理論に依拠している • ビットコインは以下の3つを利用 • 暗号学的ハッシュ関数 • 電子署名 • ゼロ知識証明
- 5. 暗号理論 • 仮想通貨は暗号理論に依拠している • ビットコインは以下の3つを利用 • 暗号学的ハッシュ関数 • 電子署名 • ゼロ知識証明
- 6. 暗号学的ハッシュ関数 • ハッシュ関数は任意の長さ入力を受け取り固定サイズの 出力を生成する関数 • 暗号学的ハッシュ関数は以下の3つの属性を備える • 衝突耐性 • 秘匿性 • パズル親和性
- 7. 衝突耐性 • 衝突とは、2つの異なる入力が同じ出力を生成すること • 誰も衝突を見つけられないようなハッシュ関数𝐻は 衝突耐性がある 2つの値𝑥, 𝑦が𝑥 ≠ 𝑦でありながら𝐻 𝑥 = 𝐻 𝑦 であるようなものを決して 見つけられない場合、ハッシュ関数𝐻は衝突耐性がある 衝突耐性(collision resistance)
- 9. 衝突耐性 • 衝突を発見するための汎用的な手法 • 出力サイズが𝑋であるとき2 𝑋 + 1種類の値を選んでハッシュ値を計算 • このアルゴリズムはあらゆるハッシュ関数で機能する • しかし、計算時間が非常に長い • 特定のハッシュ関数には効率のよい衝突検出方法が存在する • 衝突耐性があることが証明されたハッシュ関数は存在しない
- 10. 応用：メッセージダイジェスト • 衝突耐性があるハッシュ関数はメッセージダイジェストとして 利用可能 • 認証付きのオンラインファイルストレージを考える • 利用者がファイルをアップロード可能 • ダウンロード時に内容の完全性が保証される
- 13. 応用：メッセージダイジェスト • どのように完全性を確認するか？ • 衝突耐性を持つハッシュ関数があれば以下の手順で確認可能 • アップロードするファイルのハッシュ値を計算 • ダウンロード後に再びハッシュ値を計算 • ２つの値を比較 • ハッシュ値は固定サイズであるためディスク容量を圧迫しない • 悪意のある第三者による変更も検出可能
- 14. 秘匿性 • ハッシュ関数の出力𝑦 = 𝐻 𝑥 が与えられたとき、𝑥を求める 現実的な手段がないとき𝐻は秘匿性を満たす • ∥は結合を表す • min-entropyが高いと分布は散らばっている min-entropyの高い確率分布から秘密の値𝑟が選ばれているときに、𝐻(𝑟 ∥ 𝑥)が 与えられても𝑥を現実的に見つけることはできない 秘匿性(hiding)
- 15. 秘匿性 • ハッシュ関数の出力𝑦 = 𝐻 𝑥 が与えられたとき、𝑥を求める 現実的な手段がないとき𝐻は秘匿性を満たす • ∥は結合を表す • min-entropyが高いと分布は散らばっている min-entropyの高い確率分布から秘密の値𝑟が選ばれているときに、𝐻(𝑟 ∥ 𝑥)が 与えられても𝑥を現実的に見つけることはできない 秘匿性(hiding) 一様ランダムな分布など
- 16. 応用：コミットメント
- 18. 応用：コミットメント
- 20. コミットメントのスキーム • コミットメントのスキームは2つのアルゴリズムから構成 1. com := commit(msg, nonce) コミット関数は入力としてメッセージとナンスと呼ばれる 秘密の無作為な値を取り、コミットメントを返す 2. verify(com, msg, nonce) verify関数は、入力としてコミットメント、メッセージ ナンスを取り、com == commit(msg, nonce)を返す
- 21. コミットメントのスキーム • このスキームには2つのセキュリティ属性が必要 1. 秘匿性(hiding) comが与えられてもmsgを現実的に見つけられない 2. 拘束性(binding) msg ≠ msg’かつ commit(msg, nonce)== commit(msg’, nonce’)となるような (msg, nonce)と(msg’, nonce’)の2つの対を現実的に 見つけられない
- 22. コミットメントのスキーム • コミットメントの手順 1. nonceの生成 2. 生成したnonceとメッセージに対してcommit関数を適用し コミットメントを公開 テーブルの上に密封された封筒を 置くことに当たる
- 23. コミットメントのスキーム • コミットメントの手順 1. nonceの生成 2. 生成したnonceとメッセージに対してcommit関数を適用し コミットメントを公開 3. メッセージとnonceを公開 4. メッセージがコミットされたものと一致するか確認 テーブルの上の密封された封筒を 開封することに当たる
- 25. セキュリティ属性 • アルゴリズムが封筒の密封と開封と同じように振る舞う ためには秘匿性と拘束性が必要 • 秘匿性 コミットメントがわかっても、封筒を見ている人が メッセージの中身を推測できてはならない • 拘束性 一度封筒の中身をコミットしたら、あとで意思を変更できない
- 26. コミットメントスキームの実装 • 暗号学的ハッシュ関数を使えば実際にコミットメントスキーム を実装できる • commit関数の実装 𝑐𝑜𝑚𝑚𝑖𝑡 𝑚𝑠𝑔, 𝑛𝑜𝑛𝑐𝑒 ≔ 𝐻(𝑛𝑜𝑛𝑐𝑒 ∥ 𝑚𝑠𝑔) • verify関数の実装 受け取ったメッセージとnonceを使ってcommit関数を適用 𝑛𝑜𝑛𝑐𝑒は無作為な256ビット値
- 27. セキュリティ属性の確認 • 秘匿性は暗号学的ハッシュ関数を用いていることから 明らかに備えている • 暗号学的ハッシュ関数は衝突耐性を持つため拘束性も暗黙に 満たされている • 𝐻 𝑛𝑜𝑐𝑛𝑒 ∥ 𝑚𝑠𝑔 == 𝐻(𝑛𝑜𝑛𝑐𝑒′ ∥ 𝑚𝑠𝑔′)となるような𝑚𝑠𝑔, 𝑚𝑠𝑔′は 見つけることができない
- 28. パズル親和性 𝑘が𝑚𝑖𝑛エントロピーの高い確率分布から選ばれているとき、ハッシュ関数𝐻の すべての𝑛ビット出力𝑦について、2 𝑛よりも大幅に短い時間で𝐻 𝑘 ∥ 𝑥 = 𝑦と なるような𝑥を現実的に見つけられないとき、ハッシュ関数𝐻はパズル親和性を 満たす パズル親和性(puzzle friendliness)
- 29. 応用：探索パズル • パズル親和性を用いると解にたどり着くための近道がない 探索パズルを作ることができる • 探索パズル • ハッシュ関数 𝐻 • 𝑚𝑖𝑛エントロピーの高い確率分布から選ばれた値𝑖𝑑 • ターゲット集合𝑌 • 𝐻 𝑖𝑑 ∥ 𝑥 ∈ 𝑌となるような𝑥がパズルの解
- 30. 応用：探索パズル • パズルの難易度は𝑌の大きさによって調整可能 • パズル𝑖𝑑が𝑚𝑖𝑛エントロピーが高い確率分布から選ばれて いれば𝑥の値を無作為に試す以外に効率の良い方法はない • パズル𝑖𝑑が推測できる場合予めパズルの解を計算するなどの ハックが可能
- 32. 電子署名 • 電子署名は紙に手で書かれる署名をデジタルの世界で 実現したもの • 電子署名の特性 1. あるユーザの署名をすることができるのは本人のみだが 署名の有効性は誰でも確認可能 2. 署名と特定の文書は紐付けされていて、他の文書に対しては 無効
- 33. 電子署名 • 電子署名の実装には公開鍵暗号を用いる • 署名者は署名したい文書に暗号学的ハッシュ関数を適用し そのハッシュ値を秘密鍵で暗号化する • その他のユーザは署名を公開鍵で復号しハッシュ値との 一致を確かめる
- 34. 電子署名 • 電子署名の実装には公開鍵暗号を用いる • 署名者は署名したい文書に暗号学的ハッシュ関数を適用し そのハッシュ値を秘密鍵で暗号化する • その他のユーザは署名を公開鍵で復号しハッシュ値との 一致を確かめる • ビットコインはECDSA(楕円曲線DSA)と呼ばれる電子署名 スキームを利用している メッセージダイジェスト！
- 35. 識別情報としての公開鍵 • ビットコインでは公開鍵をユーザの識別情報として用いる • これによってユーザは好きなときに新しい人格を作成可能 • 実際には公開鍵は大きいためハッシュ値を用いる • 公開鍵のみからは現実世界の個人を特定できない
- 36. 非中央集権的な識別情報管理 • この仕組の上では、中央集権的な識別情報管理は不要 • 誰でも好きなときに識別情報を発行できる • これらの識別情報はアドレスと呼ばれる • 識別情報自体は匿名だが行動から特定される可能性はある • 6章で取り上げる
- 37. ハッシュポインタとデータ構造 • ハッシュポインタは暗号通貨を構成する上で重要なデータ構造 • 名前の通り、ポインタ+ データの暗号学的ハッシュで 構成される • 通常のポインタと異なり情報が書き換えられていないことを 確認可能 データ 𝐻( )
- 39. ブロックチェーン データ データ データ 前：𝐻 前：𝐻 前：𝐻 𝐻
- 40. ブロックチェーンのユースケース • 改竄開示ログ • 誰かがログを書き換えるとその変更が検出される データ データ データ 前：𝐻 前：𝐻 前：𝐻 𝐻
- 41. ブロックチェーンのユースケース • 改竄開示ログ • 誰かがログを書き換えるとその変更が検出される データ データ データ 前：𝐻 前：𝐻 前：𝐻 𝐻 リストヘッドを指すハッシュポインタを 安全な場所に保存する限り改竄を検知できる
- 42. Merkle木 • ハッシュポインタを使った二分木 • ブロックチェーンと同様に改竄を検知できる • あるブロックが木に含まれることの証明を対数時間で可能 • ソート済みであれば含まれないことの証明も対数時間で可能
- 43. Merkle木 データ データ データ データ 𝐻 𝐻 𝐻 𝐻 𝐻 𝐻
- 45. Goofycoin • Goofycoinは2つのルールを持つ 1. Goofyが好きなときにコインを鋳造することができる 2. コインを持つ人は誰でもそれを他人に送金することができる
- 46. Goofycoin コインの鋳造 • Goofyのコイン鋳造プロセス 1. 新しい一意なコインID(𝑢𝑛𝑖𝑞𝑢𝑒𝐶𝑜𝑖𝑛𝐼𝐷)を生成 2. 𝐶𝑟𝑒𝑎𝑡𝑒𝐶𝑜𝑖𝑛 [𝑢𝑛𝑖𝑞𝑢𝑒𝐶𝑜𝑖𝑛𝐼𝐷]という文字列を生成 3. 自分の署名用秘密鍵を使ってこの文字列の電子署名を計算 • この文字列とGoofyの署名をあわせたものが1つのコインになる
- 47. Goofycoin コインの送金 • コインの送金は暗号学的な操作を使って行う • コインの送金プロセス(Goofyがアリスに送金と仮定) 1. [アリスの識別情報]に[𝐻 ]を支払うという新しい声明を 作成する 2. 声明を表す文字列に署名する • この操作を終えるとアリスがコインの所有者になる
- 48. Goofycoin コインの送金 𝑝𝑘 𝑏𝑜𝑏に𝐻 を支払う 𝑝𝑘 𝑎𝑙𝑖𝑐𝑒に𝐻 を支払う 𝐶𝑟𝑒𝑎𝑡𝑒𝐶𝑜𝑖𝑛 𝑢𝑛𝑖𝑞𝑢𝑒𝐶𝑜𝑖𝑛𝐼𝐷 𝑠𝑘 𝑎𝑙𝑖𝑐𝑒によって署名 𝑠𝑘 𝑔𝑜𝑜𝑓𝑦によって署名 𝑠𝑘 𝑔𝑜𝑜𝑓𝑦によって署名
- 49. Goofycoin コインの送金 𝑝𝑘 𝑏𝑜𝑏に𝐻 を支払う 𝑝𝑘 𝑎𝑙𝑖𝑐𝑒に𝐻 を支払う 𝐶𝑟𝑒𝑎𝑡𝑒𝐶𝑜𝑖𝑛 𝑢𝑛𝑖𝑞𝑢𝑒𝐶𝑜𝑖𝑛𝐼𝐷 𝑠𝑘 𝑎𝑙𝑖𝑐𝑒によって署名 𝑠𝑘 𝑔𝑜𝑜𝑓𝑦によって署名 𝑠𝑘 𝑔𝑜𝑜𝑓𝑦によって署名 各ステップで正当な所有者 が正しい声明に署名してい ることを確認できる
- 50. Goofycoinのセキュリティ上の問題点 • Goofycoinでは二重支払いが可能 • 最初にアリスからボブへ送金処理を行う しかし、送金したことを他の誰にも公開しない • その後同じコインをチャックに支払う声明に署名する • ボブとチャックからはどちらも自身が正当な所有者に見える
- 51. Scroogecoin • Goofycoinにおける二重支払いの問題を解決する新しい通貨 Scroogecoinを考える • Scroogecoinではすべての取引の履歴を記録する追記専用台帳 を公開する • 取引が受け入れられるためには、台帳への書き込みが必要 • これによって二重支払いを防ぐ事ができる
- 52. Scroogecoin • 追記専用の台帳はブロックチェーンを用いて構築する • 各ブロックはそれぞれ一つの取引を格納する (実際には最適化のために複数の取引を格納する) • 個々のブロックは取引ID、取引の内容、前のブロックを指す ハッシュポインタから構成される • Scroogeは端のハッシュポインタに署名しブロックチェーンと 署名を公開する
- 53. Scroogecoin 取引内容 取引内容 取引内容 前：𝐻 前：𝐻 前：𝐻 𝐻 取引ID : 71 取引ID : 72 取引ID : 73
- 54. Scroogecoin • Scroogecoinでは、Scroogeが署名したブロックチェーンに 含まれている取引だけが取引とされる • 取引を記録するブロックにScroogeの署名があることを チェックすれば取引がScroogeに保証されているか確認可能 • Scroogeはすでに使われたコインを二重払いしようとする と取引を保証しないようにしなければならない
- 55. ブロックチェーンの必要性 • ハッシュポインタを用いたブロックチェーンは追記専用の 属性を保証する • Scroogeが既存の取引に変更を加えるとその後のすべての ブロックに影響を与える • Scroogeが発行するハッシュポインタを監視している限り 変更が加えられたことを簡単に補足できる
- 62. Scroogeの取引 • Scroogeには2種類の取引がある 1. CreateCoins 2. PayCoins
- 64. CreateCoins 取引ID : 73 タイプ : CreateCoins 作成されたコイン 番号 価値 受領者 0 3.2 0x……… 1 1.4 0x……… 2 7.1 0x……… coinID 73(0) coinID 73(1) coinID 73(2)
- 66. PayCoins • PayCoins取引はいくらかのコインを消費し、同じ価値を持つ 新しいコインを作る • 新しいコインは別の人のものになることがある • この取引はコインを払うすべての人が署名しなければならない
- 67. PayCoins • 取引が有効だと認められる4つの条件 1. 消費されるコインが有効である (コインが以前の取引で生成されている) 2. 消費されるコインが以前の取引で消費されていない (二重支払い防止) 3. この取引で破壊されるコインの価値の合計が 新しく作られるコインの価値と等しいこと 4. この取引で消費されるすべてのコインの所有者が この取引に有効な署名をすること
- 68. PayCoins 取引ID : 73 タイプ : PayCoins 消費されたcoinID : 68(1), 42(0), 72(3) 作成されたコイン 番号 価値 受領者 0 3.2 0x……… 1 1.4 0x……… 2 7.1 0x……… 署名
- 70. Scroogecoinの問題 • Scroogecoinはどのコインが有効なのかを人々が確認できる という意味では正しく機能している • 誰もがブロックチェーンを見てすべての取引が有効で 二重支払いが行われていないことを確認できる • 問題はScroogeの存在
- 71. Scroogecoinの問題 • ScroogecoinではScroogeが巨大な影響力を持つ • Scroogeは他人の署名を偽造できないため取引の偽造は不可能 • 以下のような振る舞いが可能 1. 一部の利用者の取引を承認しない 2. コインを好きなだけ鋳造可能 3. システムの停止