去年夏天，我正在開發一款應用程序，用於測試潛在客戶的計算機是否適合集成我們的硬件。其中一個建議是在某些情況下使用該工具生成的HTML報告作爲退款的理由。簽名和驗證自動生成的報告
我的直接反應是，「我們必須簽署這些報告來驗證其真實性。」我設想的解決方案涉及爲報告創建簽名，然後將其嵌入到元標記中。不幸的是，這種情況會要求應用程序簽署報告，這意味着它需要一個私鑰。一旦應用程序存儲私鑰，我們又回到了原來的位置，不保證真實性。
我的下一個主意是給家裏打電話並讓服務器在報告上簽名，但用戶需要互聯網連接才能測試硬件兼容性。此外，應用程序需要與服務器進行身份驗證，並且感興趣的一方可以找出它正在使用的憑據。
所以我的問題是這樣的。除了混淆之外，還有什麼方法可以驗證應用程序是否確實生成了給定的報告？
正如Eugene正確指出的，我最初的答案是驗證接收器。讓我提出另一種方法用於驗證發件人
驗證發件人：
當你的應用程序部署在客戶端，您生成並部署其持有私鑰自簽名PFX證書。
您的客戶端和密碼的PFX的細節是由您的客戶端設置，可以是你可以把它印在紙上追究他們，他們剛剛生成的密鑰負責通過客戶簽訂..
現在您有一個可以簽名的私鑰，並且在導出HTML報告時，您可以將證書與報告一起導出。
這是一個低成本的解決方案，並不像在Eugene的前一篇文章中指出的那樣在私鑰中保存私鑰。
驗證接收器：
有你的接收端的RSA 2048密鑰對。將您的公鑰導出到您的發件人。
當發件人生成報告時，讓報告由對稱密鑰AES 256加密。讓對稱密鑰本身由您的公鑰加密/包裝。
當您收到加密報告時，使用您的私鑰解開/解密對稱密鑰，然後用對稱密鑰解密加密報告。
通過這種方式，您可以確保只有預期的接收方纔能查看報告。
我想說，你需要重新評估可能的風險，並且很可能你會發現它們沒有你想象的那麼重要。原因是報告對你有價值，但對客戶的可能性較小。所以這或多或少是一個商業任務，而不是編程。
要回答你的具體問題，沒有簡單的方法來保護用於簽名的私鑰被盜（如果真的要的話）。對於更復雜的解決方案，使用內置私鑰的加密標記可以起作用，但cryptotoken本身就是一個硬件，在您的情況下，它會不必要地使計劃複雜化。
在這種情況下，您對客戶的價值（以及實際的安全風險）是有限的。因此，我並不十分擔心我們到達的解決方案：軟件的每個發佈版本都會隨機生成一個與之關聯的鹽。鹽被嵌入到客戶端應用程序中，並通過對醃製報告進行散列創建「簽名」。這很簡單，並且與使用嵌入式私鑰簽名一樣安全。我們認爲，如果有人想退款足夠糟糕，可以從應用程序中挖出鹽，那麼他們可以擁有它。 – jpm
該任務是驗證發件人，而不是接收者。 –
@Eugene，是的，你是對的。我誤解了這個帖子。我會編輯我的答案，留下我以前的答案，以便有人可以從中受益，如果他們正在尋找查詢的反向。 – Raj
這是一個很好的解決方案。出於某種原因，我只是假設整個簽名過程對用戶而言都是透明的。當然，現在我意識到，如果他們打算使用報告進行退款，那麼他們沒有理由不明確驗證它。 – jpm