八位信任;eMudhra的CA密钥在毫秒内被破解
eMudhra的一个证书授权私钥是数字4。这不是以4开头的数字,也不是后面跟着几百个随机数字的数字,就是4……另一个是56,还有一个是115。我知道,因为我刚刚在我的笔记本电脑上从它们的公共证书中恢复了所有密钥,这个过程花了不到一秒钟。发生了什么事情?在10月17日星期六,一位安全研究人员向苹果、谷歌、微软、Mozilla和eMudhra报告称,八个eMudhra中间证书的私钥被泄露。Chrome在当晚推送了一个CRLSet更新封锁了这些证书,Mozilla则在几个小时后通过OneCRL在Firefox中封锁了它们。在10月20日,Mozilla公开宣布并发布了一个NSS更新,移除了eMudhra根证书,Chrome确认该根证书将纳入Chrome根存储的第43版。这八个中间证书是六个TLS发行CA(DV、OV和EV,各两代)以及两个代码签名CA,都是在2025年4月创建的。它们每一个还在2025年5月由Sectigo的AAA证书服务根证书进行了交叉签名。这是所发生的事情,但“怎样”才是有趣的部分,Ian Carroll在讨论中用一句话总结道:它们本质上是弱的单字节密钥,任何人都可以因式分解,问题无法被遏制。私钥实际上是什么?这些是定义在P-384曲线上的椭圆曲线密钥。私钥只是一个数字d。公钥,也就是在证书中供全世界查看的东西,是d × G,其中G是每个人使用的曲线上的一个固定点,而“×”表示利用曲线的特殊算术将G自我相加d次。向前计算很简单,但反向计算,从公钥到d,被认为是不切实际的。这就是整个安全模型,它只有在d非常大的情况下才能成立。P-384的私钥应该是一个随机的384位数字,这给你提供了2³⁸⁴个可能性(约为10¹¹⁵),所以没有人会去搜索这个。eMudhra的密钥看起来是这样的:d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004 一个P-384的私钥应该看起来是这样的:d = 0x48ac06790886c80c48d31691fd4c0fe9ce3207f9807f2fe571d6e4ec426d78644298fc53df2b92566970e757ac998c34 那是47个字节的零加上一个字节,所有八个密钥都是这样的。一个字节有256个可能的值,所以“搜索”就是:计算1 × G,2 × G,3 × G,并在匹配证书时停止,最多254步。因此,整个事情,那些CA可能签发的每一个证书,所有信任它们的客户端,都寄托在八位上。我检查了Mozilla附上了受影响证书的信息,因此我提取了所有16个证书(8个密钥,每个密钥都在两个签发的证书中使用:一次由eMudhra,另一次由Sectigo)并进行了暴力破解。每一个都立即崩溃,六个TLS值和两个代码签名密钥同样脆弱:中间类型 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 有趣的是,这些证书看上去没有任何问题。从d = 4推导出的公钥是曲线上的一个完全有效的点,编码没有问题,曲线没有问题,每个结构检查都通过。唯一的方法是去尝试。为什么“无法被遏制”?通常,当CA密钥被泄露时,意味着有人偷了它!有一个小偷,有一个发生的时刻,而且你至少可以推测出现在谁可以访问该密钥。在这里,没有人需要偷任何东西。密钥从证书存在的那天起就有效地是公开的。自2025年4月以来,任何查看这些证书的人都可以在普通硬件上在毫秒内恢复该密钥。这是一个17个月的窗口期,没有办法知道是否有人做过这一点。Chrome指出,由于Chrome强制执行证书透明性,且没有TLS证书与这些CA链接出现在CT中,因此在Chrome中没有伪造证书可以被默认信任。这是事实,对浏览器来说是令人放心的。不过,CT检测错误签发,但并不防止错误签发,许多软件根本不检查CT。今天谁受到影响?主流和更新的浏览器可能绝对没问题。Chrome和Firefox直接封锁了这些中间证书,并且两者都要求CT,而Safari也要求CT。然而,其他情况则不同。大多数非浏览器的TLS客户端(基本上所有其他的,使用默认设置)——像curl、Python、Node、Go、Java、git、包管理器以及你拥有的每一个脚本和守护程序——在这里做了三件重要的事情:它们信任磁盘上的CA捆绑包,默认情况下不检查吊销,并且不检查CT。所以,eMudhra和Sectigo撤销这些中间证书对它们根本没有帮助。关于TLS和PKI,我经常发现这是一个问题。
本站免费、广告极少。如果觉得有帮助,可以请我们喝杯咖啡 —— 任何金额都对持续运营有实际帮助。
☕请我喝杯咖啡