我希望實現一些有效的（即具有良好的性能）邏輯，以便在我們的Web應用程序中進行有效負載簽名。目標是讓 HTML5 客戶端保證接收到的有效負載的內容確實是由我們的后端生成的內容。我們不想使用共享鹽進行有效負載哈希生成，因為用戶可以輕松打開HTML5源代碼并找到鹽短語。我們現在已經實現了 RSA 簽名，其中后端使用其私鑰添加有效負載簽名，我們的 HTML5 客戶端使用其內置的公鑰對其進行驗證。但是，簽名生成過程需要 250 毫秒（對于相對較小的有效負載），并且由于簽名請求的性質，此時間量是不可接受的。唯一的另一個想法是在運行時生成一個共享密鑰，每次客戶端初始化其與后端的會話時。然而，這個秘密不能以明文形式發送，所以看起來我們將不得不實現一個Diffie-Hellman交換機制，如果可能的話，我們希望避免這種情況，或者使用現有庫自動化。請記住，由于我們銷售產品的方式的性質，保密和加密需要在應用程序層完成。我們不希望加密我們的流量，這是我們的客戶可能會或可能不會實現的東西（因為它是一個 Intranet 應用程序）。但是，我們必須避免向他們公開與我們的許可檢查機制等相關的內容。后端不是基于云的，也不由我們控制，而是安裝在客戶的本地計算機上。前端是爪哇腳本，后端是爪哇。
2 回答
慕標琳琳
TA貢獻1830條經驗 獲得超9個贊
請注意，Diffie-Hellman 交換機制不受 MITM 攻擊的保護，因此不加密流量意味著您需要對來自服務器的 DH 數據進行身份驗證。這就是為什么使用基于DH的密碼套件的Web服務器使用其服務器證書的私鑰對通過網絡發送的DH元素進行簽名的原因，以便客戶端檢查這些元素是否確實來自他要連接到的服務器。這些元素是公開的，但需要簽名。
您所說的“具有共享鹽的有效負載哈希生成”是一個鍵控哈希消息身份驗證代碼，因此它基于共享密鑰，正如您所注意到的，并且由于您不想使用此機制，這意味著您不信任客戶端。因此，您必須使用非對稱加密對有效負載進行簽名。
使用非對稱算法對服務器有效負載進行簽名意味著您首先需要讓服務器與客戶端共享公鑰。由于您不加密客戶端和服務器之間的數據，因此您需要在客戶端源代碼中部署服務器公鑰。
您談到了簽名生成過程，但是客戶端上的簽名檢查過程在您的情況下也非常重要，因為用戶等待結果的總時間是添加簽名時間和檢查簽名的時間（而且，簽名通?？梢栽诜掌魃项A測， 如果要簽名的數據不是動態生成的，但永遠無法預料到驗證）。因此，您需要一種快速檢查客戶端簽名的方法。首先，對哈希值進行簽名，而不是對整個有效負載進行簽名。然后選擇客戶端開發環境中可用的最快非對稱簽名算法。請注意，檢查 RSA 簽名比檢查 DSA 或 ECDSA 簽名更快，因為相應的密鑰長度對應于相同的安全級別。所以你應該留在RSA。
直到這條線之前，所有這些可能不會對您有太大幫助！現在有一種方法可以使用RSA來簽名和驗證簽名來提高性能，這種方式與SSL / TLS在從同一服務器下載多個頁面或其他對象時實現以提高瀏覽器性能的方式完全相同：使用會話緩存。您與一個特定用戶共享特定會話的公共密鑰。切勿將此常見機密用于其他會話。當用戶首次連接時，僅使用 RSA 一次，以交換臨時共享機密或交換 DH 材料以創建此共享機密。然后，每次服務器需要對對象進行簽名時，它都會使用此特定密鑰創建一個鍵控哈希消息身份驗證代碼。因此，如果用戶找到該機密，例如使用瀏覽器的調試模式，則這不是問題：此機密僅用于幫助他知道來自服務器的內容未被更改。因此，用戶不能使用此密鑰來更改服務器與其他用戶之間的數據交換。
添加回答
舉報
0/150
提交
取消