2026年7月30日、ハードウェアウォレットColdcardで生成された秘密鍵から、ビットコインが大量に引き出された。原因は、2021年3月以降のファームウェアにおいて、秘密鍵を作るときの乱数が、本来使われるはずのハードウェア乱数生成器ではなく、予測可能なソフトウェア側の代替から供給されていたことにある。開発元のCoinkiteによれば、本来128ビットあるはずの強度は、機種によって約40ビットから約72ビットまで低下していた。
問題があったのは、ビットコインのプロトコルでも、オフライン保管という考え方でもない。秘密鍵が作られる瞬間の乱数だった。
ハードウェアウォレットは、秘密鍵をインターネットから切り離すための道具である。しかし鍵そのものが予測可能な材料から作られていた場合、切り離しても意味を持たない。攻撃者は端末に触れる必要がなかった。生成されうる鍵の候補を片端から作り、公開されているアドレスと突き合わせることで、当たりを見つけられたためだ。
自己保管は、鍵をどこに置くかだけで決まるものではない。鍵がどう作られ、どう使われ、誰の設計に依存しているか——今回の事件は、そのうち普段あまり意識されない部分を表面化させた。
Coldcard事件では何が起きたのか
7月30日、Coldcardで生成されたシードから、複数回に分けて資金が引き出された。攻撃は端末への物理的な接触を伴っていない。攻撃者は、生成されうる鍵の候補からアドレスを導き、ブロックチェーン上で残高のあるアドレスと照合していた。
影響を受けるのは、2021年3月のファームウェア以降、2026年7月の修正版までに端末上で生成されたシードである。それ以前に作られたシードは対象外とされる。Coinkiteの公表値では、実効的な強度はMk2とMk3が約40ビット、Mk4・Mk5・Qが約72ビットで、いずれも設計上の目標である128ビットを下回っていた。
流出量は、Galaxy Researchが8月4日時点で確認分1,596 BTC（約7,300アドレス）としたのに対し、Riverは8月12日時点で1,816 BTCとしている。攻撃は複数の波に分かれて継続しており、集計時点によって数字が動いている。Galaxy Researchは同時点で、未確認の波を含めれば2,055 BTCに達する可能性があるとしていた。
Coinkiteは7月31日に全機種向けの修正版ファームウェアを公開した。あわせて、脆弱なファームウェアを搭載した在庫の破棄と、該当製品の出荷停止を実施した。TAPSIGNER、OPENDIME、SATSCARDは対象外としている。
技術的背景──なぜ乱数が弱くなったのか
ファームウェアのビルド設定で、乱数生成器の指定が実質的に無効になっていた。その結果、秘密鍵を作るときに乱数を取得する処理が、Coinkiteが用意したハードウェア側の実装ではなく、土台となるソフトウェアに元から含まれていた簡易な生成器につながっていた。
後者は疑似乱数生成器と呼ばれるもので、計算によって数列を作る。初期値が分かれば、そこから先の出力はすべて再現できる。今回、その初期値は端末の識別子とタイマーの値に由来していた。いずれも機器の情報であり、乱数源ではない。
Coinkiteはこの点について、ハードウェア乱数生成器が動作中に故障して弱い代替へ切り替わったのではなく、接続先が最初から誤っていたと説明している。装置は正常だったが、そこへつながっていなかった、ということである。
なぜ4年以上見つからなかったのか
問題があったのは、暗号処理そのものでも、ビットコイン固有の処理でもなかった。Coinkiteによれば、2つの独立した部品のつなぎ目である。監査やコードレビューは各部品の内部を確認するように設計されることが多く、部品どうしの境界は死角になりやすい。
出力の見た目も手がかりにならなかった。疑似乱数生成器の出力は統計的にはランダムに見え、端末に内蔵された健全性チェックも通過していた。
Coinkiteは、事件の前に実施していたAIによるコードレビューでも検出できず、事後に複数の最新モデルで再検証しても検出されなかったと公表している。同社は他の開発チームに対し、ビルドやモジュールの境界を重点的に確認するよう呼びかけた。Coldcardのファームウェアは公開されており、だからこそ第三者が原因を特定して報告できたが、公開されていることと、実際に検証が及んでいることは同じではない。
ハードウェアウォレットは、そもそも何を守っているのか
ハードウェアウォレットが守るのは、秘密鍵をインターネットに接続された環境に置かない、という一点である。
ハードウェアウォレットはビットコインを保管しているわけではない。ビットコインはブロックチェーン上にあり、端末が持っているのは、それを動かす権限にあたる秘密鍵だけだ。送金するときは、取引の内容を端末に渡して端末内部で署名し、署名済みのデータだけを外へ出す。秘密鍵は端末から出ない。これが設計の中心にある。
この構造が防ぐのは、鍵が外部へ漏れる経路である。PCに感染したマルウェア、フィッシングサイト、クリップボードの改ざん、侵害された端末——いずれも、鍵がネットワークに触れる環境に置かれていることを前提とした攻撃であり、ハードウェアウォレットはその前提を崩す。
今回の事件は、この守備範囲の外で起きた。鍵は漏れていない。外部から再現された。防いでいる経路を通っていない以上、防御が働かないのは設計どおりであり、この点で製品の防御機構が破られたわけではない。破られたのは、その手前にある鍵の作り方だった。
秘密鍵は「作られ方」で強度が決まる
ビットコインの秘密鍵は、計算によって導き出すものではない。膨大な候補の中から、ランダムに一つを選ぶものである。したがって安全性を決めているのは、選択肢の広さそのものだ。
この広さを表す指標がエントロピーで、単位はビットである。1ビット増えるごとに候補は2倍になる。128ビットなら、候補は2の128乗、およそ3.4×10の38乗通りになる。
ここで注意が必要なのは、ビット数の減り方と安全性の減り方が比例しないことだ。128ビットから40ビットへの低下は、安全性が3分の1になるという意味ではない。探索対象となる候補数が、2の128乗から2の40乗へ縮小することを意味する。
この約40ビットという水準は、Mk2とMk3に限られる。Mk4・Mk5・Qは約72ビットで、こちらは通常の計算資源で探索できる規模ではない。Coinkiteが後者も移行の対象としたのは、探索が容易だからではなく、設計目標の128ビットを大きく下回るためである。
2の40乗はおよそ1兆1,000億通りである。桁だけを見れば大きく思えるが、専用の計算資源を投じれば現実的な探索対象になり得る規模だ。一方、2の128乗はその範囲に入らない。
つまりエントロピーの低下が決定的だったのは、鍵が「弱くなった」からではなく、試し切れない領域から、条件次第では探索対象になり得る領域へ、境界をまたいだからである。安全性は連続的に目減りするのではなく、ある線を境に性質が変わる。
今回、生成された値にはハッシュ関数（SHA-256）が掛けられ、BIP39のチェックサムも付与され、端末の健全性チェックも通過していた。下流の処理はすべて正常に動作していた。それでも何も救えなかった。
ハッシュ関数は、入力の分布を整えることはできるが、入力の候補数を増やすことはできないからである。40ビット分の候補をハッシュしても、出力の見た目は均一になるが、候補は40ビット分のままだ。ランダムに見えることと、ランダムであることは別である。
自分でランダム性を足すという選択肢
Coldcardには、シードを作るときにサイコロの出目を加える機能がある。Coinkiteによれば、50回から98回の独立した非公開のダイスロールを入力した場合、ダイス由来の入力だけで128ビット以上のエントロピーに達する。99回以上なら約256ビットになる。この条件を満たしていた利用者は、今回の乱数の問題だけでは影響を受けていないとされる。
ただし、ここから「対策していれば防げた」という整理を引き出すのは適切ではない。実際にサイコロを50回以上振ってシードを作っている利用者はごく少数であり、そもそも端末が生成する乱数を信頼できることが製品の前提だったからである。原因は利用者の運用ではなく、実装の側にある。
この機能が示しているのはむしろ、鍵の材料を利用者側でも足せるという設計の考え方そのものだ。端末の乱数が正しく動いているかどうかを利用者が検証する手段は、通常ない。検証できないものへの依存を減らす選択肢が用意されていたこと自体が、今回の結果として意味を持った。
オフラインで保管していても防げなかった理由
オフライン保管が防ぐのは、ネットワークを経由する攻撃である。裏返せば、それ以外の経路——とりわけ鍵の生成時点の欠陥——には効かない。
今回の攻撃は、ネットワークを経由していない。攻撃者が見ていたのは、ブロックチェーン上の公開情報だけである。
ここには構造上の非対称がある。ブロックチェーンは公開台帳であるため、攻撃者は候補の鍵からアドレスを導き、実際に残高のあるアドレスと突き合わせることができる。総当たりを試みる側にとって、その場で答え合わせができる状態が常に用意されているということだ。候補の数さえ十分に狭ければ、鍵がどこに保管されているかは関係がなくなる。
この点は、ビットコインのプロトコルとの境界を考えるうえでも重要になる。ビットコインのネットワークが検証しているのは、その署名がそのアドレスの鍵によるものかどうかである。今回、署名は正しい鍵で作られていた。ネットワークから見れば、正当な所有者による送金と区別が付かない。
つまり、問題があったのはビットコインのプロトコルではなく、秘密鍵を生成するウォレット側の実装である。ビットコインのネットワークは鍵の正しさを検証するが、鍵がどのように作られたかは検証しない。
これは裏を返せば、鍵の生成品質をプロトコルが保証してくれることはない、ということでもある。その責任は、実装する側と利用する側に残されている。プロトコルが無傷だったという事実は、被害を受けた利用者にとって何の救いにもならない。重要なのは、鍵の生成という工程が誰の責任範囲にあるのかを、あらかじめ知っておくことのほうだ。
自己保管では、リスクは消えるのではなく入れ替わる
取引所にビットコインを預ける場合、想定されるリスクは、破綻、凍結、内部不正、外部からの侵害などである。いずれも共通しているのは、自分以外の判断や管理体制に依存している点だ。
自己保管はこれを引き受け直す。預け先に依存するリスクは消えるが、代わりに、自分の判断と、自分が選んだ道具の設計に依存するリスクを負う。ここで消えているのはリスクそのものではなく、リスクの所在である。
自己保管で考えるべき範囲は、鍵をどこに置くか（保管）だけではない。鍵がどう作られたか（生成）、どう使うか（利用）、そして誰の実装に依存しているか（第三者への依存）まで含まれる。一般に「自己保管のリスク」として語られるのは保管の話に偏りがちだが、今回表面化したのは、生成と第三者への依存だった。
このうち第三者への依存は、完全に取り除けるものではない。ハードウェアウォレットを使う以上、そのメーカーの実装を信頼する部分は必ず残る。市販の端末を使わずに鍵を作る方法はあるが、大半の利用者にとって現実的な選択肢とは言いがたい。
したがって扱い方は、依存を消すことではなく、依存を分散させることになる。異なるメーカーの端末を組み合わせる、複数の鍵を必要とするマルチシグを使う、鍵の材料に自分で用意したランダム性を混ぜる——いずれも、一つの実装の欠陥が全体に及ばないようにするという同じ考え方に基づいている。
今回、Riverは自社の分析の中で、取引所リスクを取り除くことがすべてのリスクを取り除くことにはならないと指摘した。自己保管が取引所より安全だという話でも、その逆でもない。
今回の事件から、自己保管で確認すべきこと
この事件が問いかけているのは、どの製品を選ぶべきかではない。自分の鍵がどういう経緯で存在しているかを、どこまで把握しているかである。
第一に、自分のシードをいつ、どの端末で、どのファームウェアで生成したかを把握しているかどうか。今回、影響を受けるかどうかを分けたのは、保管方法でも資産額でもなく、鍵が作られた時点の環境だった。この情報を記録している利用者は多くない。
第二に、一つの機種、一つの実装にすべてを預けていないかどうか。実装の欠陥は事前には見えず、今回のように数年間気づかれないこともある。分散は、欠陥を防ぐためではなく、欠陥が起きたときに全体へ波及させないための設計である。
第三に、使っている製品の脆弱性情報が自分に届く経路があるかどうか。今回、対応の速さがそのまま被害の有無を分けた局面があった。
なお、Coldcardの利用者については、確認すべき点が具体的に示されている。影響を受けるのは対象ファームウェアで生成されたシードであり、ファームウェアを更新しても、すでに生成されたシードは修復されない。新しいシードを生成し、資金を移す必要がある。弱いシードは、他のどの端末に復元しても弱いままである。
Galaxy Researchは8月4日時点で、少なくとも15の別個の実行者がこの不具合を悪用していると報告していた。その後も被害状況の分析は続いており、攻撃対象となったアドレスや流出量の集計は更新されている。移行の手順はCoinkiteが公開しているアドバイザリに詳しく、同社は、急いだ移行そのものが新たな損失を生みうるとして、順を追って確認しながら進めるよう求めている。該当する場合は、必ず公式の案内を参照してほしい。
ビットコインは、鍵を持つ者がそのまま所有者になる仕組みだ。だからこそ、その鍵がどこで、どうやって作られたのかという問いは、保管方法を選ぶことと同じだけの重みを持つ。
