PKI 数字签名的替代方案答案

【问题标题】：Alternative to PKI digital signaturePKI 数字签名的替代方案
【发布时间】：2013-04-24 21:01:18
【问题描述】：

我正在寻找一种以实现以下目标的方式转换 xml 文档的方法：

它可以通过 Internet 分发到已知应用程序并由它们管理，而无需任何特殊的存储要求
应用程序可以确定文档的来源
应用程序可以确定它在生成后是否被篡改或更改
文档已加密，但出于混淆目的而不是因为它包含敏感信息
应用程序可以通过编程方式读取 xml 的内容

这听起来像是一个经典的数字签名场景。但是，我不希望源和接收应用程序必须处理与管理公钥和私钥相关的后勤问题。

那么，我的问题是：有没有什么方法可以在不使用数字证书的情况下可靠地满足这些要求？

【问题讨论】：

如果不面对密钥管理，您就无法获得真正的安全性。您必须交换一些密钥材料，无论是某种对称算法的预共享密钥，还是 PKI 系统中认证机构的公钥。

标签： encryption digital-signature pki

【解决方案1】：

如果您并不真正寻求安全性 - 尤其是在伪造/更改方面，嵌入在应用程序中的秘密对称密钥就足以满足更改检测和加密方面的要求。只需使用标准分组密码和 MAC (Message Authentication Code (wikipedia))。当然，提取密钥并更改这些文档会相对简单。

不幸的是，识别来源有点棘手。当您使用 PKI 时，身份隐含地出现，因为每个私钥都隐含地标识一个实体。由于您没有这样的自然标识符，您现在需要定义自己的标识方案：可能是您在运行它的机器上看到的第一个网络适配器的 MAC 地址，或者可能是您显式分配标识的更复杂的方案个人应用程序或使用该应用程序的个人。一旦你有了某种身份定义，在加密/签名操作之前将这个标识字符串添加到文档的开头作为一个单独的 XML 字段将是一件简单的事情。

【讨论】：

感谢@vhallac 的一些有用的指点，正是我所需要的。经过反思，在我的场景中识别消息的来源并不重要。最重要的因素是能够检测到原始文档是否已被更改。
据我了解，源应用程序和收件人应用程序都将共享一个密钥来加密/解密文档。为了让恶意用户篡改文档而不使其变得毫无意义，他们需要获取密钥、解密文档、更改文档并使用相同的密钥重新加密。那将是这种方法的主要漏洞吗？
@PaulTaylor 另一个问题是，如果对称密钥从某些应用程序中泄漏，您将不得不替换/更新您对密钥进行硬编码的所有应用程序。使用 PKI，这是不同的 - 在签名的情况下，您需要验证证书的有效性，这几乎是自动化的过程，如果证书在签名方面被替换，您不需要替换所有验证者。
@PaulTaylor 你是对的。您可以尝试相同方法的变体，但最终，系统的实际安全性将归结为隐藏在应用程序中的秘密，除非您让应用程序的用户以密码的形式提供部分秘密.但是，让它为具有不同密码的多个用户工作可能是不可行的。使用 PKI 可能会更好。
@EugeneMayevski'EldoSCorp 你说得很好。我应该在回答中提到它。

【解决方案2】：

对于身份验证，您需要有一些密钥方案来确保此身份验证。如果您特别不喜欢证书，另一种方法是使用 XML 的 OpenPGP 密钥（XMLDSig 支持 OpenPGP 密钥）。

【讨论】：

【解决方案3】：

[披露：我为 ARX 的 CoSign 工作]

但是，我不希望源应用程序和接收者应用程序必须处理与管理公钥和私钥相关的后勤问题。

另一种放牧猫的方法是使用 PKI，但通过使用集中式 SSCD (Secure Signature Creation Device) 来最大限度地减少常见的 PKI 后勤问题。

将它与自动生成已在收件人机器的信任链中的证书的能力相结合。 CoSign 和其他人这样做。

收件人可以轻松验证生成的数字签名 XML 文件的身份/真实性和完整性，同时最大限度地减少签署 XML 文件的管理负担。

【讨论】：

这也很有帮助，谢谢@Larry K，我会研究一下。但是，即使这样在我正在考虑的场景中也可能不可行，因为它需要足够的权限才能访问服务器证书存储。
Re：访问服务器证书存储的足够权限 -- 在签名机器上还是在收件人/验证机器上？
两者都有，但特别是收件人。