cryptography - PKCS#7 SignedData 和多种摘要算法

Question

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

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

看来在 PKCS#7 标准中，提供多个摘要的唯一方法是提供多个 SignerInfo，每个摘要算法对应一个。不幸的是，这似乎会导致安全性的净下降，因为攻击者能够使用最弱的摘要算法剥离除 SignerInfo 之外的所有内容，而仅靠该摘要算法仍将形成有效的签名。这种理解正确吗？

如果是这样，我的想法是在 SignerInfo 的authentiatedAttributes 字段中使用自定义属性，为附加摘要算法提供附加消息摘要(将 SHA1 保留为“默认”算法以实现向后兼容性)。由于该字段作为单个 block 进行身份验证，因此可以防止上述攻击。这看起来是一个可行的方法吗？有没有办法在不超出 PKCS 标准的情况下完成此任务或类似的任务？

Answer 1

是的，你说得对，在当前CMS RFC 中提到了消息摘要属性

The SignedAttributes in a signerInfoMUST include only one instance of the message-digest attribute.Similarly, the AuthAttributes in an AuthenticatedData MUST includeonly one instance of the message-digest attribute.

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

是的，任何安全系统的强度都取决于其最薄弱的环节，因此理论上，如果您仍然接受 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，但应用 RFC 3161 - 符合签名的时间戳作为未签名的属性。这些时间戳实际上是它们自己的签名。好处是您可以使用 SHA-256 作为消息印记，并且时间戳服务器通常使用您提供的相同摘要算法应用其签名。然后拒绝任何不包含此类时间戳或仅包含消息印记/签名摘要算法弱于 SHA-256 的时间戳的签名。

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

时间戳的另一个好处是您可以将生成日期与签名相关联 - 您可以安全地声明签名是在时间戳时间之前生成的。因此，即使签名证书被撤销，借助时间戳，您仍然可以根据证书被撤销的时间精确地决定是拒绝还是接受签名。如果证书在时间戳之后被撤销，那么如果证书在时间戳时间之前被撤销，您可以接受签名(添加安全裕度(又名“宽限期”) - 信息发布需要一些时间)那么你想拒绝签名。

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