ハードウェアウォレットは、シンプルな約束の上に成り立っています。鍵をオフラインに保てば、攻撃者は手が届かない、という約束です。
Coldcardのハッキングは、その前提を崩しました。
ある欠陥によって、一部のリカバリーフレーズは作成された瞬間から予測可能になっており、ウォレットがオフラインで物理的に保護されたままでもビットコインが盗まれました。
今週は、この事件がビットコインのセルフカストディへの信頼をどう揺るがし、一部の保有者を取引所へと押し戻したのかを見ていきます。続いて、鍵を予測可能にした技術的な失敗と、影響を受けたウォレットをアップデートしても、すでに作成された鍵は守れない理由を検証します。
ほかにも、自己拡散するnpmワーム、Metabaseのゼロデイ、macOSの画面共有のバイパス、悪用されたLoadMasterの欠陥、バックドア入りのルーター、セキュリティテストのためのLLVM、怪しいGitHub SSO更新メールなどを取り上げます。
この号の内容
🌡️ 脅威レベル：高警戒
⚡ ニュース：押さえておきたいセキュリティニュース5本
🔎 ディープダイブ：Coldcardのハッキングはビットコインのセルフカストディへの信頼をどう揺るがしたか
🎣 これはフィッシング？
🔬 技術研究：ウォレットはオフラインのままだった。それでも攻撃者は鍵を見つけた。
🛠️ 今週のツール：LLVM
👤 今週の人物：Andrea Fioraldi
📅 今週のイベント：Ekoparty Security Conference 2026
📚 今週の本：Black Hat GraphQL
😅 今週のミーム
❓ 最後にひとつ質問
では、始めましょう。
今週のニュースに入る前に、現在の脅威レベルを確認しておきます。
🌡️脅威レベル
⚡ ニュース
400を超えるnpmパッケージが自己拡散するワームに変えられた
ChainDropは、盗まれた公開用の認証情報を通じて人気のJavaScriptパッケージに感染しました。このマルウェアはインストール中に実行され、開発者のワークステーションやCI/CDシステムからnpm、GitHub、クラウド、インフラのシークレットを探し出し、盗んだトークンを使って自動的にさらに多くのパッケージに感染しました。Microsoftは、影響を受けたパッケージを400件以上特定しました。Unit 42は、このワームのデータ窃取パターンに一致する公開GitHubリポジトリを453件発見し、10の環境でその実行を確認しました。
盗まれたトークンが開発者とCIのシステムに感染する。
Metabaseのゼロデイがパスワードリセットを管理者アクセスに変えた
Metabaseは、攻撃者が同社のクラウドサービスに対して未知のSQLインジェクションの欠陥を悪用したことを認めました。脆弱なパスワードリセットのエンドポイントにより、認証情報を持たないリモートの攻撃者が管理者アクセスを得ることができ、接続されたデータベースの認証情報やデータが露出するおそれがありました。Metabaseはクラウドプラットフォームを修正し、セルフホスト版向けの修正もリリースしました。その後、Framework、Tally、Kilo Codeが被害を報告しました。顧客の連絡先情報、パスワードハッシュ、Slackのアクセストークンが関わるものです。
パスワードリセットのバイパスで接続先のデータベースが露出する。
有効なパスワードは不要：AppleがmacOSの画面共有のバイパスを修正
Appleは、同じネットワーク上の攻撃者が有効な認証情報なしでmacOSの画面共有に認証できたことを公表しました。CVE-2026-65400として追跡されているこの脆弱性は認証前に機能し、画面共有が有効なシステムに影響しました。Huntressによると、VNCパスワードの変更や許可ユーザーの制限では悪用を防げませんでした。Appleは8月6日、macOS Tahoe 26.6.1、Sequoia 15.7.9、Sonoma 14.8.9でこの欠陥に対処しました。
ローカルの攻撃者が画面共有の認証をバイパスする。
CISA、悪用されたLoadMasterの欠陥の修正に政府機関へ3日間の猶予
CVE-2026-8037はProgress Kemp LoadMasterに影響します。アプリケーションとサーバーの間でトラフィックを分散する製品です。この欠陥により、認証情報を持たないリモートの攻撃者が、アプライアンスに送られる十分にチェックされていない入力を通じてOSコマンドを実行できます。Progressは影響を受けるバージョン向けの修正をリリースしました。CISAは8月7日、この脆弱性をKnown Exploited Vulnerabilitiesカタログに追加し、連邦政府機関に8月10日を修復期限として設定しました。
認証されていないリクエストが脆弱なロードバランサーを悪用する。
20以上のルーター機種が、root権限のバックドアをデフォルトで有効にした状態で出荷されていた
VulnCheckは、ENDLESSDOORSという名前のリモート制御用インプラントを発見しました。ZbtlinkとWiflyerのブランドで販売されているルーターの内部です。このソフトウェアは外部のインフラと通信し、サーバーを認証することなく、完全なシステム権限でコマンドを実行できます。VulnCheckは、影響を受けるルーターが世界中で少なくとも100,000台配備されている可能性があると推定しています。Zbtlinkは8月6日、このインプラントはサポートツールだと説明し、影響を受けるルーターの販売を停止し、ファームウェアを削除して、アップデートの開発を始めました。
組み込まれたインプラントがルーターのリモート制御を可能にする。
🔎 ディープダイブ
Coldcardのハッキングはビットコインのセルフカストディへの信頼をどう揺るがしたか
ハッカーは約1億3000万ドル相当のビットコインを盗みました。Coldcardのハードウェアウォレットからのもので、2026年で3番目に大きな暗号資産のハッキングとなりました。
ハードウェアウォレットは、シンプルな約束の上に作られています。鍵をオフラインに保てば、リモートの攻撃者は手が届かない、という約束です。侵害されるアカウントも、シークレットを保持するサーバーもなく、リカバリーフレーズか物理的なデバイスがなければ侵入する手段はありません。
Coldcardの盗難は、その約束を破りました。
ウォレットはオフラインのままでしたが、それでもビットコインは盗まれました。ビットコインのセルフカストディで人々が頼りにしている主要なツールの一つに、弱点があることが露呈したのです。
セルフカストディとは、その管理を取引所やほかの企業に任せるのではなく、自分のビットコインの鍵を自分で保有することです。ハードウェアウォレットはその鍵をオフラインで作成・保存し、オンラインの攻撃者の手が届かない場所に置いておくことになっています。
Coldcardは、セキュリティの評判が高い、定評あるビットコイン専用のハードウェアウォレットでした。ところが、一部の端末がリカバリーフレーズを生成する方法に欠陥があり、その鍵は作成された瞬間から予測可能になっていました。攻撃者はウォレットの物理的な保護を破ることなく、それらの鍵を再構築し、資金にアクセスできたのです。
そこで、本当の問いはこうです。
セルフカストディを守るはずのデバイスが最も弱い環になったら、何が起きるのか。
セルフカストディが取り除くのはカストディアンであり、信頼ではない
人々がセルフカストディを選ぶのは、自分のビットコインについて取引所や金融機関を信頼しなくて済むようにするためです。しかし、秘密鍵を管理するということは、それを安全に守ることも意味します。
ハードウェアウォレット以前は、ペーパーウォレットや常時オフラインのコンピューターが必要になることがよくありました。ハードウェアウォレットは、そうした複雑な仕組みを、鍵を作成してオフラインで保管する専用デバイスに置き換えました。
これによってセルフカストディは実用的になりましたが、信頼がなくなったわけではありません。その信頼は、ビットコインを預かる機関から、ウォレットを製造するメーカーへと移ったのです。
ほとんどのユーザーは、自分の端末がどのように鍵を作成しているかを検証できません。最も重要な部分をメーカーが正しく扱ったと信頼するしかないのです。
Coldcardのハッキングでユーザーはセルフカストディに疑問を抱いた
Coldcardは、数少ない定評あるビットコイン専用ハードウェアウォレットの一つでした。ビットコインの鍵をオフラインかつ取引所の外に置いておきたい人々の間で、信頼される選択肢になっていました。
その評判が、このハッキングの意味をより重くしました。
Coldcardの役割は、単に鍵をオフラインに保つことではありませんでした。ユーザーは、そもそも鍵を安全に作成することをColdcardに託していたのです。その段階が所有者の知らないうちに失敗していれば、その後のすべての保護は脆弱な鍵を中心に構築されていたことになります。
ある被害者はGalaxy Researchに対し、自分のColdcardは銀行の貸金庫に保管されたままで、一度もインターネットに接続したことがなかったと報告しました。それでも攻撃者は7分間で18.25 BTCを盗みました。端末は物理的に保護されたままでしたが、それが作成した鍵は守られていなかったのです。
リスクは、人々が自分を守るために選んだ製品から生じていました。
反応は、RedditのビットコインおよびColdcardのコミュニティに広がりました。あるユーザーはこのエクスプロイトでビットコインを失ったと報告し、別のユーザーはColdcardから離れると述べました。
別の議論では、あるLedgerの所有者があらゆるハードウェアウォレット企業に疑問を呈し、コメント欄ではETF、Fidelity、Binance、Coinbaseへの移行が議論されました。
これらの投稿は、より広範な移行を証明するものではありません。しかし、第三者に戻るという選択肢が、すでに議論の一部になっていたことを示しています。
Coldcardが一部の保有者をセルフカストディから取引所へ押し戻した
欠陥が明らかになった後、脆弱な鍵を心配する保有者は、ビットコインをどこに移すかを決めなければなりませんでした。別のハードウェアウォレットを信頼するか、取引所に鍵を守ってもらうかです。
オンチェーンデータは、その後に起きたことを部分的に示しています。CryptoQuantによると、7月31日には100万近いビットコインアドレスが資金を送受信しました。前日の645,000から増加しています。この急増はビットコインを移そうとする殺到を示していますが、個々の送金の理由や資金の行き先まではわかりません。
取引所への入金は、より明確な手がかりになります。同じ日、人々は取引所から引き出した量よりも多くのビットコインを取引所に入金しました。CoinDeskによると、その差は11,163 BTCでした。大半はBinance、River、Kraken、OKXに送られました。
すべての入金をColdcardに結びつけられるわけではありません。しかしタイミングからは、一部の保有者が別のセルフカストディウォレットではなく取引所を選んだことがうかがえます。
とはいえ、取引所には取引所のリスクがあります。多くのビットコイン保有者がセルフカストディを選ぶのは、取引所が繰り返しハッキングされたり破綻したりしてきたからです。たとえば2025年には、攻撃者がBybit取引所から約15億ドルを盗みました。
取引所に戻った保有者にとって、この移動はColdcardをめぐる差し迫った不確実性を取り除きました。しかし、信頼の必要性がなくなったわけではありません。その信頼は、ウォレットのメーカーから、鍵を守りビットコインへのアクセスを提供する責任を負う取引所へと戻っただけです。
Coldcardは、セルフカストディが終わったことを証明したわけではありません。自分の鍵を持つということは、その鍵を作成するツールを信頼することでもあると示したのです。
ハードウェアウォレットが安全だと認められる条件とは
Coldcardには高い評判がありました。しかし評判は、製品がこれまで何を乗り越えてきたかを反映するものです。そのセキュリティのどの部分が独立してテストされたかを示すものではありません。
オープンソース、エアギャップ（インターネットに直接接続せずに動作するよう設計されていること）、セキュアエレメント（秘密鍵を保護するために作られたチップ）といった用語は、ウォレットを信頼できるものに聞こえさせます。これらは有用な機能ですが、製品全体が安全であることを証明するものではありません。
公開されたコードもレビューが必要です。また、認証を受けたチップだからといって、鍵の作成と保護を担うソフトウェアが自動的に適格になるわけではありません。
正式なセキュリティ認定では、テストされた製品とソフトウェアバージョン、対象とした脅威、評価を実施した組織が明確に特定されます。
たとえば、Ledger Nano S PlusのANSSI認証は、評価されたバージョンと構成にのみ適用されます。そのセキュリティターゲットには、予測可能な乱数生成や悪意あるファームウェアアップデートといった脅威が含まれています。何がテストされたかは示しますが、将来のすべてのバージョンの安全性を保証するものではありません。
Coldcardは、これがなぜ重要なのかを示しています。その弱点はファームウェアを通じて持ち込まれ、リカバリーフレーズの作成方法に影響しました。ハードウェアだけのレビューでは見逃されたはずですし、脆弱なファームウェアがリリースされる前に完了したレビューでは、もはや十分ではなかったでしょう。
したがって、意味のある認定はハードウェア、ファームウェア、鍵生成、アップデートのプロセスをカバーしなければなりません。また、アップデートによって鍵の作成方法や保護方法が変わるときには、繰り返し実施されなければなりません。
セルフカストディは、取引所を信頼する必要をなくします。その信頼を、ユーザーが検証できない主張に置き換えるべきではありません。ハードウェアウォレットのセキュリティには明確なエビデンスが必要であり、そのエビデンスは製品が変わるたびに更新されなければなりません。
🎣 これはフィッシング？
GitHub SSOのアクセスを更新するために、クリックしますか。
🔬 技術研究
ウォレットはオフラインのままだった。それでも攻撃者は鍵を見つけた。
2026年7月に報告されたCOLDCARDの盗難は、コールドストレージの反対側にある障害モードを露呈させました。攻撃者は、デバイスを侵害する必要も、取引を傍受する必要も、ユーザーをだまして支払いを承認させる必要も、バックアップからリカバリーフレーズを盗む必要もありませんでした。公開報道では、この事件は影響を受けたファームウェアにおける脆弱なシード生成と結びつけられています。ウォレットはオフラインでしたが、ありうるシードの空間は探索できるほど小さかったのです。
最初に広く記録された一斉移動では、7月30日に41分間で1,196個のColdcardウォレットから約1,082.65 BTCが移され、当時の価値で約7000万米ドルに相当しました。その後の分析で、報告された総額は約5,000個のウォレットにわたる約1,755 BTCに拡大し、損失は1億1600万米ドル近くに達しました。ただし、研究者が追加の取引をグループ化するにつれて、推定値は変化し続けました。
デバイスは、生成後に鍵を漏えいさせたわけではありません。
鍵は最初から推測可能だったとみられます。
攻撃者はウォレットに侵入する必要がありませんでした。縮小したシード空間を別の場所で探索し、ビットコインを保有するアドレスを見つけ、自分のマシン上で鍵を再現したのです。
乱数性がセキュリティ境界になった場所
ビットコインウォレットは、互いに無関係な秘密鍵の山を保存しているわけではありません。出発点はエントロピー、つまりリカバリーフレーズとしてエンコードされたランダムな入力です。同じリカバリーフレーズと任意のパスフレーズが与えられれば、BIP-39は常に同じシードを生成し、ウォレットはそこからマスターキー、秘密鍵、公開鍵、アドレスを導出します。
この再現性は意図されたものです。だからこそ、同じリカバリーワードで、何年後でも別の互換デバイス上に同じウォレットを再構築できるのです。
これは同時に、厳格なルールも生み出します。同じシードを再構築した人は誰でも、同じウォレットを再構築できるということです。
通常、これは計算上非現実的です。正しく生成された12語のBIP-39フレーズは128ビットのエントロピーを表し、24語のフレーズは256ビットを表します。探索空間があまりに大きいため、すべての可能性を試すことは現実的な攻撃にはなりません。
しかし、単語がランダム性を生み出すわけではありません。単語はそれをエンコードしているだけです。
乱数生成器が、ありうる値のうち限られた、あるいは予測可能な部分集合しか生成できない場合、リカバリーフレーズは見た目は普通でも、その長さが示唆するよりはるかに小さな不確実性しか表していないことがあります。正しく綴られた24語が、自動的に256ビットのセキュリティになるわけではありません。その強さは、単語を選んだプロセスの強さ以上にはならないのです。
COLDCARDの事件が破ったとみられるのは、まさにこの境界です。
決してありえてはならなかったフォールバック
COLDCARDはファームウェアのリポジトリを公開し、再現可能なビルドをサポートしているため、このコードパスを直接調べることができます。
ファームウェア4.0.0で、COLDCARDは新しいウォレットの生成を、独自のckcc.rng_bytesというハードウェア乱数の経路から、新しいlibNgUライブラリのラッパーであるrandom.bytes(32)に変更しました。想定されていたlibNgUの実装は、STM32のハードウェア乱数生成器を使うはずでした。
ビルド構成のミスが、その意図を台無しにしました。LibNgUはハードウェアRNGの設定が存在するかどうかだけをチェックし、MicroPythonはそれが有効かどうかをチェックしていました。設定は存在していましたが0に設定されていたため、libNgUのチェックは通る一方、MicroPythonはrng_get()をソフトウェアのフォールバックとしてコンパイルしました。
このフォールバックのシードは、十分な新しい秘密のエントロピーではなく、デバイス固有の値とタイミングの値から作られていました。その結果、普通に見えるシードが、はるかに小さく列挙可能な可能性の集合から生まれることがありました。正確な影響はデバイスの世代によって異なります。影響を受けるモデルとファームウェアの範囲については、Coinkiteの最新のアドバイザリが信頼できる情報源です。
結果として、呼び出しチェーンは次のようになっていました。
make_new_wallet()
↓
random.bytes(32)
↓
ngu.random.bytes()
↓
my_random_bytes()
↓
CHIP_TRNG_32()
↓
rng_get() 最後の関数名こそ、実装と前提が食い違った場所です。
COLDCARDのボード構成では、プロジェクトが独自のハードウェアRNG実装を含んでいたため、MICROPY_HW_ENABLE_RNGを0と定義していました。LibNgUはSTM32のハードウェアRNGが利用可能であることを確保しようとしましたが、そのコンパイル時のガードはMICROPY_HW_ENABLE_RNGが定義されているかどうかだけをチェックしていました。値が有効かどうかはチェックしていなかったのです。
マクロが存在していたため、libNgUはビルドを受け入れ、CHIP_TRNG_32()をMicroPythonのrng_get()にマッピングしました。マクロの値が0だったため、MicroPythonはrng_get()のもう一方の実装をコンパイルしました。ハードウェアRNGが有効になっていないSTM32ターゲット向けの、YasmarangというソフトウェアPRNGです。
この設定は値0で存在していました。それだけでlibNgUの存在チェックは通りましたが、MicroPythonの値チェックによって、ハードウェアRNGの実装ではなくソフトウェアのフォールバックがコンパイルされました。
このフォールバックは、チップの一意な識別子の最初の32ビットと現在のSysTickカウンターのXOR、さらにリアルタイムクロックの2つのレジスターから内部状態を初期化していました。これらの入力は変化し得ますが、256ビットの新しい秘密のエントロピーに相当するものではありません。LibNgUはその出力を、固定の定数から状態が始まる2つ目のYasmarangストリームとXORしていました。別の決定論的なストリームを混ぜても出力は変わりますが、未知のエントロピーが加わるわけではありません。
この違いは決定的に重要です。
ハードウェアTRNGは、新しく予測不能なエントロピーを提供するための物理的なプロセスを測定します。ソフトウェアPRNGは、内部状態をランダムに見える値へと展開します。暗号論的に安全なPRNGは、十分な秘密のエントロピーで始まり、正しく再シードされれば安全になり得ます。デバイス識別子やタイマーの状態といった値でシードされた小さな決定論的フォールバックは、ウォレットのマスターシークレットを生成する手段の代わりとして容認できるものではありません。
危険だったのは、単にソフトウェアの生成器が存在していたことではありません。本番の経路が、セキュリティ上きわめて重要な処理にそれを黙って使い得たことです。
2つのローカルチェックが、エントロピーの損失を修復しないまま、出力をより安全に見せていました。シード作成では、生成された32バイトに4種類を超える異なる値が含まれていることを確認していました。これは固まった生成器は捕捉できますが、予測可能な出力と暗号論的にランダムな出力を区別することはできません。次に、偏りを緩和するために32バイトをSHA-256でハッシュしていました。ハッシュ化は偏った入力を出力全体に均等に広げることはできますが、元の生成器になかった可能性を生み出すことはできません。攻撃者が入力を列挙できるなら、すべての候補をハッシュ化することもできます。
ウォレットは、それでも有効なリカバリーフレーズを表示しました。チェックサムも機能していました。アドレスは通常どおり導出され、取引も通常どおり署名されました。シードがはるかに小さな探索空間から生まれたことを、ユーザー体験のどこも知らせてはいなかったのです。
この失敗は静かで、持続的で、影響を受けた乱数から作成されたすべてのウォレットにとって取り返しのつかないものでした。
オフラインのブルートフォース攻撃が盗難になるまで
RNGの挙動が理解されれば、物理的なウォレットはもう必要ありません。
攻撃者は脆弱な生成器を再現し、ありうる内部状態を列挙し、それぞれの出力をリカバリーフレーズの候補に変換できます。そしてすべての候補から、対応するビットコインの鍵とアドレスを導出します。
検証レイヤーはブロックチェーンが提供してくれます。
ビットコインのアドレスとその残高は公開されています。攻撃者は被害者に問い合わせる必要も、サービスにログインする必要も、ハードウェアウォレットでアラートを発生させる必要もありません。導出したアドレスをブロックチェーンの履歴と照合し、一致した候補を残すだけです。
候補のシードからビットコインを保有するアドレスが導出されれば、探索は終わりです。攻撃者は、元のウォレット所有者と同じ署名権限を手にしたことになります。自分のシステム上でウォレットを再現し、ビットコインネットワークが完全に有効とみなす取引を作成できます。
ネットワークが拒否するような偽造署名はありません。パスワードの失敗もありません。異常な認証フローもありません。
攻撃者は鍵を持っているのです。
41分という数字が攻撃の全体像を表していない理由
報道の中で最も劇的な数字は、1,000を超えるビットコインが移動された41分間という時間枠です。
それはおそらく実行段階であって、作業の始まりではありません。
候補シードの列挙、アドレスの導出、履歴の確認、資金のある標的の優先順位付けは、最初の盗難取引が現れる前に行われていた可能性があります。この素早い一斉移動からは、攻撃者が脆弱なウォレットと秘密鍵のリストをすでに用意し、最も価値の高い標的から順に、統制のとれた短時間の集中攻撃で処理していったことがうかがえます。
その後の取引は、攻撃の帰属を複雑にしています。公開されている推定値は、当初の594 BTCから1,000 BTC超へ、さらに追加の波やアドレスがこの弱点と関連付けられるにつれて約1,755 BTCへと増えました。取引のタイミングや資金の流れが似ていればクラスタリングの裏付けにはなりますが、すべての盗難が一つの実行者によるものだと自動的に証明するわけではありません。
そのため、最も安全な表現は、最終的な被害者数や単一の攻撃者による確定総額ではなく、変化し続けるオンチェーンの推定値です。
デバイスのアップデートだけでは不十分な理由
ファームウェアのアップデートは、今後のウォレット作成に使われる乱数を修正できます。
すでに存在するシードにエントロピーを加えることはできません。
影響を受けたリカバリーフレーズから導出されたすべての秘密鍵とアドレスは、元のシードに結びついたままです。デバイスを初期化して同じ単語で復元しても、何も変わりません。その単語を別のハードウェアウォレットにインポートしても、何も変わりません。新しいデバイスは、攻撃者がすでに計算できるかもしれない同じ鍵を再現するだけです。
意味のある修復は移行です。
公式ベンダーの配布元から検証済みのファームウェアをインストールする。
信頼できる、影響を受けていないプロセスで、まったく新しいシードを生成する。
リカバリー手順と受信アドレスをオフラインで検証する。
古いシードから導出されたアドレスのすべての資金を新しいウォレットに移す。
BIP-85の子ウォレットを含め、古いルートから導出されたすべての子ウォレットを露出している可能性があるものとして扱う。
リカバリーフレーズを、Webサイト、サポートフォーム、「チェッカー」、頼んでもいないリカバリーツールに決して入力しない。
影響を受けるデバイスとファームウェアの範囲を確定的に知るには、Coinkiteの最新のアドバイザリに従ってください。公開報道では「ウォレット」「アドレス」「デバイス」「ユーザー」が常に一貫して使われているわけではなく、これらの用語は互換的ではありません。
ハードウェアウォレットのチームが学ぶべきこと
これは、ビットコインの署名アルゴリズム、BIP-39の単語リスト、ブロックチェーンのコンセンサスの失敗ではありませんでした。長期的なシークレットが作成される瞬間における実装の失敗でした。
そのため、エンジニアリング上の教訓はきわめて直接的です。
暗号用のRNGはフェイルクローズでなければなりません。想定したエントロピー源が利用できない場合、シード作成は目に見えるエラーで停止すべきです。
本番コードには、鍵生成のための非暗号的なフォールバックを黙って含めるべきではありません。
テストでは、ソースレベルやシミュレーターでの挙動だけでなく、ユーザーに出荷されるのとまったく同じ署名済みファームウェアイメージとハードウェアの経路を実行しなければなりません。
ビルド時の構成で、必要なRNG実装が有効であることをアサートすべきです。
独立したエントロピー源を組み合わせれば、一つのコンポーネントの故障がシードを完全に決定することはなくなります。
シード生成には、統計的な乱数性テストに加えて、既知解テスト、フォールトインジェクションテスト、異常系テストが必要です。
再現可能なビルドは透明性を高めますが、再現性が証明するのはバイナリがソースと一致することだけです。ソースが安全であることは証明しません。
マルチシグによるカストディは、鍵が独立して、理想的には異なる実装とベンダーにまたがって生成されるときに最も強くなります。すべての署名者で同じ脆弱な生成器を繰り返し使えば、同じ障害ドメインが残ります。
より広い教訓が居心地の悪いものなのは、ハードウェアウォレットがセットアップ後はすべてを正しく行っているように見えるからです。シードをオフラインに保ちます。PINを保護します。ファームウェアを検証します。信頼できる画面にアドレスを表示します。専用ハードウェアの内部で署名します。
こうした制御はすべて、シード生成の下流にあります。
最初のシークレットが予測可能なら、残りのアーキテクチャは、攻撃者が独自に再現できる鍵を守っているだけかもしれません。
エアギャップは、シークレットがデバイスから出ていくのを防ぎます。
もともと十分に秘密ではなかったシークレットを守ることはできません。
バージョンと範囲に関する注記：このセクションは、2026年8月10日時点で入手可能な公開報道に基づいています。損失総額、取引のクラスター、影響を受けるデバイスの正確な範囲は、まだ変化し続けていました。1億1600万米ドルという数字は推定値であり、監査を経た最終的な損失総額ではありません。
出典：TRM Labs、CoinDesk、Coinkiteのセキュリティアドバイザリ、COLDCARDのファームウェアリポジトリ、ファームウェア4.0.0のシード生成コード、COLDCARDボードのRNG構成、固定版のlibNgU RNG実装、固定版のMicroPython STM32 RNG実装、COLDCARDのファームウェア履歴、BIP-39仕様
🛠️ 今週のツール
LLVM
ほとんどの人は、コンパイラーの仕事は一つだと考えています。ソースコードを動作するアプリケーションに変えることです。
LLVMは、コンパイルがセキュリティテストの一部にもなり得ることを示しています。Clangを支えるこのオープンソースの基盤は、ソフトウェアのビルド中にチェックを挿入でき、セキュリティチームがメモリエラーを発見したり、通常のテストでは到達しないようなコードへファザーを導いたりするのに役立ちます。
LLVMがセキュリティテストを支える仕組み
ClangはCとC++のソースコードを、最終的なアプリケーションを生成する前にLLVMが解析・変更できる内部形式に変換します。
この過程で、AddressSanitizerのようなツールが、メモリの問題を検出するチェックを追加できます。許可された領域外のデータへのアクセスや、解放後のメモリの再利用といった問題です。
LLVMにはlibFuzzerも含まれています。変更を加えた入力をプログラムに繰り返し送り、それらがコードのどの部分に到達するかを追跡します。新しい挙動を発見した入力は保持されてさらに変更され、ファザーはアプリケーションの奥へと段階的に探索を進めていきます。
簡単な例
ある企業が、画像ファイルを処理するC++ライブラリを保守しているとします。
セキュリティエンジニアは、ClangでライブラリをコンパイルしてAddressSanitizerを有効にします。次に、画像を開く関数にlibFuzzerを接続し、開始時の入力としていくつかの有効なファイルを与えます。
LibFuzzerは、パーサーのどの部分に到達したかを監視しながら、それらのファイルを継続的に変更します。やがて、ある不正な形式の画像がめったに使われないコードパスを実行し、メモリエラーを引き起こします。
AddressSanitizerはエラーが発生した場所を報告し、チームに再現可能な入力と、調査を始めるための明確な起点を与えます。
置き換えないもの
LLVMは基盤となるプロジェクトであり、アプリケーションに向けるだけで使えるセキュリティスキャナーではありません。
そのセキュリティ機能を使うには、通常、ソースコードとビルドプロセスへのアクセスに加えて、適切なファジング対象が必要です。認可の不備、安全でないビジネスロジック、テストが到達しない脆弱性を自動的に特定することはありません。
こうした追加のチェックはアプリケーションの動作を遅くすることもあるため、計装されたビルドは一般にテスト用に使われ、ユーザー向けにはリリースされません。
👏 今週の人物
Andrea Fioraldi
今週は、Andrea Fioraldiを紹介します。ファジングと脆弱性の自動発見を専門とするセキュリティ研究者です。
AndreaはAFL++のメンテナーの一人です。AFL++はコミュニティ主導のオープンソースのファザーで、長年のセキュリティ研究を通じて開発された手法を一つの実用的なツールにまとめています。
彼の仕事には、カスタマイズしたファザーを構築するためのフレームワークであるLibAFLや、ソースコードが入手できないコンパイル済みソフトウェアのメモリエラー検出を支援するQASanもあります。最新のファジング手法に関する彼の博士論文は、GDR Sécurité Informatiqueの2024年論文賞を受賞しました。
ファジング研究を、ソフトウェアの脆弱性を発見するための実用的なオープンソースツールへと結びつけてきたことから、Andrea Fioraldiを今週の人物に選びました。
📅 今週のイベント
Ekoparty Security Conference 2026
ラテンアメリカ最大のハッカーカンファレンスであるEkopartyの第22回に向けて、数千人のセキュリティ研究者、専門家、愛好家がブエノスアイレスに集まる見込みです。
3日間にわたり、技術講演やワークショップに加えて、CTF、コミュニティビレッジ、ライブハッキング、実践的なチャレンジが行われます。
プログラムは、モバイルハッキング、リバースエンジニアリング、ファジング、エクスプロイト、ファームウェア、クラウドセキュリティ、ハードウェアハッキングをカバーしています。
AppSecチームや攻撃的セキュリティのチームにとって、Ekopartyは新しいセキュリティ研究、実践的なデモ、ハンズオンのアクティビティを一つのイベントにまとめた場です。
📍 Centro de Convenciones de Buenos Aires, Argentina
📅 2026年10月7日～9日
📚 今週の本
Black Hat GraphQL
著者：Nick Aleks、Dolev Farhi
クライアントが欲しいデータを正確に指定できるAPIを、どうテストすればよいのでしょうか。
Black Hat GraphQLは、GraphQL APIの仕組みと、セキュリティ専門家がそのアタックサーフェスを調べる方法を解説しています。偵察、情報漏えい、認証・認可のバイパス、インジェクション、サービス拒否攻撃、リクエストフォージェリを取り上げています。
ハンズオンのラボと意図的に脆弱にしたGraphQLアプリケーションを通じて、読者は弱点の特定、セキュリティ制御の検証、開発パイプラインへの自動テストの組み込み方を学びます。
GraphQL APIがどのように攻撃され、守られているのかを実践的に理解したいペンテスター、AppSecエンジニア、セキュリティアナリスト、開発者にとって、有益な一冊です。
😅 今週のミーム
ハードウェアウォレットも取引所も信頼を必要とするなら、ビットコインの保有者は、どこに保管するかを決める前にどんなエビデンスを求めるべきでしょうか。
The Breach Brief、Ostorlabチーム