COLDCARD で作った鍵から、7月30日以降にビットコインが引き出され続けている。原因は端末が盗まれたことでも、パスワードが漏れたことでもない。鍵を作るときに使われた乱数が、設計者の想定より弱かった。オフラインに置いてあること自体は、何も守っていなかった。自分の端末が対象なのかどうか、そして対象だったとき何をすれば済むのかは、メーカーが条件つきで公開している。まずその条件を正確に読むところからだ。
「COLDCARD だから危ない」ではない
対象の範囲は、機種でも購入時期でもなく、鍵をどう作ったかで決まる。
Coinkite が8月1日に更新した技術説明によれば、リスクがあるのは「影響を受けたファームウェアで生成した種（シード）」のうち、次の 2 つのどちらにも当てはまらないものだ。
- 生成時に 50 回以上の独立した、人に見られていないダイスロールを加えた
- その資金を、強くて固有の BIP-39 パスフレーズで保護している
機種別の条件はこうなっている。Mk2 と Mk3 はファームウェア 4.0.1 から 4.1.9 で生成した種が対象。Mk4・Mk5・Q は、標準トラックなら 5.6.0 未満（Q は 1.5.0Q 未満）、Edge トラックなら 6.6.0X 未満（Q は 6.6.0QX 未満）で生成した種が対象になる。
TAPSIGNER、OPENDIME、SATSCARD は鍵の作り方が違うため対象外だと同社は明記している。
パスフレーズについては、条件が厳しく書かれている。短いもの、よくある語、規則性のあるもの、引用、使い回し、どこかに出したことがあるもの、そして「これで合っていたか自信がない」もの——いずれも該当しない、つまり資金は危険なものとして扱えという指示だ。さらに、強いパスフレーズがあっても、それは当面の露出を減らすだけで、種そのものは直らないとしている。
ファームウェアの更新は、修理ではない
ここが一番間違えやすいところだ。
新しいファームウェアが直すのは、これから作る種である。既に作られてしまった種の安全性は回復しない。Coinkite の説明もその一文をはっきり置いている。新しい種を作り、資金をそちらへ移して初めて安全になる。
そのうえで同社が示している順序は、機種によって少し違う。
Mk2・Mk3 の場合は、まず端末を更新し、その更新済みの端末で完全に新しい種を生成する。新しいバックアップ、ウォレットの指紋（フィンガープリント）、受け取りアドレスを記録して照合する。残りの資金を動かす前に、少額のテスト送金を先に済ませる。古いバックアップは、移行が完了して確認できるまで捨てない。
Mk4・Mk5・Q の場合は、新しい種を作る前に、自分が使っているリリーストラック向けの修正版へ上げる。修正版が端末側で生成する種で足りるとされていて、ダイスロールは任意であり、この問題への対処としては必須ではない。新しい種とパスフレーズを別々に保管し、端末を再起動してから指紋と受け取りアドレスを照合する。
標準トラックと Edge トラックが別系統である点も注意が要る。バージョン番号が大きいから新しい、とは限らない。Edge の古い 6.x を「標準の 5.6.0 より数字が大きいから安全」と読むのは誤りだと、同社は名指しで注意している。
移行そのものに、失敗のしかたがある
手順を踏むこと自体にコストと落とし穴がある。ここを飛ばして「やればいい」とは言えない。
パスフレーズは、入力するたびに別のウォレットを作る。打ち間違えたパスフレーズでも、エラーにはならず、有効な別のウォレットが生まれる。だから資金を入れる前に指紋を照合しろ、と書かれている。逆に言えば、照合を省いたまま送金すると、二度と開けない場所へ送ることになる。パスフレーズを失えば、そのウォレットへは二度と入れない。
少額のテスト送金を先に、というのも同じ理由だ。工程を 1 回分増やす手間と手数料を払って、取り返しのつかない失敗を検出する。
古いバックアップをすぐ処分しないこと、そして端末自体も捨てないことも求められている。資金が回収された場合に端末が必要になりうる、というのが同社の説明だ。
時間の要素もある。同社は8月2日の投稿で「脅威は現実であり、進行中だ」と書いている。移行を落ち着いて 1 手ずつ確認しろという指示と、急げという指示が同時に来ている。この二つは矛盾しない——確認を省いた速さは、別の失い方につながるからだ。
「オフラインだから安全」が隠していたもの
何が壊れていたのかは、同社が自分で書いている。
2021年、COLDCARD は楕円曲線の処理を Bitcoin Core の実装へ移した。その移行のために組み込みライブラリを追加したところ、種の生成経路が、端末のハードウェア乱数ではなく MicroPython のソフトウェア乱数へ落ちてしまった。「暗号の選択は健全だった。統合がそうではなかった」と同社は書いている。
Mk2・Mk3 では、動いていた擬似乱数が主に端末の状態とタイミングから種を得ていた。同社の見積もりでは、探索範囲は約 40 ビット。本来目標としていた 128 ビットには遠い。Mk4 以降は別の要素が加わって影響が部分的に減っていたが、目標水準は回復していなかった。TRM Labs の分析も同じ幅を示している。
この経路は、暗号のロジックの中にはない。無関係な 2 つのモジュールの境界にあった。内部レビューも第三者監査も、通常は暗号の中心部分を見る。フラグの検査は正しく見えていたため、不具合は静かに残った。
そして、AI についての記述がある。Coinkite は事故の数週間前に、当時入手できる最良の AI モデルの一つで自社コードのセキュリティレビューを行い、この不具合も、それに類する重大なものも検出できなかったと書いている。同社はさらに、ソースコードが常に公開されてきた以上、誰かが AI で過去のファームウェアを読んでこの問題に行き当たったと想定せざるをえない、とも述べている。「攻める側も守る側も同じ AI ツールを持っている。今日それは我々の役には立たず、悪い側だけを助けた」。
事故後にフロンティアモデルで再度試したときも、検出できたものはなかったという。同社は、AI レビューに頼っているチームに対して、ビルドとサブモジュールの境界を明示的に対象にして検証するよう勧めている。
自分の側に、何を検証できる状態で置いておくか
今回の事故が示したのは、自己保管が悪いということではない。自分で持つと決めた時点で、検証の責任も自分の側に来ている、ということだ。
鍵を他人に預けなければ、預け先が破綻するリスクは消える。代わりに、鍵を作った道具が正しく動いていたかを誰も代わりに保証してくれない。今回それを確かめたのは、メーカーでも監査でもなく、公開されたコードを読んだ誰かだった。
だとすれば、置いておける選択肢はいくつかある。ダイスロールのように、装置の乱数を信じなくても済む作り方を選ぶ。単一の端末に全部を置かず、作り方の違う複数の道具に分ける。あるいは、そこまでの手間を引き受けないと決めて、預ける先を選ぶ方を検討する。どれが正しいかは、持っている額と、確認に割ける時間と、失敗したときに何が起きるかで変わる。
Coinkite は、COLDCARD に関する過去のセキュリティ研究・開示・監査を年表にまとめたページを新たに公開した。自分の道具について、こうした記録がどこにあるのかを知っているかどうかも、判断材料の一つになる。
あなたが今使っている道具は、どこの乱数で鍵を作っているだろうか。そして、それをあなたはどうやって確かめられるだろうか？
参照
- Coinkite「Technical Deep Dive into the Entropy Issue」(2026年8月1日更新・対象条件、機種別の移行手順、探索範囲約40ビットの見積もり)
- Coinkite「Update, Sunday.」(2026年8月2日・端末を廃棄しない要請、脆弱ファーム在庫の破棄、TAPSIGNER/OPENDIME/SATSCARD は非対象)
- Coinkite「Adding to the Public Record」(2026年8月4日・サブモジュール境界の不具合と、AI レビューが検出できなかった経緯)
- COLDCARD Security Disclosure History (Coinkite・公開済みの研究・開示・監査の年表)
- TRM Labs (流出規模と、鍵強度が128ビットから最小40ビットへ下がったとする分析)
- CoinDesk (2026年8月4日・流出が継続中であることと対象ファームウェアの報道)
