信頼の八ビット；eMudhraのCAキーがミリ秒で破られる

概要

eMudhraの中間認証局8つの秘密鍵が 極めて単純な数値 （例：4や56）で生成されていたことが判明。 これにより秘密鍵が 即座に復元可能 となり、証明書の安全性が根本から崩壊。 主要ブラウザでは 即時ブロック されたが、多数の非ブラウザクライアントは依然として危険な状態。 多くのIoT機器や自動アップデータ等が 長期間脆弱 なまま運用される恐れ。 根本原因は スクリプトバグと人的ミス による弱い鍵ペアの選択。

eMudhra中間認証局の秘密鍵流出事件

• eMudhraの中間認証局8つの秘密鍵が 極端に単純な数値 （例：4, 56, 115）で設定
• これらの鍵は 公開証明書から即座に復元可能 な状態に
• セキュリティ研究者がApple, Google, Microsoft, Mozilla, eMudhraに 2025年10月17日報告
• ChromeとFirefoxは 即日ブロック措置、Mozillaはルート証明書も削除
• 問題の8つは TLS発行CA6種・コード署名CA2種 （全て2025年4月作成）
  • さらにSectigoのルートでクロスサインされていた

問題の本質

• これらは 楕円曲線P-384 の秘密鍵
• 通常は 2³⁸⁴通り の巨大な乱数が必要
• eMudhraの秘密鍵は 1バイト（最大256通り） しか変動せず
• 1×G, 2×G, ...と計算するだけで 全パターン総当たりが一瞬で完了
• 公開鍵自体は一見問題なく、 形式・構造上の異常は見えない
• 事実上、 証明書発行時から秘密鍵が公開状態

被害の広がりと「封じ込め不可能」な理由

• 通常の秘密鍵流出は「盗難」だが、今回は そもそも秘密鍵が秘密でなかった
• 2025年4月以降、 誰でも即座に秘密鍵取得可能 な状態が17ヶ月続いた
• ChromeやFirefoxなど 主要ブラウザはCT（証明書透明性）で守られる
• しかし curl, Python, Node, Go, Java, git等の非ブラウザクライアント は
  • デフォルトで失効確認やCTチェックをしない
  • CAバンドルを更新しない限り脆弱性が残る
• IoTや組み込み機器は 2039年まで証明書を信頼し続ける恐れ

具体的なリスク例

• curl | sh型インストーラや自動アップデータ ：偽証明書で任意コード実行
• CI/CDパイプライン ：依存関係取得や成果物配布時の乗っ取り
• サーバ間API通信 ：APIキーや顧客データの漏洩
• IoT・組み込み機器 ：長期にわたり脆弱な通信
• Windowsコード署名 ：悪意あるソフトも正規署名扱い

実証テスト

• api.stripe.comの証明書を偽造し、curl/Python/Nodeで 検証OK
• Windowsも失効確認をしない限り チェーンを受け入れる

今後の対策

• OSや主要ミドルウェアのCAバンドルを必ず更新
• certifi, Node, Homebrew等も アップデート必須
• 更新不可能な機器は2039年までリスクが残る
• 根本原因は HSMスクリプトのバグと人的ミス で誤った弱い鍵ペアが選択されたこと

参考・ソース

• MDSPスレッド
• 研究発表
• Mozillaインシデントチケット
• eMudhraによる説明： スクリプトバグ＋人的ミス で弱い鍵が選択されていたことを認める
• AIエージェントでも 即座に秘密鍵が復元可能 なことを確認