COLDCARDの乱数生成不備とは ── 大規模流出との関連が指摘された「ハードウェアウォレットなら安全」の盲点

※この記事は2026年8月2日時点で確認できた情報を基にしている。調査は現在も続いており、影響範囲や被害推定が今後更新される可能性がある。

ハードウェアウォレットを使い、秘密鍵をインターネットから切り離せば、オンライン上の攻撃からビットコインを守りやすくなる。

私もその点を重視して、取引所だけに依存せず、Ledgerデバイスを使った自己保管を始めた。

しかし、COLDCARDで発覚した乱数生成の不備は、私が考えていたハードウェアウォレットの安全性を、もう一段深く見直すきっかけになった。

今回報告されている攻撃では、端末を盗まれたわけでも、利用者がリカバリーフレーズを偽サイトへ入力したわけでもない。

一部のCOLDCARDで生成されたシードの候補が、本来想定されていたより狭い範囲に限られていたため、攻撃者が端末の外部から候補を探索し、秘密鍵へ到達した可能性が指摘されている。

オフラインで保管していても、その秘密鍵の元になるシードフレーズが十分に予測不能な方法で作られていなければ、資産を守れない。

私は今回の問題から、ハードウェアウォレットを使っていることと、安全なシードフレーズが作られていることは同じではないと気づかされた。

COLDCARDで何が起きたのか

COLDCARDの製造元であるCoinkiteは、2026年7月30日にセキュリティ勧告を公開した。

その後、影響範囲の調査が進み、8月1日の更新では、Mk2、Mk3だけでなく、Mk4、Mk5、Qの一部ファームウェアで生成されたシードも対象に含まれることが公表された。

問題があったのは、シードフレーズを作るための乱数生成である。

ウォレットが新しいシードフレーズを作るときは、攻撃者が現実的に推測できないほど広大な候補の中から、予測不能な数を選ぶ必要がある。

しかし、COLDCARDの一部ファームウェアでは、シード生成処理が本来使用するはずだったハードウェア乱数生成器へ正しく到達せず、MicroPythonに含まれるソフトウェア側の疑似乱数生成処理へ接続されていた。

ただし、影響の構造は機種によって異なる。

Mk2とMk3では、この処理経路に暗号学的な乱数が追加されていなかった。

端末固有の識別情報、タイマーの状態、乱数処理が呼び出された履歴などを十分に絞り込めれば、生成結果を外部で再現できる構造だったとBlockは分析している。

Mk4、Mk5、Qでは、Secure Element由来の乱数が一部追加されていたため、Mk2やMk3より影響は小さい。

しかし、Secure Elementから得られた情報のすべてが最終的な乱数状態へ反映されていたわけではなく、本来想定されていた安全性には達していなかったとCoinkiteは説明している。

生成された単語は、見た目だけなら普通のシードフレーズに見える。

しかし、見た目がランダムに見えることと、攻撃者に予測できないことは別である。

後からハッシュ処理を加えても、元になる乱数候補の数が少なければ、候補数そのものを増やすことはできない。

攻撃方法は有力な分析だが、正式な検証は完了していない

BlockのBitcoin Engineering and Securityチームは、問題のコード経路を解析し、攻撃者がシード候補を外部で再現できる可能性を説明している。

一方でBlockは、現時点の分析は現在確認できている情報に基づくものであり、完全な実機検証によって攻撃可能性のすべてを確認したわけではないとも明記している。

また、最終的な技術評価については、Coinkiteが今後公開する正式な技術報告を参照するよう求めている。

Coinkiteも、現在の勧告は初期段階の分析であり、調査を継続していると説明している。

したがって、以下の攻撃経路は現時点で有力な技術的説明ではあるものの、すべての被害について最終的に実証された攻撃方法ではない。

本体へ侵入された攻撃ではなかった

今回の問題を「COLDCARD本体が遠隔操作された」と理解するのは正確ではない。

Blockが示した有力な攻撃経路では、攻撃者が個々の端末へ接続したり端末内部から秘密鍵を直接抜き取ったりする必要はなかったと考えられている。

弱い乱数から作られたシード候補を外部で計算する。

候補から公開鍵や受け取りアドレスを生成する。

ブロックチェーン上で使用されているアドレスと一致したら、そのシードから秘密鍵を復元する。

ウォレットの公開鍵、拡張公開鍵、受け取りアドレスなどが、候補が正しいかを確認する手掛かりになる。

ハードウェアウォレットがオフラインでも、攻撃者が同じ秘密鍵を別の場所で再現できれば、端末の隔離だけでは資産を守れない。

今回の問題の怖さは、コールドウォレットへ侵入されたことではない。

コールドウォレットの中にある秘密鍵と同じものを、外部で再現できた可能性があることである。

オンチェーン上の関連推定は初報より拡大している

初期の報道では、約500のアドレスから約594BTCが移動したとされていた。

その後Galaxy Researchは、今回の問題と関連するとみられる別の資金移動を追加で確認した。

2026年8月1日にGalaxy Researchが公開したオンチェーン分析では、三つの資金移動を合わせて、4,585のアドレスから合計約1,367.05 BTCが移動したと推定されている。

ただし、この数字は、Coinkiteが被害者一人ひとりを確認して集計した確定被害額ではない。

Galaxy Researchが、アドレスの作成時期、使用された受け取り形式、資金の集約方法などのオンチェーン上の特徴から、今回の脆弱性と関連すると判断した推定値である。

また、4,585という数字は、被害者数やウォレット数ではなくアドレス数である。

一人の利用者や一つのウォレットが複数のアドレスを使用している可能性もあるため、

4,585人のCOLDCARD利用者が被害を受けたとは言い切れない。

すべての資金移動について、COLDCARDの乱数生成不備が原因であると最終確定したわけでもない。

記事では、約1,367 BTCがCOLDCARDの不具合によって確実に盗まれたと断定するのではなく、Galaxy Researchの分析では、今回の問題と関連するとみられるアドレスから約1,367 BTCが移動したと推定されていると書く方が正確である。

影響を受ける機種とファームウェア

Coinkiteが2026年8月1日に更新した公式勧告では、次の環境で生成されたシードが対象とされている。

重要なのは、現在端末に入っているファームウェアではない。

シードフレーズを生成した時点で、どのファームウェアを使っていたかが基準になる。

現在のファームウェアが修正版になっていても、過去に対象バージョンで生成したシードが自動的に安全になるわけではない。

なお、Mk2とMk3の対象バージョンについては、CoinkiteとBlockの資料に違いがある。

Coinkiteの公式勧告では、対象を4.0.1から4.1.9までとしている。

一方、Blockのコード解析では、問題となる処理経路は2021年3月17日に公開された4.0.0から4.1.9までに存在したとされている。

4.0.0でシードを生成した可能性がある場合も「公式表に含まれていないから安全」と自己判断せず、安全側に立ってCoinkiteの公式サポートへ確認した方がよい。

約40ビットと約72ビットは暫定的な推定である

Coinkiteは、現在の攻撃条件を前提とした暫定評価として、Mk2とMk3の実効的な探索範囲を約40ビット、Mk4、Mk5、Qを約72ビット相当と推定している。

本来想定されていた安全性は128ビットだったため、後期機種でも本来の水準には届いていなかったと説明している。

ただし、Coinkite自身も、この数字は現在の攻撃条件に基づく予備的な推定であり、調査によって変わる可能性があるとしている。

Blockは別の観点から、Mk4、Mk5、Qについて、疑似乱数側の状態と呼び出し履歴を固定できた場合、Secure Element由来で区別される出力候補は最大2³²通りになると分析している。

ただし、この2³²という数字と、Coinkiteが示した約72ビットは、同じ条件で算出された数字ではない。

実際の攻撃コストは、端末のUID、起動時刻、タイマー状態、過去に乱数処理が呼び出された回数などを、攻撃者がどこまで絞り込めるかによって変わる。

Blockは、誰でも直ちにすべてのシードを復元できるという意味ではなく、実際の総当たり時間や攻撃費用も確定していないと説明している。

ファームウェアを更新するだけでは直らない

この問題で最も重要なのは、ファームウェアを更新しても、過去に生成したシードフレーズは安全にならないことである。

修正版ファームウェアは、これから生成するシードの乱数処理を修正する。

しかし、弱い方法で作られた既存のシードフレーズの候補数を、後から増やすことはできない。

対象ファームウェアでシードを作った場合、Coinkiteは次の対応を案内している。

1. 対象機種へ修正版ファームウェアを導入する
2. 修正版で新しいシードフレーズを生成する
3. 新しいバックアップ、ウォレットフィンガープリント、受け取りアドレスを確認する
4. まず少額を送金する
5. 新しいウォレットで着金を確認する
6. 残りの資産を移す
7. 移行が完了するまで古いバックアップを捨てない

Coinkiteは、焦って移行することで別の送金ミスを起こさないよう、落ち着いて各段階を確認することも求めている。

今回の問題は、私が少額テストを重視してきた理由ともつながる。

危険なシードから早く移したいという焦りがあっても、受け取り先の確認を省略して全額を一度に送れば、別の原因で資産を失うかもしれない。

問題が重大であるほど、手順を飛ばさないことが重要になる。

サイコロを追加した場合

対象ファームウェアでも、シード生成時に少なくとも50回の、公平で独立し、他人に知られていないサイコロの出目を追加していた場合、Coinkiteは今回の乱数問題だけを理由に、そのシードが危険だとは判断していない。

50回から98回の独立したサイコロの出目では、サイコロ入力だけで少なくとも128ビット相当、99回以上では約256ビット相当の乱数が加わると説明されている。

ただし、

• 何回振ったか分からない
• 出目を記録したり他人へ公開したりした
• 公平なサイコロだったか分からない
• サイコロを加えた後に表示された最終シードがどれか分からない

場合は、新しいシードへの移行が推奨されている。

この例外は、端末側で生成された弱い乱数とは別に、利用者自身が十分な独立した乱数を追加していた場合に限られる。

修正版ファームウェアでは、通常の端末生成だけで必要な乱数が確保されるとCoinkiteは説明しており、今回の問題へ対応するためにサイコロを追加することは必須ではない。

強いBIP39パスフレーズを使っていた場合

対象のシードに、強く固有のBIP39パスフレーズを組み合わせていた場合、攻撃者はシード候補に加えてパスフレーズも推測する必要がある。

そのため、弱いシードだけから直ちにパスフレーズ付きウォレットへ到達される危険は下がる。

しかし、パスフレーズを使っても、元のシードにある乱数生成の問題が修復されるわけではない。

短い言葉、引用文、規則的な文字列、ほかで使い回したパスフレーズは推測される可能性がある。

Coinkiteは、強いパスフレーズを使用している場合でも、可能な時点で修正版ファームウェアから生成した新しいシードへ移行するよう案内している。

ここでいうパスフレーズは、COLDCARD端末のPINとは別のものである。

また、パスフレーズを一文字でも間違えると、別の有効なウォレットが生成される。

新しいウォレットへ資産を移す場合は、ウォレットフィンガープリントや受け取りアドレスが意図したものと一致しているか確認する必要がある。

ソースコードが公開されていても長期間発見されなかった

COLDCARDは、ファームウェアのソースコードを公開し、利用者や外部研究者が検証できることを特徴としてきた。

それでも、問題の処理経路は2021年3月にシード生成へ入ってから、2026年7月まで発見されなかった。

問題となったハードウェア乱数生成用のコード自体は、ファームウェア内に存在していた。

しかし、実際のシード生成処理がどの乱数生成関数へ到達しているかが、処理経路の最後まで確認されていなかった。

目的のハードウェア乱数生成器と、MicroPython側の疑似乱数生成器が同じ形式の関数を持っていたため、誤った実装へ接続された状態でもビルドが完了していた。

ソースコードが公開されていることと、すべての処理経路が実機で正しく検証されていることは同じではない。

これは、ソースコードを公開する意味がないという話ではない。

公開されていたからこそ、外部研究者が原因を確認し、技術的な議論を進められた面もある。

しかし、ソースコードが公開されているだけで、自動的に安全になるとは考えない方がよい。

コードの公開、処理経路の検証、実機テスト、ビルド時の検査、外部監査、問題発生後の情報公開は、それぞれ別の安全対策である。

Coinkiteは修正版で、誤った疑似乱数処理が含まれないようにし、正しい乱数生成関数へ接続されていなければビルドを失敗させる検査を追加したと説明している。

ハードウェアウォレットへの信頼は失われたのか

今回の事件は、ハードウェアウォレットに対する信頼を大きく傷つけたと私は思う。

利用者は、端末が正しい乱数を作り第三者には推測できないシードフレーズを表示していると信じるしかない。

画面に表示された12個や24個の単語を見ても、その背後に十分な乱数が使われているかを人間が目で確認することはできない。

今回の問題では、その最も基本的な前提が破られた。

一方で、私は、すべてのハードウェアウォレットが無意味になったとは考えていない。

今回明らかになったのは、ハードウェアウォレットという分類だけでは、安全性を判断できないということである。

• シードをどの乱数生成器で作るのか
• 乱数生成器はどのように試験されているのか
• シード生成処理が意図した乱数生成器へ確実に到達しているか
• 秘密鍵をどこで保管するのか
• 署名処理をどこで行うのか
• ファームウェアの検証方法はどうなっているのか
• 問題が起きたとき、どのように公表・修正するのか

同じハードウェアウォレットでも、内部設計や検証方法は異なる。

「オフライン」「エアギャップ」「ソースコード公開」「Secure Element」といった一つの言葉だけで、安全性全体を判断することはできない。

今回の問題だけでLedgerが安全だとは証明されない

私は現在、Ledgerを使ってビットコインを自己保管している。

Ledgerは、シードの元になる乱数をSecure Element内のTrue Random Number Generatorで生成すると説明している。

また、Secure Elementに搭載された乱数生成器は、温度、電圧、周波数などの異なる条件で試験され、第三者機関によるセキュリティ評価の対象になるとしている。

生成されたシードも、Secure Element内の不揮発性メモリへ保存されると説明されている。

この設計と検証方法は、今回COLDCARDで明らかになった処理とは異なる。

CoinkiteとBlockが公開した今回の報告はCOLDCARDを対象としたものであり、Ledgerがこの不具合の対象だとは報告されていない。

しかし、Secure Element内に認証された乱数生成器が搭載されていることだけで、シード生成に関わるファームウェアや処理経路全体に、将来も不具合が起きないことまで証明されるわけではない。

今回のCOLDCARD問題でも、目的のハードウェア乱数生成器自体は存在していた。

問題は、実際のシード生成処理が、意図した乱数生成器へ正しく到達していなかったことである。

そのため、今回の問題で「危険なのはCOLDCARDで、Ledgerは完全に安全」とは言い切れない。

Ledgerにも、Secure Element、ファームウェア、オペレーティングシステム、製造工程、セキュリティ検証など内部の仕組みを信頼しなければならない部分が残る。

私は今回の事件を「メーカーや製品ごとに安全設計は異なり、その違いを理解して選ぶ必要がある」という教訓として受け止めている。

自己保管は、他人を一切信用しない仕組みではない

取引所にビットコインを置けば、取引所の管理体制や出金対応を信用することになる。

ハードウェアウォレットへ移せば、取引所への依存を減らせる代わりにハードウェアウォレットの仕組みを信用することになる。

• デバイスが十分な乱数を生成すること
• シード生成処理が正しい乱数生成器へ接続されること
• ファームウェアが意図どおり動くこと
• デバイスの画面が正しい情報を表示すること
• メーカーが問題を隠蔽せずに公表すること
• 自分が重要なセキュリティ情報を見落とさないこと

利用者は上記の部分を信頼している。

そして、自分自身がリカバリーフレーズを失わず、送金先を間違えず、偽サイトへ入力しないことも必要になる。

自己保管とは、他人を一切信用しなくてよくなる方法ではない。

どの危険を自分で引き受け、どの部分を道具やメーカーへ任せるかを選び直すことだ。

私の判断：製品名よりも原因に注目すべき

今回の問題は、ハードウェアウォレットなら安全だという単純な考え方を崩した。

端末がオフラインであっても、シード生成に問題があれば資産は守れない。

ソースコードが公開されていても、長期間発見されない不具合は起こり得る。

ファームウェアを更新しても、過去に弱い方法で作られたシードは強くならない。

有名なメーカーや製品であっても、重大な失敗が起きる可能性はある。

だから私は、今後ハードウェアウォレットを選ぶときに以下を調べる必要があると考えるようになった。

• シードフレーズをどのように生成するのか
• 乱数生成を誰がどのように検証しているのか
• シード生成処理全体が検証されているか
• 秘密鍵と画面をどのチップが管理するのか
• 過去の脆弱性へどのように対応してきたのか
• 問題が起きた場合に既存利用者へ何を求めるのか

どの製品にも、将来の安全を完全に保証することはできない。

それでも、すべて同じだから選ぶ意味がないわけではない。

安全性の違いを理解し、自分が納得できる設計と対応方針を持つメーカーを選ぶ。

そして、購入した後も、ファームウェアやセキュリティ勧告を定期的に確認する。

ハードウェアウォレットは、買った瞬間に安全が完成する道具ではなかった。

シードを生成した方法、使用したファームウェア、バックアップ、送金手順、メーカーからの告知まで含めて管理する必要がある。

今回のCOLDCARD問題は、その現実を厳しい形で示した事件だと思う。

※COLDCARDの対象ファームウェアでシードを生成した可能性がある場合は、SNS上の断片的な手順ではなく、Coinkite公式の最新セキュリティ勧告を確認してほしい。焦って全額を一度に移動せず、新しいシード、ウォレットフィンガープリント、受け取りアドレスを確認し、少額テストを行ってから残りを移す必要がある。

※暗号資産や特定製品の安全性を保証するものではない。暗号資産の購入、送金、保管、ウォレットの移行は、必ず公式情報を確認したうえで自己責任で行ってほしい。