PKCS＃7 SignedData和多个摘要算法

Question

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

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

似乎在PKCS＃7标准中，提供多个摘要的唯一方法是提供多个SignerInfos，每个摘要算法一个。不幸的是，这看起来会导致安全性下降，因为攻击者能够用最薄弱的摘要算法去除除SignerInfo之外的所有信息，而这个算法本身仍然会形成有效的签名。这种理解是否正确？

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

Answer 1

是的，你是对的，在目前的CMS RFC它说，有关该消息的摘要属性，它

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

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

是的，任何安全系统都与其最薄弱的环节一样强大，因此从理论上说，如果您仍然接受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签名提供长期归档。