eMudhraの中間CA証明書8件で秘密鍵が推測可能に、MozillaとGoogleが証明書をブロック

eMudhraの中間CA証明書8件で秘密鍵が推測可能に、MozillaとGoogleが証明書をブロック

Share

eMudhraの中間CA証明書8件で秘密鍵が推測可能に、MozillaやGoogleが信頼を無効化

 

インドの認証局(CA)eMudhraが運営する「emSign」の中間CA証明書8件について、秘密鍵が第三者によって容易に復元できる状態だったことが明らかになった。この問題により、影響を受けた認証局の秘密鍵を取得した攻撃者が、正規のWebサイトを装う不正なHTTPS証明書を発行できる可能性が生じた。利用者の通信を傍受できる条件がそろった場合には、偽の証明書を使ってWebサイトになりすまし、通信内容の閲覧や改ざんを試みるおそれがある。

原因は外部からのネットワーク侵入ではなく、秘密鍵の生成時に十分な乱数が使用されていなかったことにある。問題の8件では、P-384楕円曲線暗号を使用していたにもかかわらず、秘密鍵の値がすべて256未満の整数となっていた。本来、広大な範囲からランダムに選ばれるべき秘密鍵が極めて限られた値に収まっていたため、実質的な鍵の強度は8ビット未満となり、公開鍵から秘密鍵を短時間で復元できる状態だった。影響を受けた8件のうち、6件はTLS証明書の発行用、残る2件はコード署名用の中間CA証明書だった。

問題の報告を受け、Mozilla、Google、Apple、Microsoftなどの主要なプラットフォーム事業者は、影響を受けた証明書の信頼を無効化する対応を進めた。Mozillaは10月17日、Firefoxの証明書失効情報を配信するOneCRLを更新し、対象となる中間CA証明書をブロックした。Googleも同日、ChromeのCRLSetを更新して影響を受けたTLS用中間CAの公開鍵をブロックした。これらの仕組みにより、通常の設定で利用しているFirefoxとChromeでは、ブラウザ本体の更新や再起動を行わずに保護が適用された。

一方、ブラウザとは異なり、証明書の失効情報を自動的に取得しないアプリケーションやランタイム環境では、影響が残る可能性がある。Go、NSS、Pythonのcertifi、Rust、Electronなど、独自の証明書検証処理や信頼ストアを利用するソフトウェアについては、それぞれの更新状況を確認する必要がある。失効情報の配信機能を持たない環境では、関連するライブラリや証明書ストアの更新、問題のある認証局への信頼設定の変更などが対応策となる。ただし、必要な対処方法は各ソフトウェアの証明書検証方式によって異なる。

一般利用者については、ブラウザやオペレーティングシステムをサポート対象のバージョンに維持し、セキュリティ更新が適用されているかを確認することが基本的な対応となる。Firefoxでは通常の設定でOneCRLによる保護が適用されているが、失効情報の取得を制限する独自設定を使用している場合に備え、デスクトップ版とAndroid版のFirefox 158.0.1なども公開された。更新が停止した古いブラウザや、証明書失効情報を取得できないクライアントでは、不正な証明書を信頼してしまう可能性が残るため、利用環境に応じた確認が必要となる。

Linuxディストリビューションなどでは、証明書の信頼設定がシステムやアプリケーションごとに異なる場合がある。失効情報を参照しない環境では、ca-certificatesなどの関連パッケージを更新するほか、必要に応じて影響を受けた認証局への信頼を取り消す方法も考えられる。ただし、ルート証明書を手動で削除すると、正常な証明書を利用するサービスにも接続できなくなる可能性がある。そのため、一般利用者が独自に信頼ストアを変更するのではなく、各ディストリビューションやソフトウェアの提供元が案内する更新手順に従うことが望ましい。

eMudhraは10月18日、問題の中間CA証明書8件を失効させた。Mozillaは10月20日、NSS 3.131.1で「emSign ECC Root CA – G3」を信頼対象から削除し、失効情報を利用しないアプリケーションへの影響にも対応した。GoogleもChrome Root Storeから同ルート証明書を削除する方針を示しており、対象となる環境への変更は10月27日に展開される予定だ。また、GoogleはeMudhraが運営するほかの認証局証明書についても、引き続き信頼対象として維持できるか評価を進めている。

今回の問題は、認証局の秘密鍵生成処理に不備がある場合、その影響が個別のWebサイトにとどまらず、証明書を信頼する複数のソフトウェアやサービスに及ぶ可能性を示している。主要ブラウザでは失効情報の配信によって早期に対策が講じられた一方、独自の信頼ストアを使用するアプリケーションなどでは、更新の適用状況によって影響が残る可能性がある。認証局の鍵管理に加え、証明書の失効情報を各クライアントに確実に反映できる仕組みが、今回の対応で焦点となっている。