eMudhraのCA秘密鍵がわずか1バイトの脆弱な値だったことが判明
2026年10月17日、セキュリティ研究者により、インドの認証局eMudhraが発行する8つの中間CA証明書の秘密鍵に重大な脆弱性があることが、Apple、Google、Microsoft、Mozilla、そしてeMudhra自身に報告されました。この問題は、暗号学的安全性において極めて衝撃的な内容です。
主記事の筆者であるスコット・ヘルム氏は、自身のラップトップでわずか1秒足らずで、公開されている証明書からすべての秘密鍵を復元できたと報告しています。（Hacker News (API)）
eMudhraのCA秘密鍵の一つが、なんと「4」という数字だったと報告されています。
具体的には、8つの中間証明書（6つのTLS発行CAと2つのコード署名CA）の秘密鍵が、本来384ビットのランダムな数字であるべきところ、わずか1バイト（256通りの値）の極めて小さな値で設定されていました。例えば、TLS証明書の一つには秘密鍵「4」、別のものには「56」や「115」が使われていたとされています。
このため、総当たり攻撃で数ミリ秒以内に秘密鍵が特定されてしまう状態だったのです。これは暗号学的セキュリティモデルの根幹を揺るがす事態だと感じます。
なぜこれほど脆弱な鍵が生成されてしまったのか
これらの証明書はすべて2025年4月に作成され、同年5月にはSectigoのAAA Certificate Servicesルートによってクロス署名されていました。問題の「何が起きたか」については上述の通りですが、「どうして起きたか」が最も興味深い点です。
主記事では、イアン・キャロル氏の言葉を引用して、「それらは本質的に弱い1バイトの鍵であり、誰でも因数分解でき、問題を封じ込めることはできない」と説明しています。（Hacker News (API)）
楕円曲線暗号（P-384曲線）では、秘密鍵dは巨大なランダムな数字であるべきです。公開鍵はd × G（Gは固定点）で算出され、公開鍵からdを逆算することは非常に困難である、というのがセキュリティモデルの前提です。
しかし、eMudhraの鍵は、例えばd = 0x00...004のように、47バイトのゼロと1バイトの数字で構成されていました。これにより、わずか255ステップ以下の総当たりで秘密鍵が割り出されてしまったのです。
以下に、クラックされたeMudhraの中間証明書の鍵を示します。（Hacker News (API)）
| Intermediate | Type | d |
|---|---|---|
| EM DV TLS CA - G3B | TLS | 156 |
| EM DV TLS CA - G3C | TLS | 230 |
| EM EV TLS CA - G3B | TLS | 115 |
| EM EV TLS CA - G3C | TLS | 56 |
| EM OV TLS CA - G3B | TLS | 155 |
| EM OV TLS CA - G3C | TLS | 4 |
| EM OV CS CA - G3B | Code signing | 66 |
| EM OV CS CA - G3C | Code signing | 237 |
影響とブラウザベンダーの迅速な対応
この脆弱性の恐ろしい点は、「鍵が盗まれたわけではない」という点にあります。鍵は、証明書が発行された2025年4月の時点から、実質的に誰でもアクセス可能な状態だったと言えるでしょう。
この17ヶ月間、誰でもこれらの証明書を悪用して偽の証明書を作成し、ウェブサイトのなりすましやマルウェアの署名などに利用できた可能性があります。（The Register）
主要ブラウザベンダーは迅速に対応しました。Chromeは同日夜にCRLSet（Certificate Revocation List Set）アップデートをプッシュして該当鍵をブロックし、Mozillaも数時間後にFirefoxでOneCRL経由でブロックしました。2026年10月20日には、Mozillaが公式に発表し、eMudhraのルート証明書をNSS（Network Security Services）から削除するアップデートをリリース。
Chromeも同様にChrome Root Store v43から当該ルート証明書を削除することを確定しました。（Hacker News (API)）
しかし、この問題は「封じ込めることができない」性質を持っています。なぜなら、鍵が盗まれたのではなく、最初から公開鍵情報から簡単に推測可能だったため、どこで誰がこの鍵を悪用したかを追跡することが極めて困難だからです。
未パッチのシステムは、引き続き偽造された証明書に対して脆弱な状態が続く可能性を考慮すべきだと感じます。（InfoQ）
エンジニア目線での考察：生成プロセスとセキュリティ監査の重要性
今回のeMudhraの件は、暗号鍵生成における「エントロピー」の重要性を改めて浮き彫りにしました。P-384のような強力な曲線を使用しても、秘密鍵の初期値がランダムでなければ意味がないという、暗号の基本中の基本が疎かになっていたことは、正直、ここまで来たかという感じです。普段 Claude Code などでコードを生成する際も、乱数生成やパスワード生成ロジックには特に注意を払うべきだと感じます。
これは、単なる実装ミスというより、鍵生成プロセス全体、そしてその後のセキュリティ監査体制に根本的な問題があった可能性を示唆しています。もし、鍵生成時に自動テストで鍵の強度をチェックする仕組みがあれば、このような極端に弱い鍵はリリースされなかったのではないでしょうか。また、CAとして発行する証明書の鍵に対して、第三者機関による定期的な監査や、少なくとも内部での厳格なレビュープロセスが欠如していたのではないかと考えます。
クラウドサービスにおいても、例えばGCPのKMS（Key Management Service）など、マネージドな鍵管理サービスを利用する際には、提供される鍵のエントロピーやセキュリティ保証が非常に重要になります。自前で鍵を生成・管理する際は、常にこのようなリスクを意識し、十分な乱数源の確保と、鍵強度の検証を徹底することが不可欠です。今回の事例は、セキュリティの足元が揺らぐと、どれほど大きな影響が出るかを示す教訓となるのではないでしょうか。
