cryptography - PKCS#7 SignedData and multiple digest algorithms

Question

I'm investigating upgrading an application from SHA1 as the default PKCS#7 SignedData digest algorithm to stronger digests such as SHA256, in ways that preserve backwards compatibility for signature verifiers which do not support digest algorithms other than SHA1. I want to check my understanding of the PKCS#7 format and available options.

What think I want to do is digest message content with both SHA1 and SHA256 (or more generally, a set of digest algorithms) such that older applications can continue to verify via the SHA1, and upgraded applications can begin verifying via the SHA256 (more generally, the strongest digest provided), ignoring the weaker algorithm(s). [If there is a better approach, please let me know.]

It appears that within the PKCS#7 standard, the only way to provide multiple digests is to provide multiple SignerInfos, one for each digest algorithm. Unfortunately, this would seem to lead to a net decrease in security, as an attacker is able to strip all but the the SignerInfo with the weakest digest algorithm, which alone will still form a valid signature. Is this understanding correct?

If so, my idea was to use custom attributes within the authenticatedAttributes field of SignerInfo to provide additional message-digests for the additional digest algorithms (leaving SHA1 as the "default" algorithm for backwards compatibility). Since this field is authenticated as a single block, this would prevent the above attack. Does this seem like a viable approach? Is there a way to accomplish this or something similar without going outside of the PKCS standard?

Answer 1

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

signerInfo 中的 SignedAttributes 必须只包含一个 message-digest 属性的实例。类似地，AuthenticatedData 中的 AuthAttributes 必须只包含消息摘要属性的一个实例。

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

是的，任何安全系统都与其最薄弱的环节一样强大，所以理论上，如果您仍然接受 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 年应用一个新时间戳，并让新时间戳覆盖所有旧签名（包括旧时间戳）。这样，较弱的算法就会被更新、更强的时间戳签名所覆盖。查看基于 CMS 的CAdES（也存在RFC，但现在已经过时），并尝试应用这些策略来提供 CMS 签名的长期存档。