Cryptography PKCS#7签名数据和多摘要算法

我正在研究将一个应用程序从SHA1作为默认的PKCS#7 SignedData digest算法升级到更强大的digest（如SHA256），以保持签名验证器（不支持除SHA1以外的digest算法）的向后兼容性。我想检查一下我对PKCS#7格式和可用选项的理解

我想我要做的是同时使用SHA1和SHA256（或者更一般地说，一组摘要算法）对消息内容进行摘要，这样较旧的应用程序可以继续通过SHA1进行验证，而升级的应用程序可以开始通过SHA256进行验证（更一般地说，是提供的最强摘要），而忽略较弱的算法。[如果有更好的方法，请告诉我。]

似乎在PKCS#7标准中，提供多个摘要的唯一方法是提供多个SignerInfos，每个摘要算法一个。不幸的是，这似乎会导致安全性的净降低，因为攻击者可以使用最弱的摘要算法除去除SignerInfo之外的所有签名信息，仅此算法仍将形成有效的签名。这种理解正确吗

---

如果是这样，我的想法是在SignerInfo的authenticatedAttributes字段中使用自定义属性，为其他摘要算法提供额外的消息摘要（将SHA1保留为向后兼容的“默认”算法）。由于此字段作为单个块进行身份验证，因此可以防止上述攻击。这似乎是一种可行的方法吗？有没有一种方法可以在不超出PKCS标准的情况下实现此功能或类似功能？

是的，您是对的，在当前的RFC中，它提到了

signerInfo中的SignedAttribute 必须仅包含消息摘要属性的一个实例。 类似地，AuthenticatedData中的AuthAttributes必须包括 只有消息摘要属性的一个实例

因此，使用标准签名属性提供多个消息摘要值的唯一方法是提供多个signedInfo

是的，任何安全系统都和其最薄弱的环节一样强大，因此理论上，如果您仍然接受SHA-1，那么添加带有SHA-256的SignedInfo将不会获得任何好处-正如您所说，更强的签名总是可以被剥离的

具有自定义属性的方案更难打破，但仍有一个SHA-1散列可能会受到攻击。这不再像剥离属性那么简单了——因为它被签名覆盖了。但是：

还有一种摘要算法，用于摘要签名属性，该属性是最终签名值的基础。你打算在那里用什么？SHA-256还是SHA-1？如果是SHA-1，则您将处于与以前相同的情况：

如果我可以为SHA-1生成冲突，那么我将去掉您的自定义SHA-256属性，并伪造SHA-1属性，从而使签名的最终SHA-1摘要再次相加。这表明，如果签名摘要算法也是SHA-256，那么只有在安全性方面才会有所提高，但我猜这是没有选择的，因为您希望保持向后兼容

在您的情况下，我建议始终使用SHA-1，但将符合时间戳的时间戳作为未签名属性应用于签名。这些时间戳实际上是它们自己的签名。好的是，您可以使用SHA-256作为消息压印，并且时间戳服务器通常使用您提供的相同摘要算法应用其签名。然后拒绝任何不包含此类时间戳或仅包含时间戳且消息压印/签名摘要算法弱于SHA-256的签名

这个解决方案有什么好处？您的遗留应用程序应该检查是否存在未签名的时间戳属性，以及是否使用了强摘要，但应忽略它们，并以与以前相同的方式继续验证签名。另一方面，新的应用程序将验证签名，但还将验证时间戳。由于时间戳签名“覆盖”了签名值，攻击者不再能够伪造签名。虽然签名使用SHA-1作为摘要值，但攻击者也必须能够破坏时间戳的更强摘要

时间戳的另一个好处是，您可以将生产日期与您的签名相关联——您可以安全地声明签名是在时间戳之前生产的。因此，即使要吊销签名证书，借助时间戳，您仍然可以根据证书被吊销的时间精确地决定是拒绝还是接受签名。如果证书在时间戳之后被撤销，则您可以接受签名（添加安全裕度（也称为“宽限期”）——信息发布之前需要一段时间），如果证书在时间戳之前被撤销，则您希望拒绝签名

---

时间戳的最后一个好处是，如果某些算法变弱，您可以随时间更新它们。例如，您可以使用最新的算法每隔5-10年应用一个新的时间戳，并使新的时间戳覆盖所有旧的签名（包括旧的时间戳）。这样，较弱的算法就会被更新、更强的时间戳签名覆盖。看看（也有一个，但现在已经过时了），它基于CMS，并试图应用这些策略来提供CMS签名的长期存档

已验证的属性实际上不是使用每个signerInfos签名算法进行了验证吗？如果是这样的话，我想你还是在你开始的那条船上。说得好。我认为经过身份验证的属性本身可能包含SignedData元素