2026/10/21 18:08
トラストの8ビット：eMudhra の CA キーが数ミリ秒で解読される
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
セキュリティ研究者のスcott Helme は 10 月 17 日に、eMudhra の中間証明書 8 つが脆弱性により秘密鍵が侵害されたことを報告した。この脆弱性は、安全な P-384 鍵に必要な乱数ではなく弱い単一バイトの値が使用されていたことに起因する。これらの中間証明証は Sectigo の AAA Certificate Services ルートから 2025 年 5 月にクロス署名されており、発行開始日は 2025 年 4 月である（TLS 発行 CA が 6 つ（DV、OV、EV）、コード署名 CA が 2 つ）。鍵は発行時点ですでに実質的に公開されていた。その理由は、8 ビットの長さがブルートフォース攻撃での即時復号化を可能にするためであり、最大 255 ステップで解読できうるのに対し、安全な鍵は約 10^115 の可能性を持つべきであるからである。観測された値には 4, 56, 115 がある。この脆弱性の原因は、HSM で第 2 の弱い鍵を生成したセレモニースクリプトのバグおよび CSR 用の誤った鍵を選択するという人的ミスによるものである。
Apple、Google、Microsoft、Mozilla を含む主要ベンダーは当局に通知し、Chrome は発行後間もなく（10 月下旬）CRLSet でこれらの証明書をブロックし、その後に Mozilla の NSS アップデートで eMudhra ルートを削除、Chrome Root Store v43 に追加を確認した。現代のブラウザは Certificate Transparency (CT) エンフォースメントおよび引き上げ確認によって保護されており、CT ログに偽造チェーンは見つかっていない。しかし、非ブラウザシステムは依然として極めて脆弱である。curl、Python、Node、Go、Java、Windows CryptoAPI、デフォルトの CA バンドルなどのツールは、引き上げチェックや CT ログを確認せずにこれらの証明書を受入れる。重要なリスク暴露には CI/CD パイプライン、サーバー間 API コール、コード署名ルート（脆弱性は 2039 年 7 月まで続く）、更新できないファームウェアを搭載した IoT/OT デバイスが含まれる。推奨される対応策は OS の CA バンドル（ca-certificates）、certifi、Node、Homebrew を更新し、コンテナイメージを再ビルドすることである。ただし、アップデートできないデバイスは証明書の有効期限が 2039 年 7 月になるまで引き続きリスクに晒されたままとなる。
本文
eMudhra CA 鍵漏洩：「4」という数字で全ての鍵が解けた現実
eMudhra の証明書認証機関（CA）の私用鍵のうち、一部は単に 「4」 という数字そのものです。先頭が 4 でもなく、それ以降にランダムな数字がついているわけでもなく、まさに
です。その他にも「56」「115」などの極めて小さな値が使用されていました。4
セキュリティ研究者がこの事案を Apple、Google、Microsoft、Mozilla および eMudhra に報告したのは 2024 年 10 月 17 日（土） です。報告後すぐに Chrome と Mozilla は対応を始めたものの、この脆弱性は既に 17 ヶ月間にわたり存在しており、汎用ハードウェア上でミリ秒単位で鍵が復元可能だったことが明らかとなりました。
脆弱性の概要と仕組み
漏洩したのは TLS 発行用 CA 6 つ（DV/OV/EV のそれぞれ 2 世代）および コード署名用 CA 2 つ、合計 8 つです。これらはすべて P-384 曲線を使用しており、理論上は非常に高いセキュリティが保証されていますが、以下の理由で完全に崩壊しています。
私用鍵（Private Key）の実態
-
正常な私用鍵:
- 384 ビットのランダムな数値。
- 可能性の総数は (2^{384})（約 (10^{115})）。総当たり攻撃は不可能です。
- 例：
0x...426d78644298fc53df...
-
脆弱な私用鍵 (
):d- すべて 8 ビット以下の数値 です。
- 例：
,d = 4
,d = 56
など。d = 115 - 総当たり攻撃仅需 255 ステップ（最大）ですべての鍵を復元可能です。
脆弱性の詳細リスト
| 中間 CA | 種類 | 私用鍵 d（16 進数 / 値） |
|---|---|---|
| EM DV TLS CA - G3B | TLS | |
| EM DV TLS CA - G3C | TLS | |
| EM EV TLS CA - G3B | TLS | |
| EM EV TLS CA - G3C | TLS | |
| EM OV TLS CA - G3B | TLS | |
| EM OV TLS CA - G3C | TLS | |
| EM OV CS CA - G3B | コード署名 | |
| EM OV CS CA - G3C | コード署名 | |
※注：表内の「156」「155」などは、元のテキストの
d = 156これらの鍵で作成された証明書自体には不自然さはなく、符号化も正常ですが、**「封じ込められない」**という特徴があります。
なぜ「封じ込められない」のか？
通常、CA 鍵が漏洩するのは誰かが盗んだ場合です。しかし今回は以下の点が問題です。
- 盗まれる必要がない: 鍵は既に公開状態でした（証明書が存在した日付から）。
- 長期間の暴露: 2025 年 4 月以降、どの証明書を眺めた人がいても、汎用ハードウェアで即座に復元できました。
- 検知と防御の不整合:
- Chrome は Certificate Transparency (CT) を利用して偽造を検知します。
- しかし、多くのソフトウェアや OS は CT をチェックせず、古い CA バンドルを信頼し続けます。
暴露されているシステムとリスク
最新のブラウザ（Chrome, Firefox, Safari）は CT 検証により安全ですが、それ以外の環境では深刻な脆弱性があります。
問題のあるシステム
- 非ブラウザの TLS クライアント: curl, Python, Node.js, Go, Java, git パッケージマネージャなど。
- 特徴:
- ディスク上の古い CA バンドルを信頼する。
- カスタムリビオケーション（撤回）チェックを行わない。
- Certificate Transparency (CT) をチェックしない。
具体的な被害シナリオ
-
自動更新ツールへの攻撃
,rustup
, Homebrew インストーラーなど、HTTPS で署名チェックなしにコードをダウンロードするスクリプト。nvm- リスク: 偽造証明書で攻撃者のコードが root 権限で実行される。
-
CI/CD パイプライン
- GitHub/GitLab ランナーや Jenkins が、古いベースイメージ上で
やcurl
を使用して依存関係を取得・プッシュする。Python - リスク: クラウドキーやレジストリトークンが漏洩する。
- GitHub/GitLab ランナーや Jenkins が、古いベースイメージ上で
-
サーバー間通信（API）
- 決済プロバイダー、ウェブフック、OAuth トークン交換。
- リスク:
などの高価値 API に接続しても、偽造証明書で正当な通信として扱われ、機密情報が漏洩する。api.stripe.com
-
IoT および埋め込み機器
- ルーター、カーシステム、医療機器、産業制御装置など。
- リスク: ファームウェアが 2039 年まで固定されているため、撤回処理ができない。
-
Windows コード署名
- Windows は eMudhra のルート証明書を直接信頼しており、リビオケーションチェックが入っていなければ偽物の署名を信頼する。
実証実験の結果
テスト環境（Linux, macOS, Windows）で
api.stripe.com# curl で api.stripe.com に接続（偽造証明書を使用） scott@Middle-Earth:~$ curl -v --resolve api.stripe.com:18888:127.0.0.1 https://api.stripe.com:18888/ * Added api.stripe.com:18888:127.0.0.1 to DNS cache * Hostname api.stripe.com was found in DNS cache * Trying 127.0.0.1:18888... * サーバー証明書： * 主題：CN=api.stripe.com * 発行者：C=NL; O=eMudhra BV; CN=EM DV TLS CA - G3B * SSL certificate verify ok. <--- ここが問題 > GET / HTTP/1.1 < HTTP/1.0 200 ok
結論: ネットワーク経路上にいれば、8 ビットの鍵を解いた偽造証明書を介してトラフィックを傍受・改ざんできます。
今すぐすべきこと：対応策と課題
対応可能な機器については「アップデート」が解決策です。しかし、更新不可能な機器は大きなリスクです。
推奨される対応
- OS とライブラリの更新:
パッケージ（Linux）、certifi (Python)、Node.js のデフォルトバンドルなどを最新へアップデートする。ca-certificates - コンテナ環境の再構築: ベースイメージが変更を反映していない場合、コンテナイメージを再ビルドする必要がある。
対応不能なリスク（氷山の一角）
- IoT 機器とネットワーク家電: ルーター、プリンター、テレビ、車載システムなど。
- ファームウェア更新ができない機器は、2039 年までこの脆弱な CA を信頼し続ける。
- これらは現在、非ブラウザソフトウェアにおける唯一のセキュリティ障壁だったため、完全に無防備です。
今後の展望
eMudhra と Sectigo は該当する中間 CA の撤回を発表していますが、CT をチェックしないクライアントにはこの発表は意味がありません。CA バンドルを配布するすべてのシステムが即時更新されることは期待できません。
情報源と追補
- Mozilla スレッド: Google Groups
- 公式発表ページ: eMudhra We Have a Problem
- Mozilla バグレポート (2026 年更新): Bugzilla #2083449
インシデントの原因と拡大
調査により、儀式中に使用したスクリプトにバグがあり、HSM で 2 つ目の弱すぎる鍵ペアが作成され、類似の名前ゆえに人的エラーにより CSR に誤った鍵が使われたことが判明しました。
さらに興味深いことに、AI エージェントへの単純なプロンプトだけで、これらの CA 私用鍵をすべて復元することに成功しました（例：Claude など）。