Eight Bits of Trust; eMudhraのCAキーがミリ秒でクラックされる

Eight Bits of Trust; eMudhraのCAキーがミリ秒でクラックされる

eMudhra社の証明書発行局（CA）の秘密鍵の一つは、数字の4です。

4から始まる数字ではなく、4の後に数百のランダムな数字が続くわけでもなく、ただ「4」です… 他の一つは56、もう一つは115です。なぜなら、私は今、それらをすべて公開証明書からラップトップで復元しましたが、1秒もかからなかったからです。

［画像: 脆弱な秘密鍵の例を示すスクリーンショット］

何が起こったのか

10月17日（土曜日）、セキュリティ研究者がApple、Google、Microsoft、Mozilla、そしてeMudhraに対し、8つのeMudhra中間証明書の秘密鍵が侵害されたと報告しました。Chromeはその夜にCRLSetアップデートをプッシュしてそれらをブロックし、Mozillaは数時間後にOneCRL経由でFirefoxでブロックしました。10月20日（火曜日）、Mozillaはこれを公に発表し、NSSアップデートをリリースしてeMudhraのルート証明書を削除しました。Chromeもルート証明書がChrome Root Store v43に含められることを確認しました。

これらの8つの中間証明書は、6つのTLS発行CA（DV、OV、EV、それぞれ2世代）と2つのコード署名CAで、すべて2025年4月に作成されました。それらのすべてが、2025年5月にSectigoのAAA Certificate Servicesルートによってクロス署名されていました。

これが「何が」起こったかですが、「どのように」が興味深い部分であり、Ian Carroll氏がスレッドで一言で要約しました。

それらは本質的に弱い単一バイトの鍵であり、誰でも分解できます。この問題は封じ込めることができません。

秘密鍵とは実際には何か

これらはP-384曲線上の楕円曲線鍵です。秘密鍵は単なる数字 d です。公開鍵、つまり世界が見る証明書に入るものは d × G です。ここで G は曲線上の固定された点であり、誰もが使用し、「×」は曲線の特殊な算術を使用して G を d 回自身に加えることを意味します。

順方向は簡単ですが、逆方向、つまり公開鍵から d を求めることは、非現実的と考えられています。それがセキュリティモデル全体であり、d が巨大である場合にのみ成り立ちます。P-384秘密鍵はランダムな384ビットの数値であるべきで、これは2³⁸⁴の可能性（約10¹¹⁵）を与え、誰もそれを検索することはありません。

eMudhraの鍵は次のようになります。

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

P-384秘密鍵は次のようであるべきです。

d = 0x48ac06790886c80c48d31691fd4c0fe9ce3207f9807f2fe571d6e4ec426d78644298fc53df2b92566970e757ac998c34

これは47バイトのゼロとそれに続く1バイトであり、8つの鍵すべてがこのようになっています。単一バイトには256の可能な値があるため、「検索」は次のようになります：1 × G、2 × G、3 × G を計算し、証明書に一致するまで（最大255ステップ）停止します。

したがって、これらのCAが発行できるすべての証明書、それらを信頼したすべてのクライアントは、8ビットにかかっていました。

確認しました

Mozillaは影響を受けた証明書を発表に添付していたため、私はそれらすべて16個（8つの鍵、それぞれ2つの発行済み証明書で使用：eMudhraとSectigoによって1回ずつ）を取得し、総当たり攻撃を試みました。すべてが即座に破れました。6つのTLS値と2つのコード署名鍵は同様に脆弱です。

これらの証明書に問題があるように見える点は何もありません。d = 4 から派生した公開鍵は、曲線上の完全に有効な点であり、エンコーディングは問題なく、曲線も問題なく、すべての構造チェックがパスします。見つける唯一の方法は試すことです。

なぜ「封じ込められない」のか

通常、CA鍵が侵害された場合、誰かがそれを盗んだのです！泥棒がいて、それが起こった瞬間があり、誰がその鍵にアクセスできるようになったかを少なくとも推測できます。

ここでは、誰も盗む必要はありませんでした。鍵は、証明書が存在した日から事実上公開されていました。これらの証明書のいずれかを見た人は誰でも、2025年4月以降のいつでも、一般的なハードウェアで数ミリ秒で鍵を復元できた可能性があります。これは17ヶ月の期間であり、誰かがそうしたかどうかを知る方法はありません。

Chromeは、Chromeが証明書透明性（CT）を強制しているため、これらのCAに連なるTLS証明書がCTに表示されなかったため、偽造証明書はChromeでデフォルトで信頼されることはなかったと指摘しました。それは真実であり、ブラウザにとっては安心できることです。しかし、CTは誤発行を検出するものであり、それを防ぐものではありません。そして、多くのソフトウェアはCTをまったくチェックしません。

今日、誰が危険にさらされているか

主流で更新されたブラウザはおそらく完全に安全です。ChromeとFirefoxは中間証明書を直接ブロックしており、どちらもCTを必要とします。SafariもCTを必要とします。

しかし、それ以外のすべては異なります。ほとんどの非ブラウザTLSクライアント（つまり、デフォルト設定のそれ以外のすべて）、curl、Python、Node、Go、Java、git、パッケージマネージャー、そしてすべてのスクリプトやデーモンは、ここで重要な3つのことを行います：ディスク上のCAバンドルを信頼し、デフォルトで失効チェックを行わず、CTをチェックしません。したがって、eMudhraとSectigoがこれらの П中間証明書を失効させたという事実は、彼らにはまったく役立ちません。これは、TLSとPKIについて話すときによく見かけることであり、クライアントエコシステムの規模がいかに大きいかが見過ごされがちです。私たちは、CRLiteのような失効のための最新ソリューションを見るときのトレーニングでこれをしばしば考慮しますが、それはデスクトップブラウザには効果がありますが、他のTLSクライアントには何も効果がありません。今、ルートストアの更新が必要なものが何であるかを考えてみてください。これは氷山の一角にすぎません。

• curl | sh インストーラーとセルフアップデーター。多くのツールは、署名チェックなしでHTTPS経由でスクリプトまたはバイナリをダウンロードしてインストールまたは更新します（rustup、nvm、Homebrewのインストーラー、数え切れないほどの「install.sh」ページ、IoTファームウェアアップデーター）。ここで偽造された証明書は、攻撃者のコードを実行することを意味し、多くの場合root権限で実行されます。
• CI/CDパイプライン。GitHub/GitLabランナー、Jenkins、ビルドコンテナは、クラウドキー、レジストリトークン、署名キーを保持しながら、依存関係を取得し、成果物をプッシュします。それらは共有ネットワーク上の古いベースイメージで実行され、すべてが下でcurl、Python、Go、Nodeを使用しています。
• サーバー間API呼び出し。支払いプロバイダー、Webhook、OAuthトークン交換、クラウドSDK（AWS CLIとbotoは独自のcertifiバンドルを使用；TerraformとkubectlはGoを使用）。これらはAPIシークレットと顧客データをヘッダーに運びます。
• IoT、組み込み、OTデバイス。カメラ、ルーター、テレビ、医療機器、スマート家電、決済端末、産業用コントローラーがコマンドやアップデートのために電話してきます。それらのバンドルは2039年まで凍結されており、「封じ込められない」という点が現実になっています。
• Windowsコード署名。これはTLSではありませんが、同じ欠陥です：WindowsはeMudhra CSルートを直接信頼します。EM OV CS CA - G3B/G3Cで署名されたマルウェアは、失効チェックを行わないものにとっては、実際のパブリッシャーからの署名済みソフトウェアのように見えます。

私はこれを自分のマシンでローカルサーバーとapi.stripe.comの証明書を使用してテストしました。この名前は、私たち全員が非常に価値があると同意できるでしょう。デフォルト設定では、curlはSSL certificate verify okと表示し、Pythonはハンドシェイクを完了し、Nodeはauthorized: trueと表示しました。これは、テストしたすべてのLinuxおよびmacOSマシンで真実でした。Windowsでは、失効チェックが有効になっていない限りCryptoAPIはチェーンを受け入れましたが、それでも2つのルートのうち1つだけが失効していると返されました。

scott@Middle-Earth:~$ curl -v --resolve api.stripe.com:18888:127.0.0.1 https://api.stripe.com:18888/
* Added api.stripe.com:18888:127.0.0.1 to DNS cache
* Hostname api.stripe.com was found in DNS cache
*   Trying 127.0.0.1:18888...
...snip...
* Server certificate:
*  subject: CN=api.stripe.com
*  start date: Oct 20 18:39:57 2026 GMT
*  expire date: Oct 21 18:44:57 2026 GMT
*  subjectAltName: host "api.stripe.com" matched cert's "api.stripe.com"
*  issuer: C=NL; O=eMudhra BV; CN=EM DV TLS CA - G3B
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: api.stripe.com:18888
> User-Agent: curl/7.68.0
> Accept: */*
>
...snip...
< HTTP/1.0 200 ok
< Content-type: text/html
<
<HTML><BODY BGCOLOR="#ffffff">
<pre>
s_server -accept 127.0.0.1:18888 -cert /tmp/tmp.rBcIpjTbZV/leaf.pem -key /tmp/tmp.rBcIpjTbZV/leaf.key -cert_chain /home/scott/code/test/intermediate-sectigo.pem -www -quiet
...snip...
</pre></BODY></HTML>
...snip...
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
scott@Middle-Earth:~$ 

その証明書に他のホスト名を任意で設定でき、そのデバイスのトラフィックを傍受するために必要なすべてが揃います。あとはネットワークパスに乗るだけです。

今すぐ何をすべきか

幸いなことに、更新可能なデバイスに必要な手順はそれほど複雑ではなく、アドバイスは基本的に「それらを更新する」ということに尽きます。問題は、更新できない、または簡単に更新できないデバイスです。

1. CAバンドルを出荷するすべてを更新する：OSのca-certificatesパッケージ、certifi、Node、Homebrew、そしてベースイメージが変更を反映したらコンテナイメージを再構築します。
2. 更新できないデバイスが難しい部分です。ルーター、プリンター、テレビ、凍結されたファームウェアを持つアプライアンスは、2039年7月までの有効期限までこれらの証明書を信頼し続けます…

8ビット。17ヶ月もの間、それが、膨大な量の非ブラウザソフトウェアと、任意のサイトの偽造証明書が、すべての暗号化されたトラフィックのセキュリティを破る可能性との間に立ちはだかっていたすべてでした。

ソース

MDSPスレッド：https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ

リサーチ発表：https://emudhra.we-have-a-problem.com/

更新 2026年10月20日 20:16 UTC
公開直後、Mozillaはインシデントチケットを公開しました：https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

eMudhraは、そのチケットで何が起こったかについての説明を提供しました。どうやら、セレモニー中に使用されたスクリプトにバグがあり、HSM上に2番目の弱い鍵ペアが作成され、名前が似ていたため、ヒューマンエラーによりCSRに間違った鍵が使用されたようです。上記の記事のテキストは、この新しい情報の結果として変更されていません。また、AIエージェントでの簡単なプロンプトでCAの秘密鍵を復元できたことも確認できます。Claudeは単一のプロンプトで秘密鍵を復元できました。

この投稿を楽しんだり、役に立ったりしましたか？
☕️ 感謝の気持ちとしてコーヒーを一杯買うことを検討してください！
🔔 投稿時に無料通知を購読してください！
🤩メンバーになって私のコンテンツをサポートしてください！

タグ：証明書発行局、証明書失効

---