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