签署并验证自动生成的报告
去年夏天，我正在开发一个应用程序，用于测试潜在客户的计算机是否适合集成我们的硬件。建议的想法之一是使用该工具生成的 HTML 报告作为在某些情况下退款的理由。
我的第一反应是：“好吧，我们必须签署这些报告以验证其真实性。”我设想的解决方案涉及为报告创建签名，然后将其嵌入元标记中。不幸的是，这种情况需要应用程序签署报告，这意味着它需要私钥。一旦应用程序存储了私钥，我们就回到了第一步，无法保证真实性。
我的下一个想法是打电话回家并让服务器签署报告，但随后用户需要互联网连接来测试硬件兼容性。另外，应用程序需要通过服务器进行身份验证，感兴趣的一方可以弄清楚它使用什么凭据来执行此操作。
所以我的问题是这样的。除了混淆之外，还有什么方法可以验证应用程序确实生成了给定的报告吗？
Last summer, I was working on an application that tested the suitability of a prospective customer's computer for integrating our hardware. One of the notions suggested was to use the HTML report generated by the tool as justification for a refund in certain situations.
My immediate reaction was, "well we have to sign these reports to verify their authenticity." The solution I envisioned involved creating a signature for the report, then embedding it in a meta tag. Unfortunately, this scenario would require the application to sign the report, which means it would need a private key. Once the application is storing the private key, we're back at square one with no guarantee of authenticity.
My next idea was to phone home and have a server sign the report, but then the user needs an internet connection just to test hardware compatibility. Plus, the application would need to authenticate with the server, and an interested party could figure out what credentials it was using to do that.
So my question is this. Is there any way, outside of obfuscation, to verify that the application did indeed generate a given report?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如尤金正确指出的那样，我最初的答案是验证接收者的身份。让我提出一种验证发件人身份的替代方法
当您的应用程序部署在客户端时，您将生成并部署一个保存私钥的自签名 PFX 证书。
您的客户详细信息和 PFX 密码由您的客户设置，您可以将其打印出来并由您的客户在纸上签名，以让他们对刚刚生成的密钥负责。
现在您有了私钥可以签名，导出 HTML 报告时，可以将证书随报告一起导出。
这是一种低成本的解决方案，并且不如将私钥放在加密令牌中那么安全，正如尤金在上一篇文章中指出的那样。
在接收端拥有 RSA 2048 密钥对。将您的公钥导出给发件人。
当发送者生成报告后，让报告由对称密钥（例如 AES 256）加密。让对称密钥本身由您的公钥加密/包装。
当您收到加密报告时，使用您的私钥解包/解密对称密钥，然后再使用对称密钥解密加密报告。
这样，您可以确保只有目标接收者才能查看报告。
As Eugene has rightly pointed that my initial answer was to authenticate the receiver. Let me propose an alternative approach for authenticating the sender
When your application is deployed at your client end, you generate and deploy a self signed PFX certificate which holds the private key.
The details of your client and passphrase for the PFX is set by your client and may be you can get it printed and signed by your client in paper to hold them accountable for the keys which they have just generated..
Now you have a private key which can sign and when exporting the HTML report, you can export the certificate along with the report.
This is a low cost solution and is not as secure as having your private keys in a cryptotoken, as indicated by Eugene, in the previous post.
Have a RSA 2048 key pair at your receiving end. Export your public key to your senders.
When the sender has generated the report, let the report be encrypted by a symmetric key say AES 256. Let the symmetric key itself be encrypted/wrapped by your public key.
When you receive the encrypted report,use your private key to unwrap/decrypt the symmetric key and in turn decrypt the encrypted report with the symmetric key.
This way, you make sure that only the intended receiver alone can view the report.
我想说，你需要重新评估可能的风险，很可能你会发现它们并不像你想象的那么重要。原因是该报告对您有价值，但对客户而言不太有价值。所以这或多或少是一项业务任务，而不是编程任务。
为了回答您的具体问题，没有简单的方法可以保护用于签名的私钥不被窃取（如果确实愿意的话）。对于更复杂的解决方案，使用内部存储私钥的加密令牌是可行的，但加密令牌本身就是一个硬件，在您的场景中，它会不必要地使方案复杂化。
I'd say that you need to re-evaluate possible risks and most likely you will find them to be not as important as you could think. The reason is that the report has value for you but less likely for a customer. So it's more or less a business task, not a programming one.
To answer your concrete question, there's no simple way to protect the private key used for signing from being stolen (if one really wants to). For more complex solutions employing a cryptotoken with private key stored inside would work, but cryptotoken is itself a hardware and in your scenario it would unnecessarily complicate the scheme.