加密和簽名方案

場景一
轉帳交易：
假設我要作個轉帳的app叫支付寶，要完成轉帳的功能，轉帳時，須要輸入對方支付寶帳號和姓名，而後點擊轉帳，輸入支付密碼，就能夠完成轉帳的功能。
實現方式，客戶端經過http協議發送轉帳報文給服務端
報文無加密和簽名機制
如今用戶甲要轉帳給用戶乙。
安全隱患
網絡傳輸不安全，若是有人截取客戶端請求報文，進行篡改，好比篡改收款方的支付寶帳號和真實姓名，那麼服務端就會把錢轉到別的地方去。
結論：須要防止報文被篡改
場景二
某商城A要接支付寶移動支付，大體流程：

1. 客戶端app調用支付寶的sdk發送支付報文
2. 客戶端接收支付寶服務端的處理響應
3. 商戶服務端接收支付寶服務端的交易成功通知
   客戶端發送請求的安全隱患同場景一
   服務端接收通知時，存在以下隱患，黑客甲，去商城A
   人爲模擬支付寶的通知報文，將訂單變成成功。
   這是一個通知報文要作簽名的案例
   須要注意的是，步驟2和3一樣須要作簽名驗證
   結論：須要確認報文來自真實合法的服務端（其實在商戶對商戶的通訊過程當中，也須要確認報文來自真實合法的客戶端）

場景一和場景二的最終結論：

1. 安全網絡通訊過程當中，須要防止報文被篡改
2. 安全網絡通訊過程當中，須要客戶端和服務端雙方確認對方的身份，即交易完成後，不可抵賴

方案一 對稱加密簽名機制
具體方案：用一種對稱加密算法將報文加密，並得出一個簽名串
舉例：MD5加密簽名，簽名串=md5(原文&密鑰)（其餘對稱加密算法簽名道理是同樣的，不作詳述）
假設最終的報文是：最終報文=原文&簽名串
此方案達到的效果：
若是黑客截取報文，並篡改原文，那麼服務端進行驗籤的時候，將不會經過。
由於原文變化了，算出的簽名串會改變，那麼黑客須要從新計算出簽名串
要算出簽名串，須要知道以下要素
簽名算法（包含加密算法），原文，密鑰
前2個確定是會暴露的，沒法保密，而客戶端是app，密鑰也是暴露的，因此簽名串會被從新計算出來，所以黑客將成功篡改轉帳報文。
方案二 對稱加密簽名，動態密鑰
從方案一咱們得出一個結論：
簽名算法（包含加密算法），原文，密鑰三者只要保證其中一個不被黑客截取，將沒法算出簽名串，也就沒法篡改報文。
那麼咱們能夠動態生成簽名的密鑰，並用rsa公鑰對其進行加密（此處rsa私鑰在服務端，不會泄密，由於簽名密鑰不會被解密），而後傳至服務端
次方案用於場景一，能夠解決報文被篡改的問題。
可是服務端就沒法確認客戶端是否合法，尤爲在機構與機構通訊的時候，這個方案就更不可取。
且次方案不適合於方案2，支付寶服務端發通知的時候，總不能動態產生密鑰，這樣你就沒法斷定報文是不是支付寶服務端發送來的。
方案三 報文加密（對稱加非對稱）
從方案一咱們得出一個結論：
簽名算法（包含加密算法），原文，密鑰三者只要保證其中一個不被黑客截取，將沒法算出簽名串，也就沒法篡改報文。
那麼咱們就採起對報文加密，可用方式是對稱加密和非對稱加密
1.對稱加密：3des
簽名串=md5(原文&密鑰1)
最終報文=3des密鑰2&簽名串
傳輸過程當中，報文是加密的，沒法篡改（由於沒法拿到用戶關鍵信息，如session，tokenId等認證信息），看似沒有問題，可是密鑰1和密鑰2均可能泄密，並且3des會被解密掉，因此又回到方案一的結果。
2.非對稱加密+對稱加密：3des+rsa+md5
那麼咱們能夠從方案二吸收經驗，用rsa密鑰加密對稱加密密鑰
簽名串=md5(原文&密鑰1)
最終報文=3des密鑰2|簽名串|rsarsa公鑰
此方案仍然有方案二的缺陷，只能解決場景1，不能解決場景2
緣由在於簽名的密鑰，服務端和客戶端是同樣的，沒法產生惟一性身份
咱們須要用rsa來簽名

方案四 rsa簽名+https
報文加密是必須的，那麼咱們用https加密，其原理同非對稱加密+對稱加密
場景一方案：
客戶端產生一對公私鑰 pubKey_c，priKey_c
服務端產生一對公私鑰 pubkey_s，priKey_s
客戶端與服務端置換公鑰
最終持有狀況以下：
客戶端：pubkey_s，priKey_c
服務端：pubKey_c，priKey_s
客戶端發送報文：
簽名串=rsapriKey_c
最終報文=https(報文原文+簽名串);
場景二，相對於場景二
服務端用pubKey_c作驗籤，
產生效果：客戶端私鑰priKey_c沒有被盜取時，能夠防止報文被篡改，且服務端能夠確認信息來自合法的客戶端，在機構與機構通訊時，次種假設是成立的。
客戶端是app, 客戶端私鑰priKey_c會被盜取，不能保證客戶端的合法性（即客戶端能夠不是官方提供的），但仍然能夠防止報文被篡改。
服務端響應報文時：
簽名串=rsapriKey_s
最終報文=https(報文原文+簽名串);
產生效果：由於服務端的私鑰priKey_s在理論上是不會泄密的，因此能夠保證響應報文不會被篡改，且來自真實合法的服務端
場景二方案：
支付寶服務端發送報文：
簽名串=rsapriKey_s
最終報文=https(報文原文+簽名串);
客戶端用pubkey_s來驗籤便可，可保證，報文不會被篡改，且來自真實合法的服務端