去年夏天，我正在开发一个应用程序，用于测试潜在客户的计算机是否适合集成我们的硬件。建议的概念之一是使用该工具生成的 HTML 报告作为在某些情况下退款的理由。
我的第一反应是，“我们必须签署这些报告以验证其真实性。” 我设想的解决方案包括为报告创建签名，然后将其嵌入到元标记中。不幸的是，这种情况需要应用程序签署报告，这意味着它需要一个私钥。一旦应用程序存储了私钥，我们又回到了第一阶段，无法保证真实性。
我的下一个想法是打电话回家并让服务器签署报告，但随后用户需要互联网连接来测试硬件兼容性。另外，应用程序需要通过服务器进行身份验证，感兴趣的一方可以弄清楚它使用什么凭据来执行此操作。
所以我的问题是这个。除了混淆之外，有什么方法可以验证应用程序确实生成了给定的报告？
正如尤金正确指出的那样，我最初的答案是对接收者进行身份验证。让我提出一种替代方法来验证发件人
验证发件人：
当您的应用程序部署在您的客户端时，您会生成并部署一个包含私钥的自签名 PFX 证书。
您的客户的详细信息和 PFX 的密码由您的客户设置，您可能可以让您的客户打印并在纸上签名，让他们对他们刚刚生成的密钥负责。
现在您有一个可以签名的私钥，并且在导出 HTML 报告时，您可以将证书与报告一起导出。
这是一种低成本的解决方案，并且不如上一篇文章中 Eugene 所指出的将您的私钥放在加密令牌中那样安全。
验证接收者：
在接收端有一个 RSA 2048 密钥对。将您的公钥导出给您的发件人。
当发件人生成报告后，让报告通过对称密钥加密，比如 AES 256。让对称密钥本身由您的公钥加密/包装。
当您收到加密报告时，使用您的私钥解包/解密对称密钥，然后使用对称密钥解密加密报告。
这样，您可以确保只有预期的接收者可以查看报告。
我想说你需要重新评估可能的风险，你很可能会发现它们并不像你想象的那么重要。原因是该报告对您有价值，但对客户却不太可能。所以它或多或少是一项业务任务，而不是编程任务。
要回答您的具体问题，没有简单的方法可以保护用于签名的私钥不被盗（如果真的想要的话）。对于更复杂的解决方案，使用内部存储有私钥的加密令牌可以工作，但加密令牌本身就是一种硬件，在您的场景中，它会使方案不必要地复杂化。