Bitcoin Coreは、ユーザーが承認した送金先に資金が暗号学的に紐付けられない可能性のあるトランザクションへの署名を防ぐ保護策を追加しました。9月25日にプロジェクトのマスター開発ブランチへマージされたこの変更は、部分署名Bitcoinトランザクション(PSBT)における狭い範囲の欠陥を対象とし、意図した出力を保護しないまま有効な署名が生成される恐れがありました。Bitcoin Optechは10月2日にこの更新を取り上げました。

この問題はユーザーの秘密鍵を露呈させるものではありません。その代わりに、別のリスクをもたらします。特定の条件下では、トランザクションの受信者が変更された後でも署名が有効なまま残る可能性があるのです。

SIGHASH_SINGLEの弱点の仕組み

Bitcoinのすべての署名にはsighashフラグが付いており、署名がトランザクションのどの部分にコミットするかを決定します。SIGHASH_SINGLEはこうした署名モードの一つで、入力をトランザクション内の対応する位置の出力にコミットさせるように設計されています。その位置に出力が存在しない場合、保護の破綻の仕方は使用されるビットコインの種類によって異なります。

レガシー入力の場合、出力が欠落しているケースでは固定のハッシュ値に対する署名が生成される可能性があります。Bitcoin Coreの開発者らは、同じ構造的条件が揃えば、その署名が同じ鍵が管理する他の未使用出力に対して再利用される可能性があると述べています。

SegWit v0トランザクションは、署名が依然として使用される特定のコインとその金額にコミットするため、より強い保護を維持しています。しかし、送金先の出力は紐付かないまま残る可能性があります。これはウォレットや署名デバイスにとって承認の問題を生みます。ソフトウェアはユーザーに一つの支払いを提示しながら、承認された受信者が変更されていないことを暗号学的に保証しない署を生成する恐れがあるのです。

Bitcoin Core、危険な署名リクエストを阻止

Bitcoin Coreは既にrawトランザクション署名インターフェースを通じてこのエッジケースを拒否していましたが、walletprocesspsbtコマンドを含むPSBTの経路では署名が可能なままでした。新しいコードはこのチェックをBitcoin Coreの共有署名作成ロジックに移動したため、同じ拒否がBitcoin Coreのすべての署名経路に適用されるようになり、影響を受けるレガシーおよびSegWit v0の入力の署名を防ぎつつ、同一PSBT内の他の有効な入力はそのまま処理されます。

PSBTは、ソフトウェアウォレット、ハードウェアデバイス、オフライン署名者間のトランザクション調整に広く使われています。トランザクション構築者は、秘密鍵の管理権限をそのシステムに渡すことなく、別の署名者に情報を渡すことができます。したがって、この修正は、ウォレット開発者が鍵のセキュリティとは独立に強制しなければならない境界、すなわち有効な暗号学的署名はユーザーが実際に承認したトランザクション詳細にコミットしなければならないという原則を強化するものです。

PSBTを定義するBitcoin Improvement Proposal 174は、すでに署名者に対して受け入れられない署名モードを拒否するよう指示し、代替が指定されていない場合はSIGHASH_ALLを推奨しています。Bitcoin Coreの変更は、この出力欠落の構成が署名段階に到達することを明示的に防ぎます。

修正を含む製品版リリースはまだない

ユーザーがこの保護策を含む製品版リリースを入手できるようにはなっていません。9月25日の変更はBitcoin Coreの開発ブランチにマージされたものであり、10月4日時点でプロジェクトが公開しているリリース一覧には修正済みバージョンの特定やバックポートの確認はありませんでした。バックポートは同じ保護策を既にリリース済みのバージョンに届けるものですが、一覧に現れるまで、この保護は開発用コードベースにのみ存在します。

そのため、ウォレット事業者やハードウェア署名の統合を手がける企業には、Bitcoin Coreのリリースによる下流での保護強化を待つのではなく、各自のSIGHASH_SINGLEリクエスト処理を見直すという、より差し迫った判断が課されています。

原文はCryptoSlateで公開されました。