我正在查看Subject Key Identifier
CA证书的属性,并试图了解它在验证中所起的作用,并推断验证客户端软件可能出错的原因。
当我阅读RFC3280时,我看到主题密钥标识符(SKI)就像用于构建和验证PKI链的胶水。与用于将两个证书绑定在一起的证书序列号和名称相比,滑雪似乎也是一个更安全的版本。
关于证书哈希的客户端验证,客户端只是简单地进行滑雪的“模式匹配”,还是按如下所述实际计算链式滑雪:
对于CA证书,主题密钥标识符应该从 (公钥)或生成唯一值的方法中派生。从公钥生成密钥标识符的两个common方法是:(1) keyIdentifier由位字符串subjectPublicKey值的160位SHA-1哈希(不包括标记、长度和未使用比特数)组成。(2) keyIdentifier由一个值为0100的四位类型字段和位字符串subjectPublicKey值的SHA-1哈希值中最小的60位(不包括标记、长度和未使用位串位数)组成。
我试图减轻的一个例子风险是一个格式错误的CA证书,它的公钥不散列到正确的滑雪(通过手工ASN.1编辑并从攻击者的根目录中重新签名证书)
发布于 2013-01-09 16:00:39
Subject Key Identifier
在验证中不起作用,至少在构成RFC 5280第6节的算法中不起作用。它旨在帮助路径构建,即在验证之前进行的活动:这是希望验证证书的实体组装潜在的证书链,然后通过第6节算法进行处理的时候。第4.2.1.2节描述了这一扩展,并包括以下案文:
为了方便证书路径的构造,这个扩展必须出现在所有符合条件的CA证书中,即所有证书,包括基本约束扩展(第4.2.1.9节),其中cA的值为真。在符合CA证书的情况下,主题密钥标识符的值必须是放置在由本证书主体颁发的证书的权威密钥标识符扩展(4.2.1.1节)的密钥标识符字段中的值。在执行证书路径验证时,不需要应用程序验证密钥标识符是否匹配。
这些“必须”是CA上的义务:为了符合RFC 5280描述的配置文件,CA必须注意将它颁发的证书的Authority Key Identifier
与自己的Subject Key Identifier
相匹配。注意最后一句:此匹配不是验证必须验证的部分。
RFC建议通过散列来计算密钥标识符,因为它将最大限度地减少冲突,从而保证该扩展在路径构建中的最大效率。然而,哈希并不是强制性的。CA可以以他们认为合适的任何方式选择标识符;验证器当然不会重新计算标识符。这是纯字节对字节相等的测试。另外,我知道微软的路径验证实现可以在关键标识符不匹配的情况下构建并尝试验证路径。
流氓CA通过重用密钥标识符所能做的最坏的事情是使路径构建变得更加困难;这可能会为通过密钥标识符进行路径构建的验证者触发一种拒绝服务,而这些验证者太懒了,因此无法尝试其他方法。在实践中,验证者倾向于通过匹配主题和发布者DN来构建路径,而不是关键标识符,因此实际影响应该接近于零。
发布于 2016-05-19 12:58:27
Rouge键标识符会阻碍明确的路径查找。
在最坏的情况下,必须检查几个潜在的路径是否有效。但是,您是否会在您的信任存储区中有一个带有胭脂标识符的证书?如果你不信任它,就没必要去检查那条路。如果您确实信任它,那么这条路径就不会生效。
https://security.stackexchange.com/questions/27797
复制