認証局がXKCDのオチを現実のものにしてしまった
10月17日、セキュリティ研究者の「Wayne」氏による衝撃的な開示により、公開鍵基盤（PKI）における深刻な欠陥が明らかになりました。TLSおよびコード署名認証局を含む8つのeMudhra中間証明書が侵害されていたのです。主要なブラウザやオペレーティングシステムによって17ヶ月間も信頼されていたこれらの証明書の秘密鍵は、極めて小さな整数であり、そのうちの1つは文字通り「4」でした。
これらの鍵はP-384楕円曲線に依存していましたが、本来であれば秘密スカラー（d）には約10の115乗もの組み合わせを持つ、予測不可能な大きな384ビットの数値が必要です。しかし、侵害されたeMudhraの鍵は先頭から47バイトがゼロであり、最後のバイトの値も最大255通りの候補を総当たりすれば特定できるほど小さなものでした。
この壊滅的な脆弱性により、秘密鍵は即座に復元可能でした。特定された値は以下の通りです：
- 4
- 56
- 66
- 115
- 155
- 156
- 230
- 237
これらの整数は極めて小さいにもかかわらず、数学的には曲線上で有効な公開鍵ポイントを生成します。そのため、証明書は標準的な構造チェックを通過してしまい、根底にある暗号学的な脆弱性が隠蔽されていました。Google ChromeとFirefoxは直ちにこれらの証明書をブロックし、AppleとMicrosoftもこれに追随しました。
ミスには証跡があり、見過ごされた警報もあった
報告された原因は、2025年4月に行われた鍵生成セレモニーに遡ります。この時、eMudhraは鍵のエクスポートをテストするためにスクリプトを修正しました。このスクリプトが誤って、ハードウェアセキュリティモジュール（HSM）上に脆弱な予備の鍵ペアを生成してしまったのです。オペレーターはラベルが似ていたために混同し、本来意図していた暗号学的に強力な鍵ではなく、この侵害された鍵を証明書リクエストに使用してしまいました。
重要なのは、2025年6月に警告が発せられていたという点です。クロス署名を行っていたSectigoは、eMudhraの証明書失効リスト（CRL）に無効な署名があることを報告しました。この不一致は、eMudhraが発行済み証明書に埋め込まれた脆弱な鍵ではなく、本来の強力な鍵でCRLに署名しようとしたために発生しました。
根本的な不一致を調査する代わりに、eMudhraは脆弱な鍵を使用して失効リストに再署名を行いました。この回避策によって症状は実質的に隠蔽され、根本的なセキュリティ上の欠陥がその後16ヶ月間も放置されることとなりました。
運用面において、このインシデントは2つの重要な教訓を浮き彫りにしました。鍵生成セレモニーでは、生成されたすべての暗号資産に対して独立したアイデンティティと強度のチェックが求められます。さらに、公開鍵基盤の文脈において署名の不一致が発生した場合は、表面的な回避策ではなく、即座にインシデント対応を開始しなければなりません。
ブラウザにはガードレールがあるが、ビルドシステムにはないことが多い
SectigoがeMudhraの中間証明書にクロス署名したことで、プラットフォームの信頼ストア全体に広範な影響が及びました。研究者のWayne氏は、侵害された8つの鍵それぞれを使用して「We have a problem here（ここに問題がある）」という証明メッセージに署名することで、制御権を証明しました。これにより、鍵の侵害が確認され、悪用の可能性が広範囲に及ぶことが浮き彫りになりました。
Google ChromeやMozilla Firefoxなどのブラウザは、多くの場合数時間以内に証明書を失効させました。これらのブラウザはCertificate Transparency（CT）ログを強制しており、信頼されたすべてのTLS証明書を公開記録しています。ブラウザは通常、これらのログに存在しない証明書を拒否します。これは、ブラウザレベルでの直接的な悪用を防ぐための重要な保護手段です。
しかし、ブラウザ以外のクライアントには、こうした堅牢な防御機能が欠けていることがよくあります。curl、Python、Node、Go、Gitなどのツールは、ローカルのCAバンドルに依存することが多く、CT（Certificate Transparency）や失効確認を完全にスキップしてしまいます。そのため、これらのツールはマシン・イン・ザ・ミドル（MITM）攻撃に対して脆弱な状態にあります。
実用上のリスクは甚大です。これらの偽造キーを悪用する攻撃者は、以下を標的にする可能性があります。
- API呼び出し
- インストールスクリプト
- CIランナー
- クラウド認証情報
また、コード署名キーが2つ侵害されたことで、悪意のあるアップデートやアプリケーションが配布される可能性があり、偽造ソフトウェアに関する懸念も高まりました。技術的な詳細については、Mozilla Bugzilla: eMudhra Private Key Compromise of Intermediate Certificatesを参照してください。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
トラストストアにパッチを適用し、パイプライン全体をテストする
ブラウザベンダーやプラットフォーム運営者は、影響を受けた証明書を信頼しないよう迅速に対応しました。Apple、Google Chrome、Microsoft、Mozillaは数日以内に侵害された中間証明書をブロックし、SectigoはeMudhraとのクロス署名契約を終了しました。Goは緊急リリースであるバージョン1.27.3を発行し、標準ライブラリ内でこれら8つの中間証明書を直接ブロックしました。
デバイスやソフトウェアのアップデート状況は、特に組み込みシステムにおいて依然として異なる場合があります。リスクを軽減するため、オペレーティングシステムとCAパッケージを直ちにアップデートしてください。Goなどの言語ランタイムは1.27.3に、Pythonのcertifiパッケージは2026.10.19に更新してください。コンテナイメージとCI/CDランナーを再ビルドし、すべての依存関係が最新であることを確認してください。
公開されているインシデントテスト用エンドポイント DV G3B eMudhra.we-have-a-problem.com を使用して、クライアントをテストしてください。クライアントがエラーで証明書チェーンを拒否すれば、安全です。この検証ステップは、証明書の信頼性に依存するすべてのシステムにとって不可欠です。
このインシデントは、PKIに関する重要な教訓を浮き彫りにしました。フォーマットのチェックだけでは、ランダム性や意図を証明することはできません。キーセレモニーの一部として、キー強度のチェックを自動化してください。証明書の公開鍵が、単に構造的に有効であるだけでなく、意図したHSMキーと正確に一致していることを検証してください。Certificate Transparency (CT) ログを監視し、Sectigoの2025年6月の警告のような無効な失効署名を、深刻なセキュリティ緊急事態として扱ってください。
よくある質問
eMudhraの秘密鍵には何の問題がありましたか？
8つの中間CA証明書において、予測不可能な384ビットの値ではなく、4を含む非常に小さな秘密鍵値が使用されていました。対応するキーは、わずかな可能性をテストするだけで復元可能でした。
一般的なブラウザユーザーは危険にさらされていましたか？
最新のブラウザのCertificate Transparency要件は、ログに記録されていない偽造証明書をブロックするのに役立ちましたが、保護やアップデートの状況はまちまちでした。ブラウザ以外のソフトウェアには、同等のチェック機能が欠けていることがよくあります。
なぜCIパイプラインが懸念されたのですか？
ビルドパイプライン内のツールやサービスは、Certificate Transparencyや証明書の失効確認を行わずにローカルのCAバンドルを信頼し、偽造されたサーバー証明書を受け入れてしまう可能性があるためです。
開発者は何をすべきですか？
オペレーティングシステムと言語ランタイムのトラストストアを更新し、影響を受けるコンテナを再ビルドし、ブラウザ以外のクライアントやCIランナーの証明書検証動作をテストしてください。