この事件は一般的に言われる「秘密鍵の流出」とどう違うのですか？
多くのセキュリティ事件における秘密鍵の流出は、攻撃者がフィッシング、マルウェア、物理的な盗撮といった何らかの経路を通じて、本来安全だったはずの鍵を入手するというものだ。今回のColdcardのケースはその逆である。秘密鍵は「生成」された瞬間から既に十分にランダムではなかった。攻撃者はデバイスに触れる必要も、利用者を騙して何かをさせる必要もなく、オフラインで候補となるシードを計算し、その結果を公開されているオンチェーンデータと照合するだけで、残高のあるアドレスを見つけ出せた。
これは「受動的」なリスクだと言える。被害者は何か間違いを犯して騙されたわけではなく、手元のデバイスが工場出荷の瞬間から既にセキュリティの約束を果たしていなかったという事実が、5年間気づかれずに存在していたのである。
なぜ「128ビットのエントロピー」といった数字が、エンジニアだけでなく一般の人にとっても重要なのですか？
エントロピーとは本質的に、攻撃者が正解を推測するために試さなければならない可能性の数を定量化した指標である。128ビットは2の128乗通りの組み合わせを意味し、これは39桁の天文学的数字であり、地球上の全てのコンピュータを合わせてフル稼働させても、宇宙の年齢をもってしても全探索できない。これが業界がこれをセキュリティの最低基準と定めている理由である。影響を受けたColdcardの機種では実効エントロピーが40〜72ビットまで低下し、本来「不可能」だったはずの推測の難易度が、「既存のハードウェアリソースで現実的な時間内に達成可能」なレベルまで下がってしまった。
背後にある暗号理論を理解する必要はないが、この数字が示す落差がどれほど大きいかは理解しておく必要がある——これは「リスクが少し上がった」という話ではなく、「数学的に不可能」から「技術的に実行可能」へと直接転落したという話なのだ。
Coinkiteは「攻撃者がAIを使ってソースコードをレビューしたと想定せざるを得ない」と述べていますが、これはどのような新しい常態を示しているのですか？
この事件には興味深い詳細がある。Coinkite自身が脆弱性発覚のわずか数週間前に、最先端のAIモデルを使って同じコードをレビューしていたにもかかわらず、この問題を発見できなかった。それでも同社は、攻撃者がAIツールを使ってこの弱点を見つけたと想定せざるを得ないと考えている。これは進行中の変化を反映している——かつてビルド設定の中に深く埋もれた微妙な論理エラーを発見するには、上級エンジニアがコードを1行ずつレビューするのに多大な時間を投じる必要があったが、現在はAIツールがそうした脆弱性を見つけるコストと時間のハードルを大幅に下げている。
これはAIが暗号理論そのものを破ったという意味ではなく、脆弱性がコードに書き込まれてから発見・悪用されるまでの時間差をAIが圧縮しつつあるということだ。これにより開発チームは、従来の「定期的なセキュリティレビュー」というペースから、より「継続的なテスト」に近い防御モデルへと移行を迫られている。オープンソースであるかどうかも、もはや唯一のセキュリティ変数ではなくなっている。
Coldcardを使っていない場合でも、これは自分に関係があるのですか？
関係がある。しかも表面的に見えるよりも直接的に。多くの利用者がハードウェアウォレットを選ぶ際の判断基準は「オフライン保管＝安全」という段階で止まっており、「このデバイスのランダム性は実際どのように生成され、誰が検証したのか」まで踏み込んで問うことは少ない。Coldcard事件は、オープンソースで長年業界の標準とみなされてきた製品であっても、この検証の抜け穴が5年間誰にも気づかれずに存在し続ける可能性があることを証明した。
ハードウェアウォレットを使う全ての人にとって、具体的にできることがある。デバイスベンダーの公式セキュリティ勧告チャンネルを購読すること（ニュースになってから初めて知るのではなく）、ファームウェアのリリースノートに乱数生成器に関連する修正がないか注意を払うこと、そして自分が選んだ製品が第三者による独立したセキュリティ監査を受けたことがあるかどうかを理解すること——「オフライン」という言葉だけで万全だと思い込まないことが重要である。
2026年7月30日、暗号資産セキュリティ業界は特に皮肉な事件に見舞われた。被害者は不注意な個人投資家ではなく、わざわざハードウェアウォレットを購入し、資産をオフラインで保管し、教科書通りのあらゆる正しい行動を取っていたビットコイン保有者たちだった。攻撃者が狙ったのはCoinkite社製のハードウェアウォレット「Coldcard」で、セルフカストディ分野において最も硬派で徹底したセキュリティ志向の選択肢の一つと長らく見なされてきた製品である。
ハードウェアウォレットのセキュリティは2つの独立した前提の上に成り立っている。秘密鍵が物理的に隔離されたデバイス内にのみ存在すること（リモート攻撃者がネットワーク経由で抽出できない）、そしてその秘密鍵が十分にランダムな乱数（エントロピー）から生成されていること（デバイスに触れていない者が同じ鍵を再現できない）である。今回のColdcard事件では、第一の前提は保たれていた——USBやWi-Fi経由でデバイスから鍵が抽出された証拠はない。崩壊したのは第二の前提だった。
Coinkiteが公開した技術背景資料によれば、根本原因は2021年3月に行われたファームウェア統合時のミスにさかのぼる。当時のコード移行作業で、チップ内蔵の真性乱数生成器（TRNG）を有効化するための設定フラグを誤ってゼロに設定した。しかしこのフラグの実際の挙動は「どちらも使わない」ではなく、チップの固有シリアル番号とタイマーレジスタから初期化されるソフトウェア疑似乱数生成器（PRNG）へと静かにフォールバックするというものだった。このPRNGは初期化後に新たなエントロピーを一切収集せず、本来128ビットの強度を持つべきランダム性を、攻撃者が理論上計算または絞り込める少数の変数に置き換えてしまっていた。
影響範囲は機種によって異なる。影響を受けたMk2およびMk3では、実効エントロピーが約40ビットまで低下した。より新しいMk4、Mk5、Qではセキュアエレメントからの追加エントロピーが混合されていたものの、実効エントロピーはやはり約72ビットにとどまった——いずれも業界標準の128ビット目標（2の128乗、39桁の天文学的数字）を大きく下回る。この脆弱性は2021年3月にコードベースに混入し、約5年間発見されないままだった。
ブロックチェーン情報分析企業Galaxy Researchのオンチェーン分析によれば、7月30日、攻撃者は41分間の単一の攻撃波で1,196のビットコインアドレスを標的にし、約1,082.65 BTC（当時の価格で約7,020万ドル相当）を一度に流出させた。これは最初の波に過ぎず、その後複数の波が続き、5,200以上の個別アドレスに影響が及び、累計盗難額は上昇を続けている。Fortune誌の8月10日の報道では、累計被害額は既に2,000 BTCを超えたとされている。被害者が盗難に気づくのは数週間から数ヶ月後になることも多いため、この数字は現時点では最終確定値ではなく暫定値と見なされている。
注目すべき点として、Coldcardのソースコードは常に公開されており、Coinkite自身も事後に「誰かがAIツールを使って過去のファームウェアバージョンを検証したと想定せざるを得ない」と認めている。同社は数週間前に最先端のAIモデルを使って同じコードをレビューしたばかりだったが、この問題を発見できなかった。この事件は、AIが脆弱性の発生・発見・悪用の間の時間差を圧縮しつつあるという業界の議論における具体的な事例となっている。
事件発覚後、複数の競合他社は自社製品が影響を受けないことを直ちに公表した。Ledgerは自社デバイスがセキュアエレメントチップに内蔵された認証済みの真性乱数生成器を使用し、24語の回復フレーズごとに完全な256ビットのエントロピーを提供していると述べた。Trezorも、今回の問題はColdcard独自のカスタムファームウェアと乱数生成方式に限定されており、自社製品とは無関係であると説明した。この対比は混同されやすい重要な点を示している——これは「ハードウェアウォレットは安全でない」というカテゴリ全体の結論ではなく、同じカテゴリ内の一製品が、セキュリティモデル全体の中で最も重要でありながらユーザーが独自に検証することが最も難しい部分で実装ミスを犯したということである。
もしColdcard Mk2、Mk3、Mk4、Mk5、またはQを使用しており、シードフレーズが公式修正ファームウェアのリリース以前に生成されたものである場合、Coinkiteのガイダンスではそれを侵害済みとみなす必要がある。ファームウェアを更新し、新しいシードを生成し、フィンガープリントを検証し、テスト送金で問題ないことを確認してから、全資産を新しいウォレットに移動すべきである。古い（既に汚染された）シードフレーズを別のウォレットアプリにインポートするだけでは何も解決しない。問題はシード自体のランダム性不足にあり、それを保管する容器にあるのではないからだ。Coinkiteはまた、復旧プロセス中のミスが脆弱性そのものより大きな損害を引き起こす可能性があると特に警告し、パニックによる拙速な行動を控えるよう助言している。
より広い教訓は、「オフライン」と「ランダム」は別の事柄だということである。ハードウェアウォレットは前者を保証できるが、後者はベンダーのコードに埋め込まれた、外部の者がほとんど独自に検証できない実装の詳細に依存している。あなたにできることは限られているが具体的である——使用しているデバイスベンダーの公式セキュリティ勧告チャンネルをフォローし、定期的にファームウェアバージョンを確認し、自分が依拠している「ランダム性」が実際に誰によってどのように生成されているのかを理解すること。「オフライン保管」を無条件に「絶対安全」と同一視しないことが重要である。