印度CA机构eMudhra私钥泄露：8个中间证书密钥仅为单字节

网络安全 2026-10-21 09:08 5 阅读来源： Hacker News 精选

印度CA机构eMudhra八个中间证书私钥严重泄露，本应384位的密钥仅为单字节数值。攻击者从公开证书恢复私钥仅需不到一秒，Chrome和Firefox已紧急封锁相关证书并删除其根证书。

印度 CA 机构 eMudhra 私钥严重泄露：8 个中间证书密钥仅为单字节数值

安全研究人员发现，印度证书授权机构 eMudhra 的八个中间证书的私钥存在严重缺陷。这些本应长达 384 位的随机数，实际上仅为极小的整数——例如 4、56 或 115。从公开证书中恢复这些私钥仅需不到一秒钟。

事件时间线与处置措施

10 月 17 日（星期六），一位安全研究人员向 Apple、Google、Microsoft、Mozilla 以及 eMudhra 报告了这 8 个 eMudhra 中间证书私钥泄露的情况。当晚，Chrome 浏览器推出了 CRLSet 更新以阻止相关证书，Mozilla 也通过 OneCRL 在 Firefox 中实施了封锁。10 月 20 日（星期二），Mozilla 公开宣布此事并发送 NSS 更新，正式删除了 eMudhra 根证书。

涉事证书包括六个 TLS 发行 CA（涵盖 DV、OV 和 EV 类型，每类两代）以及两个代码签名 CA。这些证书均创建于 2025 年 4 月，并于 2025 年 5 月由 Sectigo 的 AAA 证书服务根进行交叉签名。

安全研究员伊恩·卡罗尔 (Ian Carroll) 对此总结道：“它们本质上是软弱的单字节密钥，任何人都可以对其进行分解。”

技术原理：为何 P-384 私钥会失效

这些密钥基于 P-384 椭圆曲线生成。在椭圆曲线加密中，私钥是一个数字 d，而公钥则是 d × G（其中 G 是曲线上的固定基点）。向前推演容易，但从公钥反推 d 被认为在计算上不可行，前提是 d 必须是一个极其庞大的随机数。

P-384 私钥应当是一个随机的 384 位数字，拥有约 $2^{384}$（即 $10^{115}$）种可能性，从而确保无法被穷举搜索。然而，eMudhra 生成的密钥却呈现出如下形态：

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

相比之下，正常的 P-384 私钥应类似这样：

d = 0x48ac06790886c80c48d31691fd4c0fe9ce3207f9807f2fe571d6e4ec426d78644298fc53df2b92566970e757ac998c34

所有八个泄露的密钥均属此类情况。由于一个字节仅有 256 个可能的值，攻击者只需计算 1×G, 2×G, 3×G... 直到与证书匹配即可，最多仅需 255 步。这意味着每一个信任这些证书的客户，其安全性仅依赖于区区八位数。

受影响的证书列表

经核查，涉及泄露的 16 个证书（8 个密钥分别用于两个发行证书）的具体私钥值如下：

中级证书名称	类型	私钥值 (d)
EM DV TLS CA - G3B	TLS	156
EM DV TLS CA - G3C	TLS	230
EM EV TLS CA - G3B	TLS	115
EM EV TLS CA - G3C	TLS	56
EM OV TLS CA - G3B	TLS	155
EM OV TLS CA - G3C	TLS	4
EM OV CS CA - G3B	代码签名	66
EM OV CS CA - G3C	代码签名	237

值得注意的是，这些弱密钥生成的公钥在结构检查中完全合法。编码正确，曲线有效，只有通过尝试恢复私钥才能发现异常。

“无法追溯”的安全隐患

通常当 CA 密钥泄露时，人们会推测是谁窃取了密钥。但在本案中，无人需要窃取。自证书存在之日起，密钥实际上就是公开的。任何人在 2025 年 4 月之后查看这些证书，都能在几毫秒内于原始硬件上找回密钥。这就形成了一个长达 17 个月的窗口期，期间是否有人利用该漏洞尚不清楚。

虽然 Chrome 强制执行证书透明度 (CT)，且 CT 日志显示没有与这些 CA 链接的 TLS 证书签发记录，这对主流浏览器用户而言是一种安慰。然而，CT 机制主要用于检测错误签发，无法直接阻止攻击，且许多软件默认并不检查 CT。

非浏览器环境下的暴露风险

主流及更新后的浏览器可能相对安全，因为它们大多强制要求 CT。但其他生态系统面临巨大风险。大多数非浏览器的 TLS 客户端（如 curl, Python, Node, Go, Java, git, 包管理器及各类脚本守护进程）通常依赖磁盘上的 CA 捆绑包，默认不检查撤销状态，也不检查 CT。因此，eMudhra 和 Sectigo 撤销这些中间证书并不能保护这些系统。

以下场景极易受到伪造证书的攻击：

程序安装与自动更新：许多工具通过 HTTPS 下载脚本或二进制文件进行安装或更新（如 rustup, nvm, Homebrew 安装程序, IoT 固件更新器等），若缺乏签名检查，伪造证书可能导致攻击者代码以 root 权限运行。
CI/CD 管道：GitHub/GitLab 运行器、Jenkins 及构建容器在获取依赖和推送工件时，持有云密钥、注册表令牌和签名密钥。它们往往运行在陈旧的基础镜像上，底层依赖 Curl, Python, Go 和 Node。
服务器对服务器 API 调用：支付提供商、Webhook、OAuth 代币交换及云 SDK（如 AWS CLI, boto, Terraform, kubectl）常在标题中携带 API 秘密和客户数据。
物联网、嵌入式与 OT 设备：摄像机、路由器、汽车、医疗设备、智能家电、支付终端和工业控制器。这些设备的资金结算周期长（部分至 2039 年），难以及时更新，构成了“无法追溯”的现实威胁。
Windows 代码签名：Windows 直接信任 eMudhra CS 根。使用 EM OV CS CA - G3B/G3C 签名的恶意软件将被视为合法的出版商签名软件。

测试表明，在默认设置下，curl 验证 SSL 证书为 OK，Python 完成握手，Node 返回授权 True。在 Windows 上，除非开启撤销检查，否则 CryptoAPI 接受该链；即便开启检查，也可能因路径问题导致撤销状态未被正确识别。

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:~$