場景一

轉(zhuǎn)賬交易：

假設(shè)我要做個轉(zhuǎn)賬的app叫支付寶，要完成轉(zhuǎn)賬的功能，轉(zhuǎn)賬時，需要輸入對方支付寶賬號和姓名，然后點擊轉(zhuǎn)賬，輸入支付密碼，就可以完成轉(zhuǎn)賬的功能。

實現(xiàn)方式，客戶端通過http協(xié)議發(fā)送轉(zhuǎn)賬報文給服務(wù)端

報文無加密和簽名機制

現(xiàn)在用戶甲要轉(zhuǎn)賬給用戶乙。

安全隱患

網(wǎng)絡(luò)傳輸不安全，如果有人截取客戶端請求報文，進行篡改，比如篡改收款方的支付寶賬號和真實姓名，那么服務(wù)端就會把錢轉(zhuǎn)到別的地方去。

結(jié)論：需要防止報文被篡改

場景二

某商城A要接支付寶移動支付，大致流程：

客戶端app調(diào)用支付寶的sdk發(fā)送支付報文

客戶端接收支付寶服務(wù)端的處理響應(yīng)

商戶服務(wù)端接收支付寶服務(wù)端的交易成功通知

客戶端發(fā)送請求的安全隱患同場景一

服務(wù)端接收通知時，存在如下隱患，黑客甲，去商城A

人為模擬支付寶的通知報文，將訂單變成成功。

這是一個通知報文要做簽名的案例

需要注意的是，步驟2和3同樣需要做簽名驗證

結(jié)論：需要確認報文來自真實合法的服務(wù)端（其實在商戶對商戶的通信過程中，也需要確認報文來自真實合法的客戶端）

場景一和場景二的最終結(jié)論

安全網(wǎng)絡(luò)通信過程中，需要防止報文被篡改

安全網(wǎng)絡(luò)通信過程中，需要客戶端和服務(wù)端雙方確認對方的身份，即交易完成后，不可抵賴

方案一 對稱加密簽名機制

具體方案：用一種對稱加密算法將報文加密，并得出一個簽名串

舉例：MD5加密簽名，簽名串=md5(原文&密鑰)（其他對稱加密算法簽名道理是一樣的，不做詳述）

假設(shè)最終的報文是：最終報文=原文&簽名串

此方案達到的效果：

如果黑客截取報文，并篡改原文，那么服務(wù)端進行驗簽的時候，將不會通過。

因為原文變化了，算出的簽名串會改變，那么黑客需要重新計算出簽名串

要算出簽名串，需要知道如下要素

簽名算法（包含加密算法），原文，密鑰

前2個肯定是會暴露的，無法保密，而客戶端是app，密鑰也是暴露的，所以簽名串會被重新計算出來，因此黑客將成功篡改轉(zhuǎn)賬報文。

方案二 對稱加密簽名，動態(tài)密鑰

從方案一我們得出一個結(jié)論：

簽名算法（包含加密算法），原文，密鑰三者只要保證其中一個不被黑客截取，將無法算出簽名串，也就無法篡改報文。

那么我們可以動態(tài)生成簽名的密鑰，并用rsa公鑰對其進行加密（此處rsa私鑰在服務(wù)端，不會泄密，因為簽名密鑰不會被解密），然后傳至服務(wù)端

次方案用于場景一，可以解決報文被篡改的問題。

但是服務(wù)端就無法確認客戶端是否合法，尤其在機構(gòu)與機構(gòu)通信的時候，這個方案就更不可取。

且次方案不適合于方案2，支付寶服務(wù)端發(fā)通知的時候，總不能動態(tài)產(chǎn)生密鑰，這樣你就無法判定報文是否是支付寶服務(wù)端發(fā)送來的。

方案三 報文加密（對稱加非對稱）

從方案一我們得出一個結(jié)論：

簽名算法（包含加密算法），原文，密鑰三者只要保證其中一個不被黑客截取，將無法算出簽名串，也就無法篡改報文。

那么我們就采取對報文加密，可用方式是對稱加密和非對稱加密

1.對稱加密：3des

簽名串=md5(原文&密鑰1)

最終報文=3des密鑰2&簽名串

傳輸過程中，報文是加密的，無法篡改（因為無法拿到用戶關(guān)鍵信息，如session，tokenId等認證信息），看似沒有問題，但是密鑰1和密鑰2都可能泄密，而且3des會被解密掉，所以又回到方案一的結(jié)果。

2.非對稱加密+對稱加密：3des+rsa+md5

那么我們可以從方案二吸取經(jīng)驗，用rsa密鑰加密對稱加密密鑰

簽名串=md5(原文&密鑰1)

最終報文=3des密鑰2|簽名串|rsarsa公鑰

此方案仍然有方案二的缺陷，只能解決場景1，不能解決場景2

原因在于簽名的密鑰，服務(wù)端和客戶端是一樣的，無法產(chǎn)生唯一性身份

我們需要用rsa來簽名

方案四 rsa簽名+https

報文加密是必須的，那么我們用https加密，其原理同非對稱加密+對稱加密

場景一方案：

客戶端產(chǎn)生一對公私鑰 pubKey_c，priKey_c

服務(wù)端產(chǎn)生一對公私鑰 pubkey_s，priKey_s

客戶端與服務(wù)端置換公鑰

最終持有情況如下：

客戶端：pubkey_s，priKey_c

服務(wù)端：pubKey_c，priKey_s

客戶端發(fā)送報文：

簽名串=rsapriKey_c

最終報文=https(報文原文+簽名串);

場景二，相對于場景二

服務(wù)端用pubKey_c做驗簽，

產(chǎn)生效果：客戶端私鑰priKey_c沒有被盜取時，可以防止報文被篡改，且服務(wù)端可以確認信息來自合法的客戶端，在機構(gòu)與機構(gòu)通信時，次種假設(shè)是成立的。

客戶端是app, 客戶端私鑰priKey_c會被盜取，不能保證客戶端的合法性（即客戶端可以不是官方提供的），但仍然可以防止報文被篡改。

服務(wù)端響應(yīng)報文時：

簽名串=rsapriKey_s

最終報文=https(報文原文+簽名串);

產(chǎn)生效果：因為服務(wù)端的私鑰priKey_s在理論上是不會泄密的，所以可以保證響應(yīng)報文不會被篡改，且來自真實合法的服務(wù)端

場景二方案：

支付寶服務(wù)端發(fā)送報文：

簽名串=rsapriKey_s

最終報文=https(報文原文+簽名串);

客戶端用pubkey_s來驗簽即可，可保證，報文不會被篡改，且來自真實合法的服務(wù)端