Coldcard ウォレットのエントロピー欠陥と約9000万ドルの損失：「絶対に安全」とされたハードウェアが突きつけた重大な警告

7月30日、Bitcoin のブロックチェーン上で非常に異例な送金がまとまって確認されました。

最初に注目を集めたスイープは、わずか41分間で行われました。その間に1,196のアドレスから1,082.65 BTCが移動しています。その後、Galaxy Research は関連しているとみられる別の2回の動きを確認しました。8月2日までに3回の合計は約1,367.05 BTC、当時の価格で約8,860万ドルに達し、4,585のアドレスが関係していました。

これらの数字は、Galaxy Research の公開アップデート、CoinDesk のオンチェーン追跡、The Hacker News の技術解説から相互に確認できます。

これらのウォレットには共通点がありました。関連するシードは、Coinkite の Coldcard ハードウェアウォレットで生成されたとみられています。

影響を受けた多くの端末は長期間オフラインで、リカバリーフレーズもクラウドにアップロードされていませんでした。問題はもっと前の段階にありました。ウォレット作成時、本来使われるはずだったハードウェアの真性乱数生成器が利用されていなかったのです。攻撃者はリカバリーフレーズを盗む必要すらありません。生成され得る候補を計算し、それに対応するアドレスをブロックチェーン上で探せばよかったのです。

ハードウェアウォレットで最も防ぎにくい事故の一つが、このタイプです。端末はずっと引き出しに保管され、秘密鍵も実際に端末の外へ出ていなかったかもしれません。それでも、秘密鍵が最初から十分にランダムでなければ、その後のエアギャップ、セキュアエレメント、耐タンパー設計では弱点を補えません。

資料と結論の範囲

一次確認資料：COLDCARD Mk3 Seed Generation Warning、Version History、BIP-0039: Mnemonic code for generating deterministic keys。

本記事における COLDCARD の低エントロピー欠陥、影響を受けるファームウェア、安全な移行に関する検証可能な事実は、上記の公式資料または規制関連資料を基準としています。実際のサービス提供状況、料金、利用資格、地域対応については、利用申請時点の発行元またはプラットフォームの最新ページを確認してください。

資産移行は信頼できる端末上で行い、送金先アドレスを直接確認する必要があります。個別事例の損失額については、公式確認と第三者分析を区別する必要があります。上記の一次資料で直接開示されていないユーザー体験、成功率、費用比較、トレンド判断は分析または推論であり、関係機関から個別事例について公式確認されたものではありません。

現時点で確認されていること

Coldcard の開発元 Coinkite は、2021年から2026年7月までに公開された一部のファームウェアに低エントロピー問題が存在したことを認めています。同社は、影響を受けるユーザーに新しいシードを生成し、資金を新しいアドレスへ移すよう求めています。Coinkite のセキュリティ告知で示された修正版は、Mk2/Mk3 4.2.0、Mk4/Mk5 標準版 5.6.0、Q 標準版 1.5.0Q、Edge 系列の 6.6.0X および 6.6.0QX です。

Block の Bitcoin エンジニアリングおよびセキュリティチームも独立した分析を行いました。技術レポートでは、問題を乱数呼び出しチェーンまで追跡しています。ウォレットのシード生成時、本来は STM32 チップのハードウェア乱数生成器を呼び出すはずでしたが、実際には MicroPython 内蔵のソフトウェア疑似乱数生成器 Yasmarang に到達していました。

ファームウェアの欠陥もオンチェーン上のスイープも実在しますが、両者の因果関係はまだ完全には閉じていません。Galaxy は、手数料パターン、釣り銭処理、バッチ送金の構造、導出パスなどから関連取引を特定しています。現時点では、「特定の被害者の弱いシードを再構築し、それを資金が消えたアドレスと一対一で一致させる」全工程を公開したレポートはありません。

したがって、より正確な表現は次のとおりです。研究者は、秘密鍵をオフラインで列挙可能な規模まで弱め得る Coldcard ファームウェアの欠陥を発見し、それと時間的・行動的に強く一致する複数回の不審な資金スイープを観測しました。1,367.05 BTC のすべてが「この欠陥によって盗まれたことが確認された」と断定するには、証拠があと一段足りません。

バグは乱数呼び出しチェーンに潜んでいた

Coldcard にはもともと STM32 のハードウェア RNG を直接読み取るコードがあり、対応する Python インターフェースは ckcc.rng_bytes() でした。

2021年、Coldcard は楕円曲線関連コードの移行と libNgU の導入に伴い、新規ウォレット用の乱数インターフェースを ngu.random.bytes() に変更しました。この変更を通じて問題がファームウェアに入り込みました。

本番設定では、MICROPY_HW_ENABLE_RNG は 0 と定義されていました。Coldcard には独自のハードウェア RNG ラッパーがあり、MicroPython 側でもう一つ実装する必要がなかったためです。しかし libNgU のチェックは #ifndef を使用しており、このマクロが定義されているかどうかだけを確認し、値が0以外かどうかまでは見ていませんでした。

コードはコンパイルでき、端末も正常に起動しました。しかし最終リンク時、rng_get() は Coldcard が想定したハードウェア実装に結び付かず、MicroPython の Yasmarang フォールバックへ接続されました。関連コードとコミット履歴は Coldcard のファームウェアリポジトリで確認でき、Block のレポートは呼び出し経路全体を段階的に分解しています。

Yasmarang は一見ランダムに見える数値を生成しますが、ウォレットのマスターキーに使うための暗号学的に安全な乱数生成器ではありません。初期状態は主に、チップ UID の下位32ビット、SysTick タイマー、RTC 時刻レジスタから構成されます。

チップ UID は端末識別子にすぎず、秘密情報ではありません。タイマー状態も物理的ノイズとは異なり、これらの入力同士に相関がある可能性もあります。生成器は初期化後、新しいランダム情報を継続的に取り込むこともありません。端末状態、起動時刻、過去の呼び出し回数をある範囲まで絞り込めれば、その後の出力を別のコンピューターで再現できます。

後段で生成結果にハッシュをかけても、この問題は解決しません。候補入力が1万通りなら、SHA-256 を通しても候補出力は1万通りのままです。結果がより均一に見えても、探索空間そのものが広がったわけではありません。BIP-39 のチェックサムは形式確認のためのものであり、リカバリーフレーズの実効エントロピーを増やしません。

40ビットと72ビットでは、どれほど違うのか

BIP-39 仕様では、リカバリーフレーズの初期エントロピーを128〜256ビットとしています。一般的な12語のフレーズは128ビット、24語なら256ビットです。

Coinkite の旧ファームウェアに対する初期推定では、Mk2/Mk3 のシード生成における実効探索空間は約40ビット、Mk4/Mk5/Q は約72ビットとされています。

40ビットなら候補は約1.1兆通りです。多く見えますが、128ビットとはまったく桁が違います。候補空間の差は約 2^88 倍です。さらに端末モデル、チップ UID、起動タイミング、一般的な導出パスなどで範囲を狭められれば、オフライン列挙はもはや机上の話ではありません。

後期モデルには追加の処理があります。Mk4 は起動時にセキュアエレメントから得た乱数値を混ぜますが、ハッシュ後にコードが保持するのは4バイトだけで、この32ビットを Yasmarang の状態語の一つに置き換えています。Block は、他の状態と呼び出し履歴が既知なら、セキュアエレメントが区別できる出力ストリームは最大 2^32 本だと評価しています。未知のタイマー状態をかなり寛大な上限で見積もっても、候補空間は 2^73.3 未満です。

ただし、これを単純に「Mk4 は72ビットの安全性を持つ」と表現するべきではありません。Block 自身も、2^73.3 は比較的緩い候補空間の上限にすぎず、標準的な意味での73ビットの暗号学的安全性ではないと注意しています。実際の解析コストは、UID 情報、起動時刻、過去の呼び出し回数、アドレス導出、検証速度によって変わります。現時点で完全な公開クラッキングベンチマークはありません。

確実に言えるのは、後期モデルは Mk2/Mk3 より状況が良いものの、Coldcard が本来目標としていた128ビットには届いていないということです。そのため Coinkite は、これらのユーザーにもシードの交換を求めています。

影響を受けるのは端末ではなく、シードそのもの

確認時に最も起こりやすい間違いは、現在端末に入っているファームウェアだけを見ることです。

本当にリスクを決めるのは、そのリカバリーフレーズを最初に生成したファームウェアのバージョンです。現在 Mk3 を 4.2.0 に更新しても、5年前に生成されたフレーズに後からランダム性が加わるわけではありません。同じフレーズを Ledger、Trezor、ソフトウェアウォレットに取り込んでも意味はありません。弱点はシードそのものに埋め込まれています。

ここではバージョン体系にも注意が必要です。標準版と Edge は別のリリースラインです。古い Edge のバージョン番号が 5.6.0 より大きいという理由だけで、修正済みとは判断できません。正確な対象範囲は、Coinkite の最新告知と公式バージョン履歴で確認する必要があります。

Coinkite は、TAPSIGNER、OPENDIME、SATSCARD については別のコードベースを使っており、今回の欠陥の影響を受けないとしています。

ウォレットがオフラインなのに、なぜ攻撃者は資金を動かせたのか

ハードウェアウォレットは秘密鍵を保存し、取引に署名します。乱数が適切なら、遠隔から秘密鍵を取得するのは確かに非常に困難です。

今回の攻撃経路は、端末自体を回避しました。攻撃者は自分のコンピューター上で考え得る乱数状態を列挙し、候補のリカバリーフレーズを生成し、対応する拡張公開鍵や一般的なアドレスを導出して、公開されている Bitcoin ブロックチェーン上で残高の有無を確認できます。

一致するアドレスが見つかれば、攻撃者が計算した秘密鍵はウォレット内の秘密鍵と完全に同一です。攻撃者は元の端末へ接続することなく、PIN を知らなくても、自分で署名して取引をブロードキャストできます。したがって「端末は一度もインターネットに接続していない」という事実は、この攻撃を否定する材料にはなりません。候補秘密鍵の探索自体が完全にオフラインで実行できるためです。

長期間動かしていない資金も、それだけで安全になるわけではありません。弱いシードのリスクに有効期限はありません。研究内容が公開され、計算コストが下がれば、以前は採算が合わなかった探索が現実的になる可能性があります。長期間休眠し、残高が大きいアドレスほど、むしろ攻撃対象として魅力的です。

オンチェーン上の4,585アドレスをどう理解すべきか

Galaxy Research が8月2日時点でまとめた主なデータは次のとおりです。

最初の2ラウンドでは、固定的な手数料パターンと似たバッチ処理方式が使われています。同一の運用者だった可能性もあれば、同じツールを使用しただけの可能性もあります。第3ラウンドでは集約先アドレスと出力構造が変わりました。Galaxy はオンチェーン情報だけでは判断できないとして、3ラウンドすべてを同一攻撃者に帰属させてはいません。

アドレス数をそのまま被害者数に置き換えることもできません。一人が複数のアドレスを持つことがあり、一つのリカバリーフレーズから多数の受取アドレスを生成できます。逆に、研究者がデフォルトの導出パスしかスキャンしていなければ、同じウォレット内の別の資金を見落としている可能性もあります。

オンチェーン帰属にはもう一つ本質的な制約があります。ウォレット所有者が自発的に資金を移行した場合、その取引形式は攻撃者によるスイープと似ることがあります。Galaxy の判断は、取引フィンガープリント、導出パス、被害報告を組み合わせたモデルに基づいており、ブロックチェーン上に「盗難」というラベルが直接存在するわけではありません。そのため、1,367.05 BTC は「観測された疑似関連規模」と表現する方が正確です。

コードは5年間公開されていたのに、なぜ誰も気付かなかったのか

Coldcard のファームウェアは以前から公開されており、ハードウェア乱数生成の実装も確かに存在していました。過去のレビューでは TRNG コード自体は確認できても、実際のウォレット作成時に最終的にその実装が呼ばれるかどうかまでは検証されていませんでした。

このバグは複数の層をまたいでいました。ウォレット生成関数でインターフェースが変わり、libNgU のコンパイルマクロ確認が不十分で、MicroPython には同じ役割を持つソフトウェアフォールバックがありました。個別に見れば、どの部分も特別目立つものではありません。プログラムは正常にコンパイルされ、端末も正常に動き、出力が単純に繰り返されることもありませんでした。実際のビルド結果をもとにシンボル解決と最終呼び出し経路まで追跡して初めて問題が明らかになります。

一般的な乱数テストでも発見できなかった可能性があります。非暗号学的 PRNG でも、分布が均一で隣接値が重複しないデータを生成できます。問題は「ランダムに見えない」ことではなく、内部状態を推定できることです。

Coinkite のホットフィックスでは、ビルド時の RNG シンボルチェックが追加されました。誤った実装が再びファームウェアへ入れば、ビルド自体が失敗します。公式の技術的な事後検証でも、過去の確認では期待する TRNG が存在していることは確認していた一方、ウォレット生成パスが最終的にどの実装へ解決されるかまでは確認していなかったと認めています。

オープンソースであることには、依然として価値があります。今回、問題を迅速に特定し、過去のコミットまで検証できたのは、コードが公開されていたからです。ただし「誰でも監査できる」と「すべての重要な安全経路がすでに監査済み」は同じではありません。ハードウェアウォレットでは、再現可能ビルドは出発点にすぎず、シード生成、署名、バックアップに関する呼び出しチェーンもエンドツーエンドで検証する必要があります。

マルチシグはリスクを下げられるが、鍵の生成元が重要

2-of-3 のマルチシグでは、攻撃者が弱い秘密鍵を1本復元しただけでは資金を動かせません。もう1本の署名鍵が必要です。残りの鍵が異なるメーカー、異なるコードベース、独立した乱数源で生成されていれば、一つのメーカーに固有のシステム上の欠陥をマルチシグで防げます。

しかし、影響を受けた Coldcard 3台を組み合わせてマルチシグにしても、問題が自動的に解決するわけではありません。攻撃者が署名閾値を満たす数の弱い鍵を復元できれば、資金は依然として移動可能です。Block のレポートも明確に、署名閾値を構成する中に十分な数の安全な端末が必要だと述べています。

一般ユーザーにとっては、マルチシグは複雑であればあるほど良いわけでもありません。descriptor、導出パス、端末フィンガープリント、バックアップの不足は、復元失敗につながります。完全な復元訓練をしたことがなく、単にチュートリアルに従って複数端末を組み合わせただけなら、運用リスクがシングルシグより低いとは限りません。

今どう移行すべきか

上記の表にあるファームウェアでシードを生成し、その際に十分な独立したサイコロエントロピーを加えておらず、強力かつ一意の BIP-39 passphrase も使用していなかった場合、そのシードはリスクのある旧シードとして扱うべきです。

まず Coldcard の公式ダウンロードページから、自分のモデルとリリース系列に対応する修正版ファームウェアを取得し、端末画面上でバージョンを確認します。その後、まったく新しいリカバリーフレーズを生成し、バックアップ、ウォレットフィンガープリント、受取アドレスを記録して確認します。

いきなり全額を移さないでください。まず少額を送金し、新しいウォレットで着金を確認し、フィンガープリントとアドレスを再確認してから、残りを移行します。全残高の着金を確認するまでは旧バックアップを保管し、移行完了後は旧アドレスへの入金を停止してください。

Coinkite はサイコロによるエントロピーについて一つの例外を示しています。シード作成時に Coldcard の「Add Dice Rolls」を使い、公平で独立し、完全に秘密に保たれた6面ダイスを少なくとも50回入力していれば、サイコロ自体から少なくとも128ビットのエントロピーが加わっています。99回以上なら約256ビットです。回数を覚えていない場合や、出目を撮影したりネット接続端末に記録した場合は、この例外に頼るべきではありません。

BIP-39 passphrase も独立した秘密情報を追加できますが、短い単語、名言、ありがちな変形、使い回しパスワードは推測される可能性があります。端末 PIN は BIP-39 passphrase ではありません。passphrase が十分に強くても、Coinkite はシードの交換を推奨しています。旧リカバリーフレーズ自体の弱点が修正されるわけではないためです。

移行中は、偽の告知、偽サポート、「シード安全診断」をうたうサイトに特に注意してください。Webサイト、チャット画面、リモートサポートソフトにリカバリーフレーズを入力するよう求める相手は信用してはいけません。

今回の事故が残した教訓

Coldcard のエアギャップ、再現可能ビルド、物理的な防護には今でも価値があります。ただし、生成段階ですでに弱かった秘密鍵を守ることはできません。ハードウェアウォレットは一つの金庫ではなく、乱数生成、ファームウェアビルド、秘密鍵保管、署名、バックアップ、復元という一連のプロセスです。どこか一つに問題があれば、全体が危険になります。

ユーザーがハードウェアウォレットの全コードを自分で監査することは現実的ではありません。それでも、単一障害点は減らせます。大きな資産を永続的に一社、一方式のシード生成に依存させないこと。どの端末でシードを生成したか、ファームウェアバージョン、日付を記録しておくこと。メーカーのセキュリティ告知を定期的に確認すること。そしてシード自体に関わる脆弱性が出た場合、ファームウェア更新だけで問題が終わったと思わないことです。

今回、本当に交換すべきなのは鍵です。旧シードが資金を管理している限り、リスクは残ります。

参考資料

公式企業・ファームウェア資料

• Coldcard 公式サイト

• Coinkite 公式サイト

• Coldcard / Coinkite 公式セキュリティ告知

• Coinkite 公式技術事後検証

• Coldcard 公式ファームウェアソースおよびセキュリティ告知

• Coldcard 公式ファームウェア変更履歴

• Coldcard 公式ファームウェアダウンロードページ

独立技術・標準資料

• Block Engineering: Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware

• Bitcoin BIPs: BIP-39 ニーモニック仕様

• Coldcard が2021年に libNgU を導入したコードコミット

オンチェーン追跡・報道確認

• Galaxy Research: 第3ラウンドの追跡および3ラウンド合計データ

• CoinDesk: 3回のスイープで4,585アドレス、約1,367 BTCまで拡大

• The Hacker News: 脆弱性経路、影響バージョン、Galaxy データ更新