384ビットの楕円曲線で、実際の鍵はわずか「4」だった
2026年10月17日土曜日、セキュリティ研究者がApple、Google、Microsoft、Mozilla、そしてインドの認証局（CA）であるeMudhraに対し、衝撃的な調査結果を報告しました。eMudhraが管理する8枚の中間CA証明書の秘密鍵が、ノートPCを使って1秒未満で割り出せる状態にあったのです。
これらの証明書にはNISTのP-384楕円曲線暗号が採用されていました。設計上、秘密鍵は384ビットの乱数でなければならず、取りうる値の候補は約10の115乗通りに及びます。しかし実際の秘密鍵はどうだったでしょうか。47バイト分のゼロに、わずか1バイトの数値が続くだけでした。8本の鍵の値は、それぞれ4、56、115、155、156、230、66、237。そのうち1本は、文字通り「4」だったのです。
このような鍵を特定するために必要な楕円曲線上の点加算演算は最大でも255回に過ぎず、ごく一般的なノートPCでも1秒とかかりません。研究者はMozillaの公開情報に添付された16枚の証明書から、8本の秘密鍵すべてを完全に復元しました。これらの秘密鍵は、証明書が発行された2025年4月の時点から、実質的に公開されていたも同然だったのです。
画像：破壊された南京錠。出典：Ars Technica
形式検査はすべて合格していた：問題はどこにあったのか
HTTPSの信頼の連鎖（Chain of Trust）はルート認証局から下位へと順次発行され、各段階で厳格なフォーマット検査が行われます。楕円曲線の妥当性、ASN.1エンコードの正確性、署名構造の正当性などです。eMudhraの8枚の証明書（TLS発行用の中間CA 6枚、コード署名用CA 2枚）はすべて2025年4月に作成され、同年5月にはSectigoのルート認証局である AAA Certificate Services からクロス署名を受けており、あらゆる技術仕様の検証をクリアしていました。
しかし、形式チェックの項目には「秘密鍵が真にランダムな値であるか」を確かめるものは存在しません。秘密鍵の生成は認証局自身の内部で行われ、外部からは公開鍵しか見えないためです。P-384が誇る10^115通りの数学的強度は、秘密鍵がその巨大な空間から真に無作為に抽出されて初めて成立します。 eMudhraの過ちは、外部の誰も検証してくれないまさにその工程で起きていました。
コミュニティの議論では、いくつかの原因が推測されています。鍵生成スクリプトの引数の渡し順を誤ったのか、あるいはコード内の key[0] でラップ用鍵の先頭1バイトだけを誤って代入してしまったのか。一方で、「暗号鍵は本来ハードウェア・セキュリティ・モジュール（HSM）の内部で生成されるべきものであり、外部で生成できてここまで杜撰なミスが混入すること自体、運用プロセスが根本から崩壊していた証拠だ」と指摘する声も上がっています。
ブラウザ各社による即時ブロック：4日間に何が起きたか
10月17日の夜、Googleは8枚の証明書をブロックするCRLSetのアップデートを緊急配信し、数時間後にはMozillaもOneCRLで追従しました。10月20日、Mozillaはこのインシデントを公式に公表するとともに、NSSの更新によってeMudhraのルート証明書を直接削除。GoogleもChrome Root Store v43において同ルートの信頼取り消しを確認しました。
なぜこれほど迅速な対応が取られたのでしょうか。研究者のIan Carroll氏はこのように述べています。「本質的に、誰でも因数分解できる1バイトの鍵であり、被害を局所的に封じ込めることは不可能です」。不正アクセスの日時を特定できるような侵入事件ではないため、過去17か月の間、いつでも誰でも偽造証明書を発行できる状態だったからです。
Google Chromeの開発陣はさらに重要な補足を行いました。これらの中間CAは証明書透明性（CT: Certificate Transparency）ログにTLS証明書を登録した履歴がなかったため、Chromeでは偽造証明書がデフォルトで信頼されることは防がれていました。しかし、CTは不適切な発行を検知できても署名そのものを阻止できるわけではなく、ブラウザ以外の膨大なソフトウェアはCTの検証をまったく行っていません。
画像：信頼の連鎖は上位の検証に依存しているが、基盤となる秘密鍵のエントロピーを検証する仕組みは存在しない。出典：Keytos
最大のリスクに晒された curl | sh インストールスクリプト
一般的なウェブブラウザの利用者は、緊急の失効リスト配信とCTの義務化という二重の防御壁によって概ね守られました。しかし、真の攻撃対象領域はブラウザの外側に広がっています。
curl、Python、Node.js、Go、Java、git、各種パッケージマネージャーといった非ブラウザのTLSクライアントは、通常ディスク上の静的なCAバンドルを参照し、失効確認（OCSP/CRL）を行わず、CTログの照合もしません。こうしたクライアントにとって失効アナウンスは機能せず、eMudhraのCAバンドルを読み込んだ場合、8ビットの秘密鍵を持つ中間CAは依然として正当な署名者として受け入れられてしまいます。
最も深刻な被害が懸念されるのは2つの領域です。1つ目は、パイプ処理で実行される curl | sh 形式のインストールスクリプトやソフトウェアの自動更新機能です。偽造証明書によって中間者攻撃が成立すれば、攻撃者のコードが一般ユーザー権限やroot権限でそのまま実行されてしまいます。2つ目はCI/CDパイプラインです。ビルドコンテナ内にはクラウドの認証情報、コンテナレジストリのトークン、署名鍵などの機密情報が集約されています。攻撃者に必要な機材は、ノートPC1台と1秒にも満たない計算時間だけでした。
eMudhraの釈明と事業撤退
10月22日、eMudhraは世界のSSL/TLS証明書事業から完全に撤退することを発表しました。同社の発表では主に3つの理由が挙げられています。SSL/TLS事業が売上全体の約1%に過ぎなかったこと、データ主権やコンプライアンス維持のコストが年々増大し大手による無料発行が主流化する中で採算が合わなくなったこと、そして「今回の事案を巡るソーシャルメディア上での過熱した批判と監視の目は、当社の事業規模に照らして著しく不釣り合いである」という主張です。同時に、問題の中間CAを14時間以内に失効させ、末端のエンドエンティティ証明書を一切発行しておらず、インフラへの不正侵入もなかったことを強調しました。
技術コミュニティはこの「不釣り合い」という釈明を一蹴しました。焦点となったのは、「なぜ17か月もの間、秘密鍵にエントロピーが存在しないという単純な事実に社内の誰も気づかなかったのか」という一点です。秘密鍵がHSMの内部で生成されていればこのような事態は防げたはずであり、外部生成を許していた運用実態こそが過失の本質であると厳しく批判されています。
最後の砦は人間であり、自動検証の安全網は存在しない
今回の事件において、暗号アルゴリズムそのものに何ら欠陥はありませんでした。曲線は仕様通りで、エンコードも正しく、データ構造も規格を満たし、Sectigoなどの大手認証局によるクロス署名も得ていました。8枚の証明書は17か月間にわたりあらゆる自動チェックを通過し続けました。問題が生じたのは、機械のチェックも定期的な監査も標準では行わない、極めて基本的な確認事項を人間が怠った点に尽きます。「384ビットであるはずの秘密鍵が、実際には8ビットの整数になっていないか」という確認です。
HTTPSの信頼チェーンはブラウザを終端としてインターネット全体を支えていますが、中間認証局の秘密鍵の品質を外部から確認するには、公開鍵から逆算するしかありません。eMudhraのケースではその逆算に17か月を要し、外部のセキュリティ研究者の手によって初めて暴かれました。PKIの安全保障の境界線は、最後には組織の運用規律にかかっています。そしてその規律には、curl コマンド1行で実行できるような都合の良い自動テストは存在しないのです。eMudhraはSSL/TLS事業を撤退することで幕引きを図りましたが、「監視者を誰が監視するのか」という問いに対し、次回も売上の1%を切り捨てて済ませられるような選択肢が用意されているとは限りません。
参考リンク：
- Mozilla Bugzilla 開示情報およびNSSリリースノート
- Chrome Root Store v43 関連告知
- eMudhra グローバルSSL/TLS事業撤退声明
- Ian Carroll による解説
- Hacker News ディスカッション (item?id=50177916)
