『Bitcoinとプライバシー』@Bitcoin技術勉強会2015.07.203. アジェンダ
1. Bitcoinとプライバシー
a. 基礎知識
b. 撹拌サービス
c. コイン・ジョイン
d. リング署名 (CryptoNote)
e. 秘匿トランザクション
2. 支払いチャンネル
a. Micropayment Channel
b. Impulse
c. Lightning Network
3. SSL/TLSのセキュリティ
a. SSL/TLSとは?
b. SSL×Bitcoin
c. 某国内Bitcoin取引所の話
d. 対策
7. Bitcoinの匿名性
● 支払人(誰が支払ったか)………△(弱い匿名性)
● 受取人(誰に支払ったか)………△(弱い匿名性)
○ 保有するアドレスは分かるが、個人情報とは直接結びつかない
○ 利用する取引所やウォレット、IPアドレスなどから推測可能
(特に公的機関であれば容易)
● 送金額(いくら支払ったか)……☓(匿名性なし)
○ Blockchainを参照すればすぐに分かってしまう
● 送金日時(いつ支払ったか)……☓(匿名性なし)
○ ブロックへの取り込み日時などからある程度予測可能
⇨ Bitcoinは「擬似的な匿名性 (pseudo-anonymity)」しかない、と言われている
既存の送金システム(クレジットカード、銀行送金、手渡し etc.)と比べると、
匿名性は非常に低いといえます
12. リング署名(アルゴリズム概要)
Fig. 1
リング署名の基本動作。ここで各変数は以下のように
定義されている。
● v, x_1, x_2, …:乱数
● g_1, g_2, …:落とし戸函数(公開鍵暗号)
● E_k:自明でない双方向函数(共有鍵暗号)
x_i→y_iの計算は世界中の誰でもできるが、逆の計算
(y_i→x_i)はg_iの秘密鍵を知る署名者のみ可能。
g_1, …の秘密鍵をひとつも知らないと、最終的に得ら
れるzはランダムとなってしまう。
Fig. 2
g_iのうち、少なくともひとつの秘密鍵を知る署
名者は、x_2の値を適切にいじることで v = z と
でき、一連の鎖的な処理を閉じて「リングを作
る」ことができる。
⇨電子署名の作成に対応
14. 秘匿トランザクション (基本アイディア)
問題:「a + b = c」であることを、a, b, c の値を知らせることなく、第三者が検証できるよう
にするには?
一見すると無理ぽですが、実は離散対数問題の性質をうまく利用す
ることで実現可能です。
ここではビットコイナーに親しみ深い (?)楕円曲線暗号(ベースポイント
G)を用いて説明します。
まず、
a + b ≡ c ⇔ (a+b) G = c G ⇔ aG + bG = cG
が成り立ちます。
従って「a+b=c」を示したいのであれば、代わりに aG, bG, cG の値を
提示し、「aG + bG = cG」であることを示せれば(ほぼ)十分であるこ
とが分かります。
ここで楕円曲線における離散対数問題の困難性を思い出すと、 aG,
bG, cGの値から a, b, c を導き出すことは非常に難しいですから、も
との入出力額 a, b, c の情報は守られることが分かります。
“≡” は考える楕円曲線の持つ位数を
法として合同、という意味
a + b = c
aG + bG = cG
変
換
も
と
の
値
の
復
元
は
不
可
能
なお、いくつかセキュリティ上・実装上の問題がありますので、このよう
な単純なやり方では NGです。
何が問題なのか、どうすれば解決できるのかといった詳細については
Gregory Maxwell 氏の公開しているノート を参照ください。
16. Micropayment Channel
他の支払いチャンネルの基礎となっているものであり、非常に重要。
マルチシグネチャを用いた共有ウォレットや LockTime をうまく使うことで、無与信下で
(trustlessに) オフチェインで送金することのできるアルゴリズム。
オフチェインで処理できるため、何万回送ろうとも手数料は厳密にゼロになることから、非
常に小さな額の支払い (=micropayment) に適しているとされる。
Micropayment Channelを使って送金する簡単な(抽象的な)手順:
1. Micropayment Channelを開く処理を行う
2. 送金トランザクションを作成し相手に渡す
3. 追加の送金が必要になったら、2.のトランザクションを適宜変更し、相手にトランザク
ションを送り直す
4. 終わったらMicropayment Channelを閉じる処理を行う
以降のスライドでは、Aさん⇨Bさんへ送金する場合のやり方を解説します。
23. Lightning Network
Micropayment Channelは、支払いチャンネルを開いた二者間のみ のやり取りに限定されています。
そのため、違う人に送金する際には、 その人ごとに支払いチャンネルを開く必要 があり、非効率です。
そこで、支払いチャンネルをバケツリレー的にいくつも経由することで、 誰か経由で支払いチャンネルが繋がってさ
えいれば送金ができるプロトコル をJ. Poonらが開発し、Lightning Networkと名づけました。
Lightning Networkの一つの利点として、ブロックチェインの データ量を大幅に削減 することができることがあげら
れます。これにより、現在問題になっている スケーラビリティの問題を解決 できるのではないか、と言われていま
す。
従来の方法では支払いを行うたびにトランザクションがブロックチェイン上に書き込まれます。
一方でLightning Networkを用いれば、支払いチャンネルの開通・閉鎖トランザクションというたった二つのトランザ
クションを定期的に(例えば数カ月に一回)ブロックチェイン上に書き込むだけで、ブロックチェインを利用せずとも
支払いを何回でも行うことができます。
通常の支払い方法
支払いトランザクション
Lightning Networkブロックチェイン
支払いごとに毎回ブロック
チェインへトランザクションを
書き込む! 支払いチャンネル
送金
を経由して支払い
ブロックチェイン
支払いチャンネル
の開通・閉鎖時の
み書き込み
24. Lightning Network (中継払いの問題点)
このスライド以降ではLightning Networkの基礎的なアイディアの解説を行います。
より詳しく知りたい方はPoon氏によるプレゼンスライドスライド①・②、さらにより詳しく知り
たい方は論文(現時点で草稿)をご覧ください。
前のスライドで述べたように、
Lightning Networkのキモは、支払
いを第三者を中継して行うことで
す。しかしながら信頼のできない第
三者を中継する場合には第三者が
「持ち逃げ」してしまう可能性があり
ますので、持ち逃げされないような
対策を講じる必要があります。
さんを経由して支払うよ〜!
支
払
い
チ
ャ
ン
ネ
ル
支
払
い
チ
ャ
ン
ネ
ル
1BTC
にBitcoinを支払わず
持ち逃げしてやろう。
フヒヒヒヒ……。
Aさん
Bさん
Cさん
25. Lightning Network (基礎アイディア)
支
払
い
チ
ャ
ン
ネ
ル
支
払
い
チ
ャ
ン
ネ
ル
そこで、中継人に持ち逃げされないように 以下のよう
な手順を踏む。
1. 受取人は秘密情報 R を用意し、適当なハッ
シュ函数を用いてハッシュ値 H = Hash(R) を
計算する。
2. 支払人は、使用時に①Bさんの電子署名と②R
の情報の両方が必要なアドレス宛てに送金す
る。
3. Bさんは、使用時に①Cさんの電子署名と②R
の情報の両方が必要なアドレス宛に送金す
る。
4. Cさんは、Bさんから受け取ったトランザクション
に自分の電子署名とRの情報を付与したもの
をブロードキャスト(実際にはクリアリング)す
る。
5. Bさんは、Cさんのブロードキャストしたトランザ
クションに含まれるRの情報を用いて、Aさんか
ら受け取ったトランザクションをブロードキャス
ト(実際にはクリアリング)する。
Aさん Cさん
Bさん
RH
H = Hash(R)
①Bの電子署名、②Rの値
が必要なトランザクション
H
H
①Cの電子署名、②Rの値
が必要なトランザクション
基本的なアイディアはこれだけですが、実際にBitcoinのscript
でこれを表現しようとすると非常に複雑です。。。
具体的には一回支払うごとに10個以上のオフライントランザク
ションを作らないといけません。
※詳細は論文をお読みください。
26. L.N. v.s. M.P. Channel
メリット:
● 直接支払いチャンネルを開いてい
ない相手ともやり取りができる
● 副作用として、ブロックチェインへ書
き込まなければいけないデータの
減少が期待できる
● 銀行のクリアリング・システムのよ
うなものを無与信下で (trustless
に) 実装できる
デメリット:
● 手続きが非常に複雑
○ バグの温床となる可能性
● トランザクション展性対策のために
Bitcoinのscript自体にさらに追加
の修正が必要(M.P.チャンネルで
も必要だが、さらなる改変が必要)
● 常にインターネットに接続し、相互
監視をする必要がある
Micropayment Channelと比べた場合の、Lightning Networkの
メリット/デメリットを思いつく限り列挙します。
28. SSL (TLS) とは?
※ここからはBitcoinより広い範囲に影響のある、SSL (TLS) のお話です。
SSL (Secure Socket Layer)とは、インターネット(TCP)通信を暗号化し、通信内容を秘匿
化するためのプロトコルです。
SSLの後継プロトコルとしてTLS (Transport Layer Security)があります。
が、“SSL”という名前があまりにも有名になりすぎてしまったため、TLSのことも便宜的に
“SSL”といってしまうことが多いです。(紛らわしい!)
ここでも“SSL”で統一します。
なお、SSL (狭義) には致命的な脆弱性(POODLE)が見つかっていますので、利用するこ
とは推奨されません。TLSを使用してください。
31. 対策
● OSやブラウザは常にアップデートする
● 二段階認証は必ず設定する
○ 両方共スマホにはしない。通常ログインはPC、二段階認証はスマホで受け取る
ように!
● 万が一ハッキングの被害にあったとしても許容できる範囲までしかBitcoinや現金は
預けない。大部分は安全なウォレットに保管する!
○ ペーパーウォレット、ハードウェアウォレットなどを利用。ウェブウォレットは論
外!
● 喫茶店や空港などの公衆Wi-Fiではアクセスをしない
● 「SSLだから安全」とは限らない。過信しない
○ 緑色のバーが出ているサイトでも、暗号化の安全性は変わらない。企業・組織の
実在性証明(オフィスの存在確認)がされているかどうかだけ
● 大きな額を預けている取引所やウォレットではセキュリティチェックをし、リスクを把握
しておく(必要であれば運営者に報告を!)
● 常にセキュリティ関連の情報が入ってくるようにアンテナを張り巡らせておく
33. まとめ
● プライバシー
○ Bitcoinを含む決済システムにおいては、利用者のプライバシーを守るためにも匿名性は必須
○ Bitcoinは擬似的な匿名性 (pseudo-anonymity) しか持っていない
○ いくつかの改善案やアルゴリズムが提案されている
■ 撹拌サービス/コインジョイン……適当にコインを「かき混ぜる」ことで、履歴の追跡を困難にする
■ リング署名……電子署名の作成者の特定ができないようにする
■ 秘匿トランザクション……不正を防止しつつ、送金額を第三者に公開せずに済むアルゴリズム
● 支払いチャンネル
○ ブロックチェインに直接書き込まずとも、送金ができるアルゴリズムの総称(しかも無与信下で)
■ Micropaymentチャンネル……特定の二者間なら、オフチェインで無制限に送金を行える手法。支払いチャンネ
ルのベースとなる考え方であり、非常に重要
■ Impulse……決済事業者を仲介人として安全かつ瞬時に支払いの検証を行う手法
■ Lightning Network……信頼できない第三者を仲介して送金を行う手法。
○ いずれにしても、トランザクション展性の問題がつきまとう(←返金トランザクションを無効化されてしまう恐れがある)
■ OP_CHECKLOCKTIMEVERIFY の重要性
■ Sighashタイプの改良
● SSL/TLSセキュリティ
○ Bitcoinの登場により「情報=カネ」な時代となったため、情報の盗聴や改ざんには、いままでより気をつけなければならな
い!
○ アップデートは怠らない。二段階認証は必ず設定。SSLを使っていても公衆無線LANはキケン!盗難リスク削減の努力
は怠らない。セキュリティ関連情報は常に収集。