『Bitcoinとプライバシー』@Bitcoin技術勉強会2015.07.20
•
11 likes•5,043 views
日本デジタルマネー協会さん主催で、Bitcoinのプライバシー（匿名性）・支払いチャンネル・HTTPSのセキュリティについてお話しました。
Recommended
More Related Content
Featured
Featured (20)
『Bitcoinとプライバシー』@Bitcoin技術勉強会2015.07.20
- 2. 今日のおはなし
- 3. アジェンダ 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. 対策
- 5. Bitcoin⇨匿名⇨犯罪⇨危険……？ Bitcoinの話題をすると「Bitcoinは匿名（とくめい）性が高いため、犯罪行 為に使われやすい！シルクロードでは違法薬物の売買に使われてい た！Bitcoinは危険だ！」とよく言われますが、そもそも ● 「匿名性」ってなんのこと？ ● 「Bitcoinは匿名性が非常に高い」って本当？ ● 匿名性が全くない方が送金システムとして優れているの？ といった疑問に正確に答えられる方は非常に少ないのではないでしょう か？また、少なからず誤解をされている方も多いような気がしています。 そこでまずは、これらの疑問について分析を行ってみましょう。
- 6. 送金システムの匿名性 Aさん (支払人) Bさん (受取人) この画像を1,000円で買わない？ いいよ〜。明日1,000円払うね〜。 どもっす。じゃあ画像送るね〜。 送金（支払）を行う際の一般的なやりとり ←のやりとりのうち、送金に関するどの情報も第三者 （赤の他人）に漏れないことが「匿名」である、というこ とといえるでしょう。 具体的には、 ● 支払人 = A（誰が） ● 受取人 = B（誰に） ● 送金額 = 1,000円（いくら） ● 支払日 = 明日（いつ） といった情報が第三者に全く漏れなければ匿名であ るといえます。 ※やり取りする当事者は（当然）知り得てもよい。 ※何を買ったのか、については送金システムの外の やり取りなので、ここでは考えない。
- 7. Bitcoinの匿名性 ● 支払人（誰が支払ったか）………△（弱い匿名性） ● 受取人（誰に支払ったか）………△（弱い匿名性） ○ 保有するアドレスは分かるが、個人情報とは直接結びつかない ○ 利用する取引所やウォレット、IPアドレスなどから推測可能 （特に公的機関であれば容易） ● 送金額（いくら支払ったか）……☓（匿名性なし） ○ Blockchainを参照すればすぐに分かってしまう ● 送金日時（いつ支払ったか）……☓（匿名性なし） ○ ブロックへの取り込み日時などからある程度予測可能 ⇨ Bitcoinは「擬似的な匿名性 (pseudo-anonymity)」しかない、と言われている 既存の送金システム（クレジットカード、銀行送金、手渡し etc.）と比べると、 匿名性は非常に低いといえます
- 8. そもそも匿名性は必要か？ いままでBitcoinの匿名性をみてきましたが、ではそもそも送金システムに匿名性は必要な のでしょうか？ このことを考えるために、匿名性の全くない支払いシステムを使うとどういったことが起きう るか考えてみましょう。 毎月定期的に受け取っている金額から、月 収が全世界にバレる。 収入が高いと： ● 友達からタカられる ● 身代金目的の誘拐被害に ● いつもの飲み屋で「儲かってんなら高 い酒飲めや」といわれる 収入が低いと： ● 周囲からバカにされる ● 彼女／彼氏から別れ話がっ 支払先と金額から、どんな品物を購入し たかが全世界にバレる ● 無駄遣いしてると家族に怒られる ● 恥ずかしいあんな雑誌やゲームやア イテムを買えない ● 生活習慣がバレる この例から分かるように、送金システムの 匿名性はプライバ シーと紙一重なのです！ したがって利用者のプライバシーを守るためには、匿名性を 高めることは非常に重要です。
- 10. CoinJoin 支払人や受取人の匿名性を向上させるサービス。 信頼できる中央集権的なサービスなしにBitcoin撹拌サービスを実現する方法。 Gregory Maxwellにより2013年8月に提案された。 実用的な実装としては、Blockchain.infoのShared Coinなどがある。 Bitcoinトランザクション Input Output 1BTC 1BTC 1BTC 1BTC 1BTC 1BTC ⇨実際のトランザクション
- 11. リング署名 支払人の匿名性を向上させる仕組みとして、リング署名を応用したものがある。 リング署名とは、複数人の署名人のうち、誰が署名したかは分からないが、そのうちの誰 かひとりが作成した署名であることを保証できるアルゴリズムです。 通常、ひとつの電子署名にはひとりの署名者（公開鍵）が対応するため、誰が送金を行っ たのか分かってしまいます。リング署名を使うと、複数の署名者のうち誰が送金したのか を隠匿することができます。 暗号通貨としての実装がCryptoNoteにより提案されている。CryptoNoteを採用する Bytecoin, Monero, DarkNote等により実装。 R.L. Rivest, A. Shamir, and Y. Tauman, How to Leak a Secret, ASIACRYPT 2001, LNCS 2248, pp. 552–565 (2001) 通常の電子署名 リング署名 署名人 電子署名 一対一に対応 電子署名 署名人 （複数） 電子署名作成 誰が署名したかは 分からない！ ? ちなみに論文のタイトルが「秘密の漏らし方 (How to Leak a Secret)」となっているのは、リング署名は自分の身元をバラさずに 内部告発をする最適な方法だから、ということらしい。
- 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 と でき、一連の鎖的な処理を閉じて「リングを作 る」ことができる。 ⇨電子署名の作成に対応
- 13. 秘匿トランザクション 送金額の匿名性を向上させるひとつの方策として、秘 匿トランザクション(Confidential Transaction) というも のがあります。 勝手にコインが増やされてしまわないよう、トランザク ションの入金額(Input)と出力額(Output)に不正がない かチェックしなければなりません。 Bitcoinではトランザクションに入力と出力の金額があら わに書かれているため、これを使ってチェックしていま す。 しかしながら、「入力額の合計 = 出力額の合計」だけを チェックすればいいことに注目すると、やり取りする金 額があらわに書かれていなくても不正チェックができま す！ Input Output 1BTC 1BTC 1BTC 1.8BTC 1.2BTC ←いくら送ったかバ レてしまう。 入力の合計額と 出力の合計額が 等しいかチェック→ 1BTC + 1BTC + 1BTC || 3BTC || 3BTC || 1.8BTC + 1.2BTC ? ←この部分だけチェックでき ればよい
- 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 氏の公開しているノート を参照ください。
- 15. 支払いチャンネル
- 16. Micropayment Channel 他の支払いチャンネルの基礎となっているものであり、非常に重要。 マルチシグネチャを用いた共有ウォレットや LockTime をうまく使うことで、無与信下で (trustlessに) オフチェインで送金することのできるアルゴリズム。 オフチェインで処理できるため、何万回送ろうとも手数料は厳密にゼロになることから、非 常に小さな額の支払い (=micropayment) に適しているとされる。 Micropayment Channelを使って送金する簡単な（抽象的な）手順： 1. Micropayment Channelを開く処理を行う 2. 送金トランザクションを作成し相手に渡す 3. 追加の送金が必要になったら、2.のトランザクションを適宜変更し、相手にトランザク ションを送り直す 4. 終わったらMicropayment Channelを閉じる処理を行う 以降のスライドでは、Aさん⇨Bさんへ送金する場合のやり方を解説します。
- 17. M.P.チャンネル (チャンネル開通) Aさん Bさん 1BTC 1BTC A&Bの マルチシグ ブロードキャスト 1BTC A&Bの マルチシグ 1BTC Aの アドレス Micropayment Channel 開通トランザクション 返金用（refund） トランザクション 電子署名添付 LockTime = 一週間 Aは、Bの署名済み返金用トランザク ションを受け取ってからM.P.チャン ネルの開通トランザクションをブロー ドキャストする。 （すぐに送ってしまうと、Bが突然い なくなった場合に共有ウォレットのコ インが誰にも取り出せなくなってしま うため） ⇨M.P.チャンネルの開通処理完了 Bが音信不通になった 場合に備えて保管
- 21. M.P.チャンネルのメリット・デメリット メリット： ● 検証が早い（トランザクションの正 当性のみチェックすればいいので、 一瞬） ● 第三者の信頼を必要としない ● 何回も送金を行う場合には、手数 料が激安になる（二回分の手数料 で何万回でも送れる） ● 最終的な送金額のみが公開され、 途中結果は秘匿されるため、ある 程度プライバシーが守られる デメリット： ● M.P.チャンネルを開いた特定の二 者間でしかやり取りできない ● はじめにBTCをデポジットしなけれ ばならないため、ある程度の余剰 資金が必要 ● 受取人もオンラインでなくてはなら ない ● トランザクション展性により、返金ト ランザクションが無効化されてしま う可能性がある ● 通常の送金と比べると、遥かに複 雑
- 22. Impulse 支払いチャンネルを用いることで、支払いチャンネル参加者以外の第三者のアドレスに対 する送金の検証が瞬時に行えるようなプロトコルです。BitPayが公開しています。 登場人物は ● Aさん：支払人 ● Bさん：決済事業者（BitPay） ● Dさん：受取人 で、AさんからDさんに、Bさんの仲介のもとに支払いを行います。 論文を読むと分りますが、基本的に決済事業者Bさんの信用が（ある程度）必要となってお り、正直微妙です。。。 なので、ここでは詳しくは解説しません。（気になる方は論文をお読みください） BitPay, Inter-Channel Payments a.k.a. “Impulse”, http://impulse.is/ (2015)
- 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の メリット／デメリットを思いつく限り列挙します。
- 27. HTTPSのセキュリティ
- 28. SSL (TLS) とは？ ※ここからはBitcoinより広い範囲に影響のある、SSL (TLS) のお話です。 SSL (Secure Socket Layer)とは、インターネット(TCP)通信を暗号化し、通信内容を秘匿 化するためのプロトコルです。 SSLの後継プロトコルとしてTLS (Transport Layer Security)があります。 が、“SSL”という名前があまりにも有名になりすぎてしまったため、TLSのことも便宜的に “SSL”といってしまうことが多いです。（紛らわしい！） ここでも“SSL”で統一します。 なお、SSL (狭義) には致命的な脆弱性(POODLE)が見つかっていますので、利用するこ とは推奨されません。TLSを使用してください。
- 29. SSL ✕ Bitcoin 安全でないSSL通信を行うと、通信内容が盗聴・改ざんされる可能性があります。 従来の使われ方ではせいぜいクレジットカード番号（怪しい購入行動をするとカードが無 効化され消費者は守られる）、ネット銀行のログインパスワード（不正利用の場合には組 戻し等が可能）程度しか盗めませんでした。 Bitcoinの登場により、文字通り「情報=カネ」な時代になりましたので、情報の漏洩は即カ ネの漏洩です。（※カネがインターネットを行き来してるイメージ） ● 取引所のパスワードが盗聴された⇨預けていたBitcoinはクラッカーのものです。日本 円もBitcoinに交換されてスッカラカンです ● 送金先Bitcoinアドレスが改ざんされた⇨商品を購入しようとして支払ったBitcoinはク ラッカーのものです ● Counterwallet.ioを改ざんされ、パスフレーズを外部に送信された⇨ウォレットの BitcoinもXCPもその他独自ジャンクコインもすべてクラッカーのものです
- 31. 対策 ● OSやブラウザは常にアップデートする ● 二段階認証は必ず設定する ○ 両方共スマホにはしない。通常ログインはPC、二段階認証はスマホで受け取る ように！ ● 万が一ハッキングの被害にあったとしても許容できる範囲までしかBitcoinや現金は 預けない。大部分は安全なウォレットに保管する！ ○ ペーパーウォレット、ハードウェアウォレットなどを利用。ウェブウォレットは論 外！ ● 喫茶店や空港などの公衆Wi-Fiではアクセスをしない ● 「SSLだから安全」とは限らない。過信しない ○ 緑色のバーが出ているサイトでも、暗号化の安全性は変わらない。企業・組織の 実在性証明（オフィスの存在確認）がされているかどうかだけ ● 大きな額を預けている取引所やウォレットではセキュリティチェックをし、リスクを把握 しておく（必要であれば運営者に報告を！） ● 常にセキュリティ関連の情報が入ってくるようにアンテナを張り巡らせておく
- 32. まとめ
- 33. まとめ ● プライバシー ○ Bitcoinを含む決済システムにおいては、利用者のプライバシーを守るためにも匿名性は必須 ○ Bitcoinは擬似的な匿名性 (pseudo-anonymity) しか持っていない ○ いくつかの改善案やアルゴリズムが提案されている ■ 撹拌サービス／コインジョイン……適当にコインを「かき混ぜる」ことで、履歴の追跡を困難にする ■ リング署名……電子署名の作成者の特定ができないようにする ■ 秘匿トランザクション……不正を防止しつつ、送金額を第三者に公開せずに済むアルゴリズム ● 支払いチャンネル ○ ブロックチェインに直接書き込まずとも、送金ができるアルゴリズムの総称（しかも無与信下で） ■ Micropaymentチャンネル……特定の二者間なら、オフチェインで無制限に送金を行える手法。支払いチャンネ ルのベースとなる考え方であり、非常に重要 ■ Impulse……決済事業者を仲介人として安全かつ瞬時に支払いの検証を行う手法 ■ Lightning Network……信頼できない第三者を仲介して送金を行う手法。 ○ いずれにしても、トランザクション展性の問題がつきまとう（←返金トランザクションを無効化されてしまう恐れがある） ■ OP_CHECKLOCKTIMEVERIFY の重要性 ■ Sighashタイプの改良 ● SSL/TLSセキュリティ ○ Bitcoinの登場により「情報=カネ」な時代となったため、情報の盗聴や改ざんには、いままでより気をつけなければならな い！ ○ アップデートは怠らない。二段階認証は必ず設定。SSLを使っていても公衆無線LANはキケン！盗難リスク削減の努力 は怠らない。セキュリティ関連情報は常に収集。