ビットコインウォレットの未来

2019年6月8日から9日にかけて、アムステルダムでBreaking Bitcoinというカンファレンスが行われました。

本コラムは、公開された動画や書きおこしをもとに、その発表内容を追いかけ、ビットコインのセキュリティに関する取り組みの最先端を知ろうという試みです。発表内容を日本語で、かつ実際の事例などを交えて解説することで、少しでも皆様がビットコインの仕組みや最新の研究について詳しくなるための一助になれることを願います。

本日は、ハードウェアウォレットについて、安全や改善点の最新研究をお伝えします。

ハードウェアウォレットは現在ここまで対応可能に！

ハードウェアウォレットは、キーを安全に保管しつつ、コインを送信したり、署名したりする機能があります。すべての入力はユーザーが意図したものでなくてはなりません。

対応するアドレスがあれば、コインを受け取ることもできます。ウォレットによってはマルチシグに対応しているでしょう。価値の有無はともかく、草コインにも対応しているかもしれません。

また、便利な機能として、coinjoin、カスタムスクリプト、サイドチェーンをサポートしていれば、便利なウォレットとして使えます。しかし、現時点ではハードウェアウォレットはcoinjoinには対応できません。ライトニングは素晴らしい仕組みですがトリッキーな側面もあり、出力と入力が束になるため、難しい部分もあります。

coinjoinの重要な部分としては、外部からの入力があることです。ハードウェアウォレットでcoinjoinを素朴に実装した場合、コインが盗まれる可能性があります。

そこで、ここではcoinjoinとライトニングに絞って話を続けたいと思います。

coinjoinによる攻撃とは？

coinjoinの詳しい仕組みについては、ここでは割愛します。

覚えておくべきこととしては、まずコインの入力をcoinjoinサーバーに登録する必要があること。次にcoinjoinトランザクションに署名し、プロトコル内で失敗した場合はリトライをすること。そして、サーバーがcoinjoinトランザクションをブロードキャストできるよう、署名を返すこと、などです。,

リトライが発生する理由ですが、誰かがDoS（サービス拒否攻撃）を行っている場合、coinjoinトランザクションの署名が失敗する可能性があります。そういった場合には同量の入力でリトライするのが一般的です。

では、悪意を持ったウォレットのことを考えてみましょう。サーバーなどではなく、一般的なユーザーが使うクライアントアプリケーションです。

通常、coinjoinで一般的なものとして、ユーザーからの2つの入力を取り込むケースを考えます。このときハードウェアウォレットは、実はどの入力が誰のものか、正確に判別することができません。したがって署名するときには、他のソフトウェアを信頼するだけになっています。

攻撃は、まず2つのユーザー入力のうち1つに関してユーザー部分を書き換え、それに対しハードウェアウォレットに署名をさせます。悪意あるソフトウェアは次にcoinjoinトランザクションが失敗したように見せかけ、同じトランザクションを再送します。このとき、2番目のユーザー入力も書き換えます。

ハードウェアウォレットには、どの入力が自分の入力だったのか判別する方法がないため、これを異常なものと認識することができないのです。Trezorはachow101と対応を進めていますが、インプットの証明には送金証明（SPV proof）が必要です。

有効な防止策は”所有権”！

SLIP-0019として、所有権の証明が提案されています。すべての入力に対し証明を行うことを可能とし、それにはキーで署名する必要があるというものです。これによって、coinjoinトランザクションに対する支払いには必ず自分の所有権を示す必要が生じるため、サービス拒否攻撃（DoS）が防げます。攻撃者は自身のUTXOが必要になるからです。

また、証明に関しては、ハードウェアウォレット自体でのみ署名できるようにし、そして一意のトランザクション識別子も持ちます。この証明を他のcoinjoinラウンドに持ち越すことはできず、所有している証明にもなります。これは、マルチシグまたはMuSig集約にも拡張可能です。

課題

Schnorr署名については議論が必要でしょう。キー集約にあたり、署名は単一キーのものになりますが、そうなるとサイズが大きくなります。このときの懸念としては、coinjoinにおけるプライバシーの漏洩が考えられます。他の参加者よりもサイズが大きな署名が存在することで、ラウンド間で同じユーザーのことを特定しやすくなるからです。

これに対抗する手段としては、schnorrとtaprootでは固定サイズの証明を作れる可能性があり、それが解決策になりえるかもしれません。

また、ライトニングの支払いを行ったり受け取ったりするためには、常に接続されている必要があります。チャネルがオープンになっているか、あるいは閉じているか、エラーになったのかを知るため、ブロックチェーンを監視しなくてはなりません。

ライトニングプロトコルには多くの秘密情報があります。オンチェーンキー、チャネルキー、失効の秘密（devocation secrets）などです。それぞれ、チャネルに資金を送るため、チャネルを更新するため、そして以前の状態を無効にしたり、他の関係者に提供したりするという役割があります。

これらすべてのキーをハードウェアウォレットに保管することは、簡単でしょうか。あまり簡単ではない、というのが現在の状況です。

セキュリティについて考えるときは、ハードウェアウォレット以外の部分についてはハッキングされうると想定します。

攻撃者はユーザーと同時にチャネルを開き、資金を送るトランザクションを送信し、コミットメントトランザクションを再送し、チャネルをオープンにするとしましょう。

仮想的なチャネルを使って資金を盗まれてしまうというケースを考えると、安全のためには、チャネルが実際に開いていることを証明しなければなりません。また、すべてのブロックはハードウェアウォレットに送信し、トランザクションがブロックに含まれていないことを確認する必要もありますが、簡単ではありません。

ブルームフィルターを使うことも可能ですが、送金証明やライトクライアントは必ずしもユーザーフレンドリーではない、というのもまた事実です。ただしフィルターはハードウェアウォレットに役立つので、使用する際にはブロック全体を解析して、ブロックが閉じられたかを確認するべきでしょう。

まとめ

以上、ハードウェアウォレットに関する最新研究の発表を簡単にまとめさせていただきました。ご興味がある方は、ここでは書ききれなかった内容もあるので、講演資料や書きおこしをご覧になって頂くことをお勧めします。

記事中の表現については講演資料を筆者なりに読み解きつつ、前後で独自の解説を加えておりますが、なにぶん新しい技術に関する内容ですので、もしも間違いなどございましたらお気軽にご指摘くださいませ。（特に技術的な指摘は大歓迎です）