仮想通貨ハードウェアウォレットの未来

The Future of Hardware Wallets

2019年6月8日から9日にかけて、アムステルダムで Breaking Bitcoin というカンファレンスが行われました。 本コラムは、公開された動画や書きおこしをもとに、その発表内容を追いかけ、Bitcoin のセキュリティに関する取り組みの最先端を知ろうという試みです。
発表内容を日本語で、かつ実際の事例などを交えて解説することで、少しでも皆様が 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）などです。それぞれ、チャネルに資金を送るため、チャネルを更新するため、そして以前の状態を無効にしたり、他の関係者に提供したりするという役割があります。

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

セキュリティについて考えるときは、ハードウェアウォレット以外の部分についてはハッキングされうると想定します。 攻撃者はユーザーと同時にチャネルを開き、資金を送るトランザクションを送信し、コミットメントトランザクションを再送し、チャネルをオープンにするとしましょう。

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

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

まとめ

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

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

【寄稿者情報】