为什么具有 SHA1 签名的根 CA 没有风险

Chr*_*s K 11 ssl tls sha1

以 Verisign 的网站为例,它有一个带有 sha1 哈希签名的根 CA。我是否错误地理解为发现冲突,他们可以模拟 Verisign 根 CA,并使用它来生成浏览器或操作系统信任的中间证书和服务器证书。

https://www.entrust.com/need-sha-2-signed-root-certificates/ 指出:

简而言之,由于软件直接信任根证书公钥,因此不会验证根证书上的签名。根证书是自签名的,不是由另一个已被授予权限的实体签名的。根证书通过操作系统或浏览器开发者管理的根证书程序获得授权。

并引用 Google 链接:https : //security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html

注意:可信根证书的基于 SHA-1 的签名不是问题,因为 TLS 客户端通过他们的身份而不是他们的哈希签名来信任它们

假设我是一个新浏览器 - SuperUserBrowser 的作者。除了哈希签名之外,我还能如何相信我的浏览器附带的根证书是真实的?

为什么具有 SHA1 签名的根 CA“不是问题”?

Ste*_*ich 12

我是否错误地理解为发现冲突,他们可以模拟 Verisign 根 CA,并使用它来生成浏览器或操作系统信任的中间证书和服务器证书。

你错了。

至于签名本身的安全性:
对证书进行签名是为了验证该证书的颁发者,以建立信任链。由于根 CA 是信任链的受信任端,因为它是预先信任的(即存储在操作系统的信任存储中),因此不需要验证根 CA 的颁发者,因此根 CA 的签名不需要验证没关系。

对于使用弱哈希算法签名的根 CA 来创建新证书:
要签署另一个证书(即创建叶证书或中间证书),您需要拥有 CA 的私钥。与证书公钥匹配的私钥不能从证书颁发者发布的签名中导出,即使证书是自签名的(即使用试图获得的私钥签名)。

签署证书的方法是首先使用不可逆散列算法散列证书的基本部分,然后使用颁发者的私钥对其进行“加密”。要获得签署新证书所需的私钥,您需要攻击加密(RSA 或 ECC),即找到在“加密”散列证书时产生相同签名的密钥。但是,由于 RSA/ECC 签名没有被破坏,因此您无法提取私钥,因此无法使用此密钥生成新证书。获得由该证书签名的新证书的另一种方法是创建一个产生相同哈希值的证书。但是虽然 SHA-1 容易受到碰撞攻击(即 找到具有相同输出的两个输入)它(与 MD5 相反)目前不易受到您需要的原像攻击(为给定输出查找输入)。这意味着这个攻击向量也失败了。