eMudhra中間CA侵害の詳細と修復ガイド

8つのeMudhra中間認証局（CA）証明書の秘密鍵が侵害され、ウェブサイトのなりすましの重大な脅威が生じています。これらの侵害された証明書は、Mozilla、Microsoft、Apple、Chromeなどの主要ベンダーが信頼するルートプログラムにチェーンしており、ユーザーと開発者による即時の対応が必要です。

侵害の理解

この侵害は典型的な鍵の盗難によるものではなく、eMudhraの鍵生成セレモニーのプロセスにおける根本的な欠陥に起因しています。8つの中間CAに使用された秘密鍵は本質的に弱く、特にECC鍵生成において256未満の整数を使用していました。この弱点により、秘密鍵は簡単に回復可能で、実質的に1バイト鍵となっていました。

根本原因分析

eMudhraの予備評価によると、根本原因は鍵生成プロセス中の人為的ミスでした。CAは、エクスポート用のラップ/アンラップ手順をテストするために、通常の鍵生成セレモニー（KGC）スクリプトへの承認済み逸脱を導入しました。この欠陥のあるスクリプトが、誤って2番目の弱いテスト鍵セットを作成しました。これらの弱い鍵が誤って証明書署名要求（CSR）の作成に使用され、その後ルートCAによって署名され、Sectigoによってクロス署名されました。

即時対応とセキュリティへの影響

主要なトラストストア運営者は、なりすましのリスクを軽減するために迅速に対応しました。侵害された証明書は主要プラットフォームでブロックされ、CA自体も影響を受けた中間CAを失効させました。

ブラウザおよびOSの修復タイムライン

  • FirefoxおよびChrome: 2026年10月17日から証明書がブロックされました。
  • Appleデバイス: 2026年10月19日からブロックが開始されました。
  • Microsoft: 2026年10月20日からブロックが開始されました。

セキュリティリスク評価

侵害された中間CAの秘密鍵を保有する攻撃者は、任意のウェブサイトやサービスをなりすます可能性があります。ブラウザベンダーはユーザーを保護するために失効ツール（OneCRL、CRLite、CRLSetsなど）を使用していますが、失効情報を消費せず、侵害された中間CAを信頼しなくなるためのソフトウェア更新が必要なクライアントでは、リスクは依然として高いままです。

ユーザーと開発者向けの修復手順

ユーザーは、ブラウザとオペレーティングシステムをできるだけ早く最新バージョンに更新する必要があります。開発者およびシステム管理者向けには、さまざまなソフトウェアパッケージに特定のパッチが必要です：

開発者およびソフトウェアパッチ

ソフトウェア パッチ済みバージョン リンク
Go 1.27.3, 1.26.10 golang-announce
Electron 44.9.1, 43.8.1, 42.11.16 electron/electron/releases/tag/v44.9.1
Python certifi 2026.10.19 certifi/python-certifi/releases/tag/2026.10.19
Rust rustls-webpki 0.103.16 rustls/webpki/releases/tag/v%2F0.103.16
Rust webpki-roots / webpki-root-certs 1.0.10 rustls/webpki-roots/releases/tag/v%2F1.0.10
Homebrew ca-certificates 2026-09-25_1 Homebrew/homebrew-core/blob/d02b8762f4a29859c47a635a0d2683223fea9812/Formula/c/ca-certificates.rb
NSS 3.131.1 mozilla.org/g/dev-tech-crypto/c/vSxZxnOMMvs
uv 0.13.4 astral-sh/uv/releases/tag/0.13.4

高度なシステム回避策

オペレーティングシステムをすぐに更新できないユーザーは、影響を受けるルートを手動で信頼しないようにすることが可能ですが、これは一般ユーザーには推奨されません。

  • macOS: ユーザーは、awkを使用して/etc/ssl/cert.pemから影響を受けるルートを削除し、組み込みの/usr/bin/curlが侵害された中間CAを信頼しないようにできます。
  • Linux (Debian/Ubuntu): /etc/ca-certificates.confを変更し、update-ca-certificatesを実行することで、影響を受けるルートを信頼しないようにできます。
  • Linux (Fedora/RHEL/CentOS): 影響を受けるルートをシステムのブロックリストディレクトリ（/etc/pki/ca-trust/source/blocklist）に追加し、trust extractおよびupdate-ca-trustを使用してトラストストアを更新できます。
  • NetBSD: certctl untrustを使用して影響を受けるルートを信頼しないようにできます。

PKIにおける体系的な脆弱性

このインシデントは、現在の公開鍵基盤（PKI）エコシステムにおけるいくつかの体系的な弱点を浮き彫りにしています。特に、証明書の失効と信頼の配布に関するものです。

失効の課題

中間CAはルートCAに影響を与えずに迅速に失効できるように設計されていますが、このメカニズムの有効性は不均一です。主要なブラウザベンダーは高度な失効ツールに投資していますが、他の多くのクライアントやソフトウェアパッケージにはこの機能がなく、侵害を認識するためにソフトウェアの更新に依存する必要があります。

組み込みトラストストア

多くのソフトウェアベンダーは、独自のCAトラストストアのバージョンをバイナリ内に埋め込んでいます。これにより、システム全体のCAバンドルにパッチを適用してもこれらのアプリケーションが自動的に保護されないため、重大な脆弱性が生じ、特定のアプリケーションが更新されるまで多くのシステムが脆弱なままになります。

ポリシー改革の必要性

このインシデントに関するコメントでは、核心的な問題は単に技術的なものではなく、基本的な証明書ポリシーと執行の失敗であると示唆されています。現在のシステムでは、CAは地理的または組織的な範囲に関係なく、任意のドメインを保証できます。批評家は、SPFがメールサーバーの表現を制限するのと同様に、ドメイン固有の制限への移行を主張しており、このような大規模な侵害がこれほど広範な影響範囲を持つのを防ぐことを求めています。

Sources

関連