一把等于 4 的私钥

一把本该是 384 位随机数的私钥，最后写成了 4。

4。

一个整数。没有省略号，没有后面跟着几百位随机数。就是 4。

Scott Helme 在笔记本上把 eMudhra 的八把中间证书私钥全算了出来，花了不到一秒。八把钥匙里，有一把的私钥是 4。另外几把是 56、66、115、155、156、230、237。

这里没有靶场，也没有演戏。eMudhra 是一家印度证书认证机构，总部在班加罗尔，2008 年成立，在印度国家证券交易所和 BSE 上市，自称签发过六千多万张证书。它给网站、软件、银行、政府项目做身份担保。那些浏览器地址栏里的小锁，本来应该由它来守住。

现在，八把钥匙躺在公开证书里，像八张写着“欢迎光临”的门禁卡。

一、一把等于四的私钥

先把“私钥”这东西说清楚。

这八把是 P-384 曲线上的椭圆曲线密钥。私钥是一个数字，记作 d。公钥是 d × G，G 是曲线上一个固定的点。从 d 推到公钥很容易，从公钥倒推 d，在数学上被认为不可行。整套 TLS 的安全感，就建立在“d 足够大、足够随机”这件事上。

一把正常的 P-384 私钥，应该是 384 位随机数，大约 10¹¹⁵ 种可能。写成十六进制，是 96 个字符，密密麻麻，像一串被猫踩过的键盘。

eMudhra 的私钥长这样：

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

47 个字节的零，最后一个字节是 4。

这不是把 P-384 算穿了。没有人用超级计算机去解离散对数。问题出在密钥生成：该随机的地方，给了一个 0 到 255 的整数。八把钥匙，八个单字节。攻击者只需要算 1 × G、2 × G、3 × G，最多试 255 次，就能在证书里找到匹配的公钥。

Scott Helme 把八把全试了一遍，不到一秒。后来他又用一个 AI agent，一句提示词，把同样的过程重跑了一遍。八把钥匙的 d 分别是：

中间证书 用途 私钥 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

最让人发凉的地方，是这些证书看起来完全正常。公钥是曲线上的合法点，编码没问题，曲线没问题，结构检查也全部通过。你盯着证书看，看不出任何异常。唯一的破绽，是你试着把 0 到 255 代进去，然后发现门开了。

没有人闯进 HSM 把钥匙偷走。钥匙从出生那天起就近似公开。只要证书在，私钥就在那里，等着被人试出来。

二、证书链在信任什么

浏览器地址栏里的小锁，很多人以为是在说“这个网站很安全”。它实际说的是：这个网站的证书，由一个我信任的机构签过名。

这套东西叫证书链。最上面是根证书，躺在浏览器和操作系统的信任库里；根证书签中间证书；中间证书再签网站自己的叶子证书。浏览器验证的时候，会沿着链子往上走，走到一个自己认识的根，然后点头。

问题就出在中间这一层。

根证书的私钥通常锁得很深，中间证书的私钥却要频繁用来签叶子证书。它像一把放在前台抽屉里的印章，使用方便，丢起来也方便。eMudhra 这八把就是中间证书的私钥：六把能签网站证书，两把能签软件代码。

拿到这八把钥匙的人，可以给任何域名签一张“合法”的证书。bank.example、api.stripe.com、你公司的内网登录页，都可以。浏览器只要还信任这条链，就会把伪造的站点当成真的。

这还不只是“看错网站”那么简单。攻击者如果在同一个 Wi-Fi 下，可以做中间人，读你发出去的东西，改你收到的页面。代码签名的那两把更麻烦：用它们签出来的恶意软件，在没做吊销检查的系统上，会显示成一个有正规发布者的程序。

eMudhra 这八把中间证书，还被 Sectigo 的 AAA Certificate Services 根交叉签过。交叉签名的本意是让新旧根之间平滑过渡，结果在这件事里，它把信任面又扩大了一圈。六把 TLS、两把代码签名，再加上 Sectigo 的交叉链，够很多人忙一阵了。

浏览器这边有 Certificate Transparency。所有公开的 TLS 证书都要进 CT 日志，伪造的证书一旦出现，就有机会被发现。Chrome 还强制要求 CT，所以这次没有出现“浏览器默认信任了一张伪造证书”的公开记录。

CT 能发现，不能阻止。它像小区的监控：拍到了，不等于门没被撬。更麻烦的是，大量非浏览器软件根本不看 CT，也不看吊销列表。

curl、Python、Node、Go、Java、git、各种包管理器，默认信任的是磁盘上的 CA bundle。它们中的大多数不会主动查 OCSP，也不会查 CRL。你把中间证书吊销了，它们不知道；你把根移除了，它们要等下一次更新。CI/CD、支付回调、OAuth、云 SDK、安装脚本，全在这条长长的尾巴上。

三、八把钥匙，十七个月

时间线不复杂，复杂的是中间那十七个月。

2025 年 4 月 30 日，eMudhra 在一场密钥仪式上生成了这八把中间证书的密钥。按 eMudhra 在 Mozilla 工单里的说法，仪式脚本有缺陷，在 HSM 里额外生成了一套弱密钥；因为标签相似，工作人员把弱密钥当成了强密钥，拿去做了 CSR。它承认“多个步骤中出现了人为错误”。

2026 年 10 月 17 日，一个只署名“Wayne”的研究者把问题报告给 Apple、Google、Microsoft、Mozilla 和 eMudhra。为了证明，他用八把私钥分别签了同一句话：“We have a problem here - Wayne”。

10 月 18 日，eMudhra 吊销了这八把中间证书。Chrome 和 Firefox 在几小时内通过 CRLSet 和 OneCRL 封禁；Apple 在周一、Microsoft 在周二跟进；Mozilla 把 eMudhra 的根证书从信任列表里移除；Chrome 把根证书放进了 Root Store v43 的移除名单。

10 月 22 日，eMudhra 宣布退出全球 SSL/TLS 证书业务。股价在三到四个交易日里跌了三到四成。它说要迁移大约三万张证书到自己的 RSA 根 emSign Root CA - G1，并免费为客户换发。它还说，八把中间证书里只有一把实际投入过生产，没有任何一张终端证书从这些中间证书签发出去，CT 日志支持这个说法。

这些说法大概率是真的。问题是，它们回答不了另一件事：从 2025 年 4 月到 2026 年 10 月，这十七个月里，有没有人已经用过这些钥匙。

CT 日志能证明“浏览器没有信任过一张公开的伪造 TLS 证书”，但它证明不了“没有人拿这些钥匙去签过一张不在 CT 里的证书”。非浏览器客户端不查 CT，也不查吊销；代码签名证书不在 CT 的覆盖范围里。eMudhra 说没有终端证书被签发，但没有谁能回到过去，把十七个月里每一台没更新的设备都检查一遍。

这不是“丢了钥匙”的故事。丢钥匙至少还有一个丢失的时刻，有一个可以追查的嫌疑人。这里的钥匙从生成那天起就近似公开，任何人、任何时间、任何一台普通笔记本，都可以把它试出来。你没法知道谁试过。

四、谁在半夜换证书

事故出来以后，eMudhra 的公关还在解释，各家公司的运维已经开始连夜换证书。

三万多张证书要迁移，听上去像个可以排期的项目。真做起来，是另一回事。证书不是换个文件就完了，它后面挂着负载均衡、CDN、API 网关、邮件服务器、VPN、mTLS、代码签名、移动 App 的证书固定。每一处都要重新签发、重新部署、重新验证。哪一处漏了，用户就会在某个早上看到一个红色的警告页。

大公司有自己的 PKI 团队，能连夜拉群。小公司只有一个兼职运维，证书过期提醒躺在某个没人看的邮箱里。再小一点的，是个人站长，证书是两年前图便宜买的，续费提醒发到了已经废弃的 QQ 邮箱。

浏览器厂商这次动作很快。Chrome 和 Firefox 几小时内封禁，Apple 和 Microsoft 几天内跟进。可浏览器只是最前面的一层。后面还有一堆不声不响的东西：

  • curl | sh 安装脚本，很多连签名都不验，只靠 HTTPS 那把小锁。
  • GitHub Actions、GitLab Runner、Jenkins，拿着云密钥和 registry token，从各种源拉依赖。
  • 支付回调、OAuth token 交换、云 SDK，走的是服务端到服务端，没人盯着看。
  • 路由器、摄像头、打印机、车机、医疗设备、支付终端，CA bundle 冻在固件里，可能要到 2039 年才过期。
  • Windows 的代码签名信任链，和 TLS 是两套东西，但这次一起被撬了。

Scott Helme 做过一个很具体的测试：他在本地起了一个服务器，用这八把钥匙里的一把，给 api.stripe.com 签了一张证书。默认配置下，curl 说 SSL certificate verify ok，Python 完成了握手，Node 返回 authorized: true。在 Windows 上，CryptoAPI 也接受了这条链，除非手动打开吊销检查。

api.stripe.com 只是一个例子。把域名换成你公司的内网 SSO、支付网关、对象存储、代码仓库，故事是一样的。攻击者不需要攻破这些公司，只需要站在网络路径中间，拿一张这些公司会信任的证书。

这就是“人人自危”的由来。私钥没有排着队泄露，可每家公司都突然发现：自己信任的那个上游，可能是一把等于 4 的钥匙。

五、我那个打不开的小站

我有一个常去的小站。不是大平台，没有登录，没有支付，只有一些胶片照片、几篇影评和一个很旧的歌单。下班以后，我偶尔会去那里坐一会儿，戴耳机，翻两张照片，什么都不想。

事故之后的某天，它打不开了。

Chrome 给了一个 NET::ERR_CERT_AUTHORITY_INVALID。我以为是证书过期，清了缓存，换了 DNS，又换了浏览器。Firefox 也拦，Edge 也拦。最后站主在群里说，证书是从 eMudhra 买的，正在排队换。

“三万多张，轮到我们不知道什么时候。”他说。

我盯着那个红色警告页看了一会儿。页面中间有一个“高级”按钮，点开还能继续访问。我点了一次，进去了，歌单还在，照片也还在。可地址栏那把小锁变成了一个带红色斜杠的图标，像一道没愈合的口子。

那个站没有什么秘密。它只是我用来放松的地方。可它也被一把等于 4 的钥匙波及了。站主自己的私钥没问题，服务器没被黑，数据库也没丢；出问题的是他头顶那条证书链。他把自己的门锁得很好，物业把整栋楼的钥匙弄丢了。

我后来还是把书签留着了。每次点进去，都要先看一遍警告，再点“高级”。我知道这不安全，可我更讨厌那种感觉：一个我用来发呆的地方，突然需要向浏览器解释自己是谁。

六、一次坏日子里的意外

eMudhra 的董事长在解释退出决定时，说了两层意思。

一层是生意：全球 SSL/TLS 只占公司营收的 1% 左右，数据主权和合规成本在上升，大厂又在免费发证书，这块业务的回报率越来越低。另一层是情绪：社交媒体把这件事放大了，审查的力度“与 SSL/TLS 在公司业务中的位置不成比例”。

这句话很诚实，也很冷。

对一家 CA 来说，信任不是营收占比。信任是全部。你可以说这块业务只占 1%，但用户不会按 1% 来感受风险。一个银行页面打不开，一个支付回调失败，一个 IoT 设备再也收不到更新，这些事不会因为 CA 的财报好看就变得不重要。

他们还把这件事形容成“一个坏日子里的意外”。可对下游来说，这个坏日子不是一天。证书迁移要几周，固件更新要几个月，冻结在设备里的 CA bundle 要等到 2039 年。一个 CA 的“一次性事件”，可以变成别人很多年的技术债。

中文互联网上很快出现了“印度三哥”的嘲笑。笑一笑没什么，但把这件事归到国籍上，太省事了。该问的是：为什么一场密钥仪式能同时生成两套密钥？为什么标签相似到能把弱密钥当成强密钥？为什么十七个月里没有人发现？为什么监管机构的公开声音比浏览器厂商还慢？

CERT-In 发了 advisory，说截至当时没有发现恶意利用。IFF 给 eMudhra、CERT-In 和 MeitY 写了公开信，要求事件报告、独立审计、更完整的信息披露和监管调查。CCA 这边，至少在当时，没有看到同等分量的公开说明。

浏览器厂商在三天里做完了它们该做的事。发证机构、监管机构和客户，反而花了更长时间来解释和迁移。这个对比，比“印度三哥”四个字更值得记住。

七、小锁后面，是一条很长的链

这件事之后，我重新看了一遍自己每天点开的那些小锁。

HTTPS 不是“安全”的同义词。它只说明：这条连接的另一端，拿着一张某家 CA 签过的证书；而你的浏览器，恰好信任那家 CA。它不保证对方不骗你，不保证服务器不打你，也不保证那家公司明天还在。

对站点来说，能做的事情其实很具体：把证书清单自动化，别让一张证书躺在没人记得的子域里；监控 CT 日志，看看有没有人替你签了证；配置 CAA，限制哪些 CA 能给你发证；别把全部身家押在一家 CA 上；准备好换证书的脚本，而不是等事故发生后再拉群。

对普通用户来说，能做的不多，但也不是没有：更新浏览器和系统；别在银行、邮箱、公司 SSO 的警告页上点“继续”；看到证书错误，先停一下；别把“小锁”当成“这个网站是好人”的证明。

对 CA 和监管机构来说，要求更高：密钥仪式要有多方见证和可复核的记录，HSM 的日志要能被独立检查，根证书项目要能随时做审计，事故报告要公开到足够让第三方复现。信任不是一句“请相信我们”，信任是一套可以被检查的流程。

这件事没有让我对某个国家产生恐惧。它留下的是一个很具体的问题：我们每天点开的那些小锁，背后到底是谁在值班？

如果值班的人把钥匙写在便签上，锁再亮，也没有用。

参考资料

posted @ 2026-10-30 10:12  keeper123  阅读(8)  评论(0)    收藏  举报