なぜ仮想通貨の「乱数の弱さ」が今も数億円規模の被害を生むのか

2026年7月31日、攻撃者が約25分で500件ほどのビットコインウォレットを一掃しました。合計594BTC、約3,800万ドル相当が移動し、被害者はいずれも「このリスクを避けるため」にハードウェアウォレットを購入していたユーザーでした。
 

Coinkite disclosed that COLDCARD firmware had been generating keys using a software pseudorandom number generator rather than the hardware generator built into the device. Two functions in the codebase shared the same name and signature, so the linker selected the wrong one, and the build produced no warning.
 

これは長年続く被害リストの最新事例です。過去10年で最大規模の仮想通貨流出は、奇抜なハッキングよりも「十分にランダムでない乱数（エントロピー）」が原因となるケースが目立ちます。

秘密鍵の裏側で何が起きている？

仮想通貨ウォレット（アプリ・ブラウザ拡張・ハードウェア型）は、誰にも推測・再現できない数字を正しく生成できるかどうかにかかっています。ここでいう「エントロピー」とは、その数字にどれだけ予測不可能性があるかを示します。

Entropy is the raw randomness a wallet uses to create a private key, measured in bits. More bits mean a larger space of keys that an attacker must search. It enters a wallet at setup. Every key, address, and signature after that follows fixed mathematical rules, so no new randomness arrives later.

エントロピーの供給源

理論上、ウォレットはpseudorandom number generator（PRNG）から乱数を取得できます。これは「真の」エントロピーを元に、必要なだけ乱数を伸ばすアルゴリズムですが、初期シード自体が予測困難でなければ意味がありません。

ブラウザタブや起動直後のスマートフォン上で動くソフトウェアは、しばしば「感覚遮断室」のような状態からスタートします。本当にランダムな数字を生み出すには、計算だけでなく外部世界からの“ノイズ”——たとえばプロセッサのタイミング変動やマウスの動き、専用ハードウェア部品——が必要です。

デバイスの起動直後、こうしたノイズのプールは空か、初期化途中かもしれません。暗号ライブラリが早すぎるタイミングで乱数生成器を呼び出すと、理論上はランダムでも、実際には探索可能な範囲の狭い数字しか出ない場合があります。

ブラウザにも独自の制約があります。JavaScriptのMath.random()は元々セキュリティ用途ではなく、より安全なcrypto.getRandomValues()もOSのエントロピープールに依存します。このプールが弱いと（モバイルサンドボックス・仮想マシン・IoT端末など）、乱数は秘密鍵生成前にすでに危険な状態になってしまいます。

取引署名における乱数

ビットコインやイーサリアムの取引署名時、秘密鍵を直接使うのではなく、nonce（一度限りの乱数）を生成し、秘密鍵と組み合わせてECDSA（楕円曲線デジタル署名アルゴリズム）で署名を作ります。

ここで問題なのは、同じnonceが同じ秘密鍵で2回使われると、数式上その秘密鍵を逆算できてしまう点です。
ECDSA署名は（r, s）の2つの数値ペアで、

• 秘密鍵（d）、
• nonce（k）、
• ハッシュ化された取引メッセージ（z）

kが異なる2つのメッセージで同じ値だと、2つの署名式が並び、両方を見た第三者がkを計算できてしまいます。一度kが分かれば、d（秘密鍵）は掛け算と逆数計算だけで導出されてしまいます。

2013年、a flaw in Android’s SecureRandom function caused early Bitcoin wallets on the platform to produce predictable nonces. Funds vanished from wallets before most users had any idea there was a problem.

この種のバグは、ソースコードを読んだだけでは見抜けません。関数呼び出し自体は正しく見えても、実際に出力されるビットを測定し、統計的なテストで予測困難性を確認しない限り、致命的な弱点が長期間誰にも気付かれず潜むことがあります。

エントロピーが長年にわたり脆弱性となる理由は、以下の通りです：

• Startup entropy drought：起動直後のデバイスは、PRNGのシードとなる十分な環境ノイズをまだ蓄積していない場合があります。

• Browser limitations：JavaScriptのMath.random()は安全ではなく、crypto.getRandomValues()もホスト環境のエントロピーに依存します。

• Unsafe tooling：バニティアドレス生成ツールやオフラインスクリプト、管理の甘いライブラリは、速度や再現性を優先して乱数の質を犠牲にしがちです。

• Human input：「ブレインウォレット」やユーザーが選ぶフレーズは、辞書攻撃で簡単に破られています。

暗号業界では、ハードウェア乱数生成器（HRNG）が長年推奨されています。電子ジッターや熱雑音、放射性崩壊など物理現象を乱数ビットに変換し、自己診断で故障や偏りも検出できます。

ハードウェアで解決する方法

高信頼システムでは、鍵を「認証済みHRNG内蔵チップの内部で生成し、絶対に複製させない」ことが基本です。

A secure element is a purpose-built, tamper-resistant microcontroller. It is a fortified chip designed to store secrets and perform cryptographic operations without revealing the underlying keys. They are the same class of component used in passports to prevent cloning, SIM cards to authenticate devices to mobile networks, and contactless payment cards to authorize transactions.

A secure element can house a hardware random number generator that draws its unpredictability from physical noise, such as thermal fluctuations or oscillator jitter, rather than from mathematical algorithms alone. 

These HRNGs are not just “once-and-done” devices. Under standards such as NIST SP 800-90B, they must perform continuous health tests, checking every output stream for statistical bias, stuck bits, or other failures that could degrade randomness over time. If anything looks suspicious, the chip can halt key generation immediately. In a good hardware wallet, the secure element’s HRNG feeds randomness directly into the key-generation process inside the chip itself. 

すべての「ハードウェア」が同じではない

ハードウェアウォレットという言葉は幅広い設計を含みますが、乱数や秘密鍵の隔離レベルは製品ごとに大きく異なります。

下位モデルでは、汎用マイコン上に構築されたものもあり、これらは物理攻撃やサイドチャネル攻撃への耐性より柔軟性を重視しています。多くは簡易的な乱数生成器を搭載しますが、

それも内部状態からシードされたpseudorandom generatorで、必ずしも基準を満たすHRNGではありません。こうした設計では、鍵生成がファームウェア内で行われ、生成された秘密鍵がRAMやフラッシュメモリに一時保存されることもあります。つまり、ファームウェアのバグやサイドチャネル攻撃、物理的な改ざんで鍵が漏れるリスクがあります。
 

一方、secure elementベースのウォレットは、エントロピー源と鍵生成ロジックの両方を耐タンパー環境内に置きます。このモデルは厳格なアクセス制御も実現し、署名や派生などの暗号処理はチップ内部だけで完結し、秘密自体は外部に出ません。

標準はすでに存在する

乱数問題は未解決の科学課題ではありません。暗号の専門家は「良いエントロピー」の要件をすでに標準化しています。米国National Institute of Standards and Technology（NIST）はSP 800-90シリーズで課題を細分化しています。

SP 800-90Bはエントロピー源の評価法（物理・ソフトウェア由来の予測困難なビット生成プロセス）を定め、各ビットストリームの真のエントロピー推定や、バイアス・故障を監視する組み込みヘルステストを義務付けています。

SP 800-90Cは、こうしたエントロピーとdeterministic random bit generators（DRBG）を組み合わせ、どちらか一方が劣化しても出力が強固なまま維持される仕組みを解説しています。

準拠デバイスは「一度だけ乱数を生成して終わり」ではなく、常に自己診断を行います。HRNGのノイズパターンが変化したり、ビットが「張り付く」・統計閾値を下回る場合、弱い鍵の生成を防ぐためシステムは即座に停止します。

自分の鍵が危険かどうか見分けるには

多くのユーザーはエントロピーを直接測定できませんが、「どこで・どうやって鍵が生成されたか」を確認することはできます。「ウェブページ上」や「古いAndroidアプリ（特に2010年代半ば以前）」で生成した鍵は、弱い可能性が高いです。最も安全なのは、認証済み・記録された乱数を使うハードウェアデバイスで新しいウォレットを作り、資産を移すことです。

エントロピー攻撃の年表

弱いエントロピーは「逆算」すら不要にします。攻撃者は乱数生成器が出しうる鍵の候補を全列挙し、各アドレスの残高をブロックチェーンで調べて盗み出します。主な歴史は以下の通りです：

• 2018—The IOTA seed generator scam：ユーザーはウェブサイトでウォレットシードを作るよう指示され、運営者がそのコピーを保持して後から資金を盗みました。被害額は約400万ドル。この場合、乱数はゼロ——攻撃者は最初から全ての数字を知っていました。
   

• 2019—The Blockchain Bandit：セキュリティ研究者が732件の弱いイーサリアム秘密鍵を特定。何年も監視していた攻撃者が、資金が入金されるたび約45,000ETHを抜き取りました。
   

• 2022—Profanity’s vanity address catastrophe：オープンソースのProfanityツールは、わずか32ビット（約40億通り）のエントロピーでカスタムイーサリアムアドレスを生成。現代のGPUなら数時間で全探索でき、ロンドンのマーケットメイカーWintermuteは約1億6,000万ドルを失いました。
   

• 2023—Trust Wallet browser extension flaw：Ledgerのセキュリティチームの開示で、ブラウザ拡張が約32ビットのエントロピーでウォレットシードを生成していたことが判明。修正は迅速でしたが、数か月間すべての新規ウォレットが危険に晒されていました。
   

• 2025—The LuBian allegation: Arkhamの主張は未検証ですが、127,426BTCもの損失が予測可能な鍵生成に起因していれば、「鍵生成の一歩目のミスが数十億ドルを消し去る」典型例となります。 
   

• 2026: COLDCARD: Coinkite disclosed that a software pseudorandom generator had replaced the intended hardware generator in shipped firmware. The fallback entered the upstream dependency in May 2018 and reached key generation in March 2021.

  Coinkite estimates about 40 bits of effective search space on Mk3 hardware, and about 72 bits on later models that mixed in secure element data. Both figures sit below the 128-bit target.

  A guard existed to prevent exactly this. It tested whether a configuration macro was defined, rather than whether its value was non-zero; the macro was set to zero, so the check passed and the error never fired.

COLDCARDからの乗り換えを検討中ですか？

Tangemは、認証済みsecure elementチップ内でハードウェア乱数生成器を使って鍵を生成します。

シードフレーズ管理にうんざりしている方へ。Tangemのシードレス方式なら、12単語や24単語のフレーズを書き留めたり、写真を撮ったり、紛失したりする心配がありません。過去の多くのウォレット流出事件の根本原因を断ち切ります。

Cure53、Kudelski、Riscureによる独立監査済み。まさにこのリスクのために設計されています。

本当に「ランダムな」乱数でコインを守りましょう。Tangem Walletはこちら。