Coldcard事例で秘密鍵依存の構造的リスクが表面化、自己管理は単一障害点を減らす設計の重要性を問われる

Last Updated on 2026年8月11日 by oba3

ビットコイン(Bitcoin)専用ハードウェアウォレット「コールドカード(Coldcard)」のシード生成問題を巡り、自己管理型ウォレットが抱える秘密鍵依存のリスクが改めて注目されている。開発元のコインカイト(Coinkite)は2026年7月30日、特定のファームウェアで生成されたシードのランダム性が本来の水準を大幅に下回っていたと公表した。TRMラボ(TRM Labs)が8月時点で整理した分析では、7月30日以降の4回の盗難波で5,200を超えるアドレスから約1,816BTC、約1億1,600万ドル相当が流出した可能性がある。ただし被害集計は暫定的で、資金移動の分析は継続している。今回の問題は一製品の不具合だけではない。暗号資産では資産を動かす権限が秘密鍵やシードへ集中するため、その生成段階が破られるだけでも、オフライン保管という防御を迂回できることが示された。

目次

何が起きたのか?

コインカイトによると、問題は2021年3月に公開されたファームウェア4.0.1からシード生成経路へ入り込んだ。Mk2とMk3では4.0.1から4.1.9までが影響対象とされ、生成されたシードのエントロピーは暫定推定で約40ビットまで低下していた。現在はMk2とMk3向けに修正版4.2.0が公開されている。

より新しいMk4、Mk5、Qでも、修正版より前に生成された一部シードは影響を受ける。コインカイトはこれらについて、本来目標としていた128ビットに対し、エントロピーが約72ビットまで低下していた可能性があると説明している。標準系ではMk4とMk5の5.6.0、Qの1.5.0Q、Edge系では6.6.0Xまたは6.6.0QXが修正ラインとして案内されている。

原因は、ハードウェア乱数生成器そのものが破られたことではない。コインカイトの技術説明では、ビルドとリンク処理に関する実装上の問題によって、本来シード生成で使う予定だったハードウェア由来の乱数ではなく、一般用途向けの疑似乱数処理が使われる状態になっていた。

TRMラボが紹介したオンチェーン分析では、7月30日以降に4回の資金流出が確認され、約1,816BTCが5,200を超えるアドレスから移動したと推計されている。端末そのものを盗み出す必要はなく、弱くなったシード候補を外部で探索し、公開されているビットコインアドレスと照合できた可能性が指摘されている。

重要なのは、ファームウェアを更新するだけでは過去に生成されたシードが安全にならないことだ。対象シードを使っている利用者は、修正版の環境で新しいシードを生成し、資産を新しいウォレットへ移す必要がある。

なぜ重要なのか?

ハードウェアウォレットは、秘密鍵を普段利用するパソコンやスマートフォンから隔離することで、オンライン攻撃の範囲を狭める。しかし今回の問題では、秘密鍵の元になるシード自体の生成強度が不足していた。そのため端末をネットワークから切り離して保管していても、安全性の前提そのものが弱くなっていた。

約40ビットと約72ビットという差も重要だ。どちらもコインカイトが目標としていた128ビットを下回るが、旧世代のMk2とMk3では特に候補範囲が小さくなっていたとされる。暗号方式そのものが破られたのではなく、十分に予測困難な秘密を生成できていなかったことが事件の核心になる。

この問題がコールドカードだけで終わらない理由は、暗号資産の盗難で鍵や署名権限の侵害が大きな損失につながっているからだ。チェイナリシス(Chainalysis)の2024年分析では、秘密鍵侵害が盗難額の43.8%を占めた。TRMラボも2026年上半期について、鍵や認証情報などを含むインフラ・運用系の侵害は件数では約15%だった一方、盗難額では約76%を占めたとしている。

攻撃件数の多さと被害額の大きさは一致しない。一つの署名権限から大量の資産を動かせる環境では、その権限を奪う攻撃が成功した際の損失が非常に大きくなりやすい。秘密鍵管理はウォレット機能の一部ではなく、暗号資産を保有する仕組みそのものに関わる。

市場構造への影響

自己管理では、取引所やカストディ企業に資産の支配権を預けない代わりに、鍵生成、バックアップ、署名、復旧までの責任が利用者側へ移る。仲介者を外すことで一つの企業への依存は減らせるが、単一のシードへ全権限を集めれば別の単一障害点が生まれる。

そのため大口資産の管理では、どのメーカーのハードウェアウォレットを選ぶかだけでは評価が足りなくなる。異なる機器や独立した鍵を使うマルチシグ、鍵を複数地点へ分ける運用、侵害された署名者だけを交換できる仕組みなど、障害を一か所に集中させない設計が選択肢になる。

もちろん複数鍵には別のリスクがある。保管場所が増えれば管理が複雑になり、復旧手順を誤れば正当な所有者自身が資産へアクセスできなくなる。そのため今回の教訓は、すべての利用者が直ちにマルチシグへ移行すべきという話ではない。資産規模や利用方法に応じて、一つの故障や一つの秘密情報の流出が全残高の喪失へ直結する構成になっていないかを確認することにある。

ウォレット事業者側でも評価軸は広がる。端末がオフラインか、セキュアエレメントを備えているかだけでなく、乱数生成をどのように検証するのか、重大な問題が判明した際に既存ユーザーの鍵をどう移行させるのかまで、製品の安全性として問われる。

資金・規制・流動性との関係

今回の問題は市場流動性を直接変える事件ではない。ただし秘密鍵の修復ができないため、影響を受けた利用者は新しいシードを作り、実際にオンチェーンで資産を移動する必要がある。通常のソフトウェア障害と違い、セキュリティ更新が保有資産そのものの移転を伴う点に特徴がある。

多数の利用者が同時に移行すれば、オンチェーン取引件数や手数料需要へ一時的な影響が出る可能性はある。ただし今回の事件によってビットコイン市場全体の流動性が大きく変化したと確認されているわけではない。資金面で見るべきなのは相場への影響より、侵害発覚後に安全なアドレスへ資産を移せる体制があるかだ。

機関投資家やカストディ企業では、この復旧設計がより重要になる。大規模な保有資産を一つのシードや一台の署名装置へ集中させていれば、問題発生時に全資産の緊急移動が必要になる。複数の承認主体へ権限を分散し、問題のある鍵だけを交換できれば、移行時の運用負担や誤操作リスクを抑えやすい。

規制面では、今回のコールドカード問題を受けて新しいカストディ規則が導入されたと確認されているわけではない。ただし金融機関が暗号資産を扱う際には、鍵を誰が保有するかだけでなく、生成方法、承認手順、バックアップ、鍵交換、インシデント対応をどのように管理しているかが実務上の重要項目になる。自己管理と機関カストディの双方で、秘密鍵のライフサイクル全体を評価する必要性を示す事例といえる。

初心者向け補足

秘密鍵とは、ビットコインなどの暗号資産を動かすための署名に使う秘密情報だ。多くのウォレットでは、複数の単語で構成されるシードフレーズから秘密鍵を復元できる。そのため端末が手元にあっても、第三者にシードを再現されれば資産を移動される可能性がある。

エントロピーは、その秘密情報がどれだけ予測しにくいかを表す尺度と考えると分かりやすい。ビット数が増えるほど候補数は急激に増える。今回コインカイトは、本来128ビットを目標としていたシードについて、Mk2とMk3では約40ビット、Mk4、Mk5、Qでは約72ビットまで低下していた可能性を示している。

ハードウェアウォレットは有効な防御手段だが、それだけで安全性が保証されるわけではない。秘密鍵を外部端末から隔離する機能と、秘密鍵を十分な乱数で正しく生成する機能は別の問題だからだ。今回の事例は、保管方法だけでなく生成段階まで確認する必要性を分かりやすく示した。

Web3Timesの視点

Web3Timesがコールドカード事例から見るのは、特定メーカーの安全性を評価することではない。焦点は、自己管理型暗号資産が一つの秘密情報へ大きな権限を集中させやすい点にある。

約1億1,600万ドルという暫定被害額以上に重要なのは、問題が2021年に入り込み、数年後まで生成済みシードの中に残ったことだ。秘密鍵は一度作れば終わりではない。生成方法の検証、ファームウェア更新、バックアップ、署名、異常発生時の交換までを継続して管理する必要がある。

AIについても線引きが必要だ。今回の盗難で攻撃者がAIを利用したことは確認されていない。コード解析や候補探索の自動化が進めば弱い秘密情報を探すコストが下がる可能性はあるが、それは今回の攻撃について確認された事実とは別の将来リスクとして扱うべきだ。

今後追うべきなのは最終的な盗難額だけではない。対象シードからどの程度の資産移行が進むのか、ウォレット企業が乱数生成をどう検証するのか、大口保有者やカストディ事業者が一つの署名権限に依存しない運用をどこまで採用するのかが重要になる。自己管理の次の安全性は、秘密鍵をより厳重に隠すことだけではなく、どこか一つが破られても資産全体の支配権まで失わない仕組みを作れるかによって決まる。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

Web3をやさしく解説するOba3

目次