COLDCARDの事件：ウォレットの「ランダム」シードがランダムではなかった時

概要

2026年7月30日より、COLDCARDビットコインハードウェアウォレットから複数のウェーブにわたって資金が引き出され、その後数日間にわたって被害が拡大し続けた。単一のオンチェーン攻撃トランザクションも脆弱なコントラクトも存在せず、損失はオフラインのシード回復問題に続くオンチェーンでの資金引き出しによるものであった。2026年8月7日時点で、オンチェーン追跡により約4,925アドレスから1,405 BTC（8月7日の価格$64,700換算で約$91M）以上が流出したことが確認され [1]、ウェーブ単位の帰属分析では10のウェーブにわたり約1,433 BTCに達し [2]、被害者との非公開チャンネルでの照合では最大2,055 BTC（約$133M）という数字が出ている [3]。

根本原因はウォレットのエントロピー障害であった。2021年のファームウェア移行において、シード生成がngu.random.bytes()を経由するようになり、意図されたSTM32ハードウェアRNGではなく決定論的なソフトウェアジェネレーターにフォールバックしていた。影響を受けたデバイスでは、シード回復が暗号学的に解読不可能な問題から、オフラインの探索問題へと縮退した。これにより、攻撃者は候補シードを列挙し、公開ウォレットデータと照合することで秘密鍵を回復できるようになった。本インシデントに関する以前の週次分析を踏まえ、この詳細分析では影響を受けたデバイス世代ごとの残余エントロピーを定量化し、被害者および盗難資金のオンチェーン特定方法を追跡し、ホットフィックス後のファームウェアリグレッションによりログイン前にサービスが拒否される可能性のある別問題を検討する。

背景

COLDCARDはビットコインハードウェアウォレットである。他のセルフカストディウォレットと同様に、そのセキュリティは最終的にウォレット設定時に生成されるシードフレーズの予測不可能性に依存している。BIP-39シードフレーズは人間が読める形式であるが、根底にあるセキュリティ特性は依然としてそれを作成するために使用されたランダムバイトのエントロピーである。シード生成の出力が予測可能であれば、その後どれだけ慎重にシードが保管されても、ウォレットのセキュリティは崩壊する。

COLDCARDはMk1からMk5のハードウェアリビジョンおよびQモデルに及ぶ。Mk2とMk3はレガシーファームウェアラインを使用する。Mk4、Mk5、QはそれぞれStandardとEdgeのリリーストラックを使用する。

COLDCARDのアプリケーションロジックの大部分はMicroPython上で動作するPythonであり、ネイティブCモジュールがハードウェアおよび暗号演算を提供している。安全なシード生成パスはSTM32ハードウェアRNGから32バイトを読み取り、周辺機器が停止するか値を繰り返した場合には失敗し、結果をハッシュ化してからBIP-39ワードとしてエンコードする必要がある。v3.2.2では、make_new_wallet()はこのパスに従っていた：

make_new_wallet()
  |- ckcc.rng_bytes(seed)
  |    `- random_buffer()
  |         |- STM32 RNG->DRを読み取る
  |         `- タイムアウトまたは重複出力時に失敗
  |- SHA-256(seed)
  `- BIP-39シードワード

脆弱性分析

根本原因はMICROPY_HW_ENABLE_RNGに関するビルドおよびインテグレーションエラーであった。COLDCARDのプロダクションボード設定はこのマクロを0に設定していた。これは、ファームウェアがMicroPythonのハードウェアRNG実装ではなく、独自のボードローカルなハードウェアRNGラッパーを使用していたためである。しかし、ウォレット生成パスはngu.random.bytes(32)に移行されており、libnguのSTM32パスは最終的にグローバルなrng_get()シンボルに依存していた。

影響を受けるパスはlibnguのmy_random_bytes()に入った。各出力ワードに対して、CHIP_TRNG_32()が返す値と独自のYasmarang出力をXORした：

generate_seed()
  `- ngu.random.bytes(32)
       `- my_random_bytes()                [libngu]
            |- CHIP_TRNG_32()
            |    `- rng_get()              [MicroPython]
            |         `- Yasmarang A
            |              `- UID + SysTick + RTC
            |
            |- my_yasmarang()              [libngu]
            |    `- Yasmarang B
            |         |- Mk2/Mk3: 公開初期状態
            |         `- Mk4/Q/Mk5: 32ビットpadの再シード
            |
            `- 出力 = Yasmarang A XOR Yasmarang B

Yasmarang AはMicroPythonのrng_get()の背後にあるフォールバックであり、デバイスおよびタイマー状態から初期化された。Yasmarang Bはlibnguのものであった：Mk2/Mk3では公開初期値を使用し、Mk4/Q/Mk5ではセキュアエレメント由来のデータで32ビットのpadのみを置き換えた。ボードローカルのSTM32 RNGは依然として存在していたが、ngu.random.bytes()はそれを呼び出さなかった。

この不一致はビルド設定に直接現れている。Mk4のmpconfigboard.hはMicroPythonのハードウェアRNGブランチを無効化していた：

// このコードは独自バージョンを持つ。
#define MICROPY_HW_ENABLE_RNG (0)

libnguのCHIP_TRNG_32()は、マクロが存在するかどうかのみチェックしてからrng_get()を呼び出すことで、マクロがハードウェアRNGの十分な証明であると依然として扱っていた：

extern uint32_t rng_get(void);
#define CHIP_TRNG_32() rng_get()

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

このガードは危険なケースを見逃している：0として定義されたマクロは依然として定義済みである。そのためビルドは成功し、rng_get()はCOLDCARDの別個のボードローカルラッパー（random32() / random_buffer()、Pythonにはckcc.rng_bytesとして公開）ではなく、MicroPythonのSTM32 RNGモジュールに解決された。MicroPythonのrng_get()の選択では、MICROPY_HW_ENABLE_RNG == 0がソフトウェアフォールバックブランチを選択した：

#if MICROPY_HW_ENABLE_RNG
    // STM32ハードウェアRNG
#else
    // Yasmarangソフトウェアフォールバック
#endif

Mk2/Mk3：約40ビット

コンパイルされたpyb_rng_yasmarang()フォールバックは、次のようにYasmarangを初期化および進行させた：

STATIC uint32_t pyb_rng_yasmarang(void) {
    static bool seeded = false;
    static uint32_t pad = 0, n = 0, d = 0;
    static uint8_t dat = 0;

    if (!seeded) {
        seeded = true;
        rtc_init_finalise();
        pad = *(uint32_t *)MP_HAL_UNIQUE_ID_ADDRESS ^ SysTick->VAL;
        n = RTC->TR;
        d = RTC->SSR;
    }

    pad += dat + d * n;
    pad = (pad << 3) + (pad >> 29);
    n = pad | 2;
    d ^= (pad << 31) + (pad >> 1);
    dat ^= (char)pad ^ (d >> 8) ^ 1;

    return pad ^ (d << 5) ^ (pad >> 18) ^ (dat << 1);
}

変数は104ビットを占めるが、状態サイズはエントロピーではない。datはゼロから始まり、他の値は独立した秘密ではなく固定メタデータまたは相関するタイマー読み取り値である。約40ビットという概算値に使用されたMk2/Mk3の緩いモデルでは：

すべてのタイマーフィールドを独立と仮定すると、意図的に広い上限が得られる：

80,000 * 86,400 * 256
= 1,769,472,000,000
= 2^40.69 候補初期状態

網羅的な探索は最大2^40.69試行を要し、一様位置仮定のもとでは平均約2^39.69試行となる。これは列挙の上限であり、40ビットの暗号学的エントロピーではない。通常のコールドブート中にRTCレジスタが静的であれば、SysTickのみが残り、上限は約2^16.29に低下する。UID、タイマー、および以前のRNG呼び出し回数が既知であれば、ストリームは正確に1つ、つまり2^0となる。呼び出し履歴が不明な場合、追加されるのは妥当な実行トレースの数のみであり、新しいエントロピー源ではない。同様に、256ビットシードのために8つの32ビットワードを生成しても探索空間は乗算されない：すべてのワードは同じ初期状態によって決定される。

libnguレイヤーでは、my_random_bytes()が上記のMicroPythonフォールバックとlibngu独自のYasmarangジェネレーターを混合した。ソースコードには文字通りchip = rng_get()は含まれていない：CHIP_TRNG_32()がrng_get()に展開される。Mk2/Mk3では、2番目のジェネレーターは公開定数から始まった：

static uint32_t yasmarang_pad = 0x0a8ce26f, yasmarang_n = 69, yasmarang_d = 233;
static uint8_t yasmarang_dat = 0;

uint32_t chip = CHIP_TRNG_32();
// ... 隣接出力ヘルスチェック ...
chip ^= my_yasmarang();

両ストリームは、MicroPythonフォールバック状態と呼び出し履歴が既知であれば再現可能であった。XORは出力値を変更したがエントロピーを追加しなかった。UID_low32が不明であっても、UID_low32 ^ SysTickは依然として両入力を1つの32ビットpadに集約する；それらの名目上のビット数は加算できない。

Mk4/Q/Mk5：約72ビット

後継モデルは同じ2ジェネレーター構造を維持したが、rng_seeding()がブート時にlibnguのジェネレーターにセキュアエレメントのデータを追加した：

a = callgate.read_rng(1)       # SE1
b = callgate.read_rng(2)       # SE2

n = ngu.hash.sha256d(a + b)
n, = ustruct.unpack('I', n[0:4])
ngu.random.reseed(n)

40バイトがハッシュに入力されたが、reseed()に到達したのは最初の4バイトのみであった [4]。random_reseed()実装はその後、libnguの32ビットpadワードのみを置き換えた：

STATIC mp_obj_t random_reseed(mp_obj_t arg)
{
    yasmarang_pad = mp_obj_get_int_truncated(arg);
    return mp_const_none;
}

他のlibngu状態ワードは公開値を維持し、MicroPythonフォールバックは再シードされなかった。約72ビットという概算値は、32ビットのlibngu再シードと後継モデルのタイマー状態の緩い上限を組み合わせたものである：

MicroPythonフォールバック：
    120,000 SysTick値 * 86,400 RTC時刻 * 256サブ秒
    = 2^41.27 状態

libnguセキュア再シード：
    2^32 値

合計上限：
    2^41.27 * 2^32 = 2^73.27 候補

平均列挙：
    2^73.27 / 2 = 2^72.27 試行

これが「約72ビット」という数値の出所である。これはセキュアエレメントが供給する72ビットではなく、平均攻撃作業量の推定値である。タイマーフィールドは相関しており再構築可能であり、MicroPythonフォールバック状態が既知であれば、2^32の再シード値のみが残り、平均2^31試行となる。最終的な32ランダムバイトをハッシュ化しても、可能なシードの数を増やすことはできない。

影響を受けるバージョン

関連するバージョンは現在インストールされているファームウェアではなく、シードを生成したファームウェアである。修正済みリリース以降に生成された新しいシードは修正されたパスを使用するが、更新によって既存のシードは修復されない。公式の影響範囲はMk2/Mk3についてv4.0.1から始まる [5] 一方、ソースレベルの分析ではv4.0.0も含まれる [4]。独立したダイスエントロピーによってシードのセキュリティを向上させることができるが、強力なBIP-39パスフレーズを後から追加しても、シード自体を修復することなく独立したバリアを追加するに過ぎない [6]。

被害者と資金の追跡

追跡すべきオンチェーンのエクスプロイトトランザクションは存在せず、回復は必然的にオフラインで行われた。影響を受けたファームウェアで生成されたシードを対象とする攻撃者は、上述の候補RNG状態を制約・列挙し、各候補のシード生成ストリームを再現し、得られたウォレット鍵を導出して公開ウォレットデータと照合し、マッチした資金のあるウォレットをオンチェーンで引き出すことができた。これはシードのみから導出可能なウォレットにのみ到達した：強力で一意のBIP-39パスフレーズはRNG欠陥が決して触れなかった独立したユーザー提供エントロピーをPBKDF2を通じて鍵導出に混合するため、そのようなウォレットは純粋なシード列挙の範囲外となる。引き出されたウォレットは必然的にそのような保護を持たないものであった [6]。盗難は追跡可能なエクスプロイトではなくオンチェーンの引き出しとしてのみ表面化したため、被害者の特定と資金の追跡はオンチェーンフォレンジックの問題となった。

いくつかの独立した取り組みが盗難資金を追跡した：公開追跡サイト（Coldcard Sweep Watch [1]、coldcard.rip [2]、Coldcard Hack Tracker [7]）および Galaxy Researchによるプライベートチャンネルでの照合 [3]。報告された合計を以下に比較する。Coldcard Sweep Watchがその方法論を公開しているため、オフチェーンレポートとオンチェーン分析のフィードバックループである特定プロセスを説明するためにそれを使用する：

1. オフチェーンのアンカー。 被害者や研究者が公開アドレスやトランザクションID、利用可能な場合はデバイスとシード生成のコンテキストを提供した。各レポートはリードとして扱われ、オンチェーンで確認された；シードフレーズ、秘密鍵、xpubは不要であった。
2. オンチェーンの拡張。 確認されたアンカーを起点として、スキャナーが同じ引き出し特性を持つ関連ブロックを検索した：おつりなしで空にされたウォレット、類似の入力タイプ、タイミングの近さ、繰り返されるフィーレート、共通の宛先、または後の共同支払い。
3. オフチェーンのクロスチェック。 新しい被害者レポート、研究者のデータセット、サービス帰属が候補ウェーブの確認または棄却に使用された。確認されたクラスターとヒューリスティック候補は別々に保持された。

Bitcoinはアドレスを識別するものであり、人やウォレットモデルではない。1つのウォレットが多数のアドレスを管理する可能性があるため、アドレス数は被害者数ではない。最初に広く報告された主要なウェーブ960188は594.48 BTCを占め、継続的なスキャンと報告により合計が増加した。2026年8月7日時点で、Coldcard Sweep Watchは約4,925アドレスから確認済みの最低値として約1,405.07 BTC（8月7日の価格$64,700換算で約$91M）を報告し [1]、8月3日のcoldcard.ripのスナップショットは10のウェーブにわたる5,477アドレスから総額最大1,433.13 BTC、手数料後の宛先への1,432.48 BTCを帰属させた [2]。Galaxy Researchによる被害者との連絡に基づく別個のプライベートチャンネル照合では、約1,596 BTCから最大2,055 BTC（同価格換算で約$133M）というさらに高い数字が出た [3]。差異は証拠の閾値、発見時期、および各追跡者が依拠する確認チャンネルを反映している。

資金はその後、3つの観察された層を通じて追跡された：引き出し元アドレス、直接の引き出し先（holding）、および後続の統合先（vault）。表は各層の個別アドレス数を示す：

追跡された出力が移動する際、分析は手数料後の価値を保存し帰属を引き出し額で上限を設けながら、分割、合併、ピールチェーンを追跡する。取引所やその他のコミングルサービスに入金された資金は信頼性を低下させ、サービスは攻撃者クラスターに追加されない。

修正が必要だった修正：潜在的なブリッキングリグレッション？

エントロピー障害とは別に、それを解決したホットフィックスは別個のファームウェアリグレッションをもたらした [8, 9]。ハードウェアRNGパスを復元する際、修正はハードウェアシードエラー状態を未処理のままにしており、これによりログイン前にサービスが拒否される可能性があり、デバイスが永続的にブリックされたという主張が出た。その強い主張がどの程度成立するかは、レジスタレベルの詳細によって決まる。

STM32ハードウェアRNGはコントロールレジスタ（RNG_CR）、ステータスレジスタ（RNG_SR）、32ビットデータレジスタ（RNG_DR）を公開している。関連するステータスは：

現在のステータスとラッチされたステータスの違いが重要である。SECSは現在のノイズソース状態を表し、SEISはソフトウェアがクリアするまでシードエラーが発生したことを記録する。Mk4/Qファミリーの STM32L4Sでは、シードエラーは新しい乱数生成を停止させる；Mk3のSTM32L4ではデータは利用可能であり続ける可能性があるが、信頼すべきではない。クロックエラーは別個であり、このシードエラーロックアップを引き起こさない。

必要な回復シーケンスはSTM32世代によって異なる：

7月31日のエントロピーホットフィックスはrng_get()をハードウェアTRNGに正しく解決させたが、Mk4/QファミリーのRNGエラー管理の詳細についてはrng_get_or_fault()はシードエラー回復を実装していない。rng_init()はRNGENがクリアの場合にのみ動作し、読み取りループはDRDYのみを確認する。シードエラーがRNGENを有効のままDRDYを抑制した場合、初期化はno-opになり、各読み取りは10ms待機してSEISをクリアせずにOSError(EFAULT)を発生させる。

これはログイン前のUIに到達する可能性がある。テンキーmempad._start_scan()とQ keyboard._start_scan()はどちらもキー押下割り込みからスキャン順をシャッフルする。そこでのRNG例外は、そのハードウェアセッションの残りの間、PIN入力と通常のファームウェアアップグレードメニューをブロックする可能性がある。

コードレベルの障害パスは信頼できるが、より強い「永続的なブリック攻撃」という主張は確立されていない。RNGコントロールおよびステータスビットはハードウェアリセット時にゼロにリセットされるため、単一の一時的なエラーが周辺機器を永続的に損傷させるべきではなく、完全な電源サイクルをまたいだ持続性は実証されていない。シードヘルステスト失敗を引き起こすリモートまたは確実に制御された方法も実証されていない。あるXへの投稿 [8]はブリックが確認されたと述べたが、それが指摘したPR、コミュニティ提出のPR #692 [9]は、著者自身がレジスタモックで障害を分析し、実際のMk4/Qハードウェアで再現せず、フィールドレポートを独立して確認しなかったと述べている。したがって、最も支持される分類は確認された永続的なブリック攻撃ではなく、潜在的なログイン前のサービス拒否および信頼性リグレッションである。

メンテナー自身の修正PR #693 [12]はシードエラーフラグを確認し、制限付きの回復とリトライを追加し、疑わしいサンプルを拒否し、予想されるキーパッドエラーのみをキャッチする。2026年8月5日にマージされ、2026年8月4日にマージされずにクローズされたコミュニティPR #692 [9]に取って代わった。

結論

このインシデントはウォレットエントロピー障害であり、影響を受けたデバイスとワークフローにおいてシード回復を暗号学的に解読不可能な問題からオフラインの探索問題へと変えた。重要なエンジニアリング上の失敗は、出荷されたファームウェアがセキュリティクリティカルなシード生成APIが実際に意図されたハードウェアRNGに到達していることを証明していなかったことである。ビルドガードはマクロの存在とマクロの値の両方を確認する必要があり、暗号エントロピーのフォールバックはフェイルクローズでなければならず、CIは最終ファームウェアイメージでのシンボルの出所とエンドツーエンドのエントロピーフローを検証すべきである。影響を受けたユーザーにとって、対処法はファームウェアの更新ではない：更新しても欠陥のあるパスで生成されたシードは修復されず、後からパスフレーズを追加してもそのシードのアドレスに既に保有されている資金は保護されない。それらの資金は修正済みリリースで作成された新しいシードからのウォレットに移動する必要があり、強力で一意のパスフレーズの背後に既にあった資金のみがシード単独の列挙の範囲外にあった [6]。

参考文献

• [1] Coldcard Sweep Watch — 確認済みの引き出しアドレスセットと損失追跡
• [2] coldcard.rip — インシデント台帳、経路、帰属
• [3] Galaxy Research — 被害者レポートによるCOLDCARD損失推定
• [4] Block Engineering — COLDCARDファームウェアにおける予測可能なRNGフォールバックと32ビット再シード
• [5] Coinkite — COLDCARDセキュリティアドバイザリと影響を受けるファームウェアの範囲
• [6] Coinkite — エントロピー問題に関する技術的詳細
• [7] Coldcard Hack Tracker — リアルタイムのウェーブ別引き出し合計
• [8] ホットフィックス後のRNG障害によりデバイスが永続的にブリックされる可能性があると主張するXへの投稿
• [9] ColdcardファームウェアPR #692 — コミュニティによるTRNG障害回復提案（マージされずにクローズ）
• [10] STMicroelectronics RM0351 — STM32L4 RNGレジスタとエラー管理
• [11] STMicroelectronics RM0432 — STM32L4S RNGレジスタとエラー管理
• [12] ColdcardファームウェアPR #693 — 制限付きリトライTRNG回復とキーパッドエラー処理のマージ