場(chǎng)景一

轉(zhuǎn)賬交易：

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

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

報(bào)文無加密和簽名機(jī)制

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

安全隱患

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

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

場(chǎng)景二

某商城A要接支付寶移動(dòng)支付，大致流程：

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

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

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

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

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

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

這是一個(gè)通知報(bào)文要做簽名的案例

需要注意的是，步驟2和3同樣需要做簽名驗(yàn)證

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

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

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

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

方案一 對(duì)稱加密簽名機(jī)制

具體方案：用一種對(duì)稱加密算法將報(bào)文加密，并得出一個(gè)簽名串

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

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

此方案達(dá)到的效果：

如果黑客截取報(bào)文，并篡改原文，那么服務(wù)端進(jìn)行驗(yàn)簽的時(shí)候，將不會(huì)通過。

因?yàn)樵淖兓耍愠龅暮灻畷?huì)改變，那么黑客需要重新計(jì)算出簽名串

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

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

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

方案二 對(duì)稱加密簽名，動(dòng)態(tài)密鑰

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

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

那么我們可以動(dòng)態(tài)生成簽名的密鑰，并用rsa公鑰對(duì)其進(jìn)行加密（此處rsa私鑰在服務(wù)端，不會(huì)泄密，因?yàn)楹灻荑€不會(huì)被解密），然后傳至服務(wù)端

次方案用于場(chǎng)景一，可以解決報(bào)文被篡改的問題。

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

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

方案三 報(bào)文加密（對(duì)稱加非對(duì)稱）

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

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

那么我們就采取對(duì)報(bào)文加密，可用方式是對(duì)稱加密和非對(duì)稱加密

1.對(duì)稱加密：3des

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

最終報(bào)文=3des密鑰2&簽名串

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

2.非對(duì)稱加密+對(duì)稱加密：3des+rsa+md5

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

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

最終報(bào)文=3des密鑰2|簽名串|rsarsa公鑰

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

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

我們需要用rsa來簽名

方案四 rsa簽名+https

報(bào)文加密是必須的，那么我們用https加密，其原理同非對(duì)稱加密+對(duì)稱加密

場(chǎng)景一方案：

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

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

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

最終持有情況如下：

客戶端：pubkey_s，priKey_c

服務(wù)端：pubKey_c，priKey_s

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

簽名串=rsapriKey_c

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

場(chǎng)景二，相對(duì)于場(chǎng)景二

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

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

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

服務(wù)端響應(yīng)報(bào)文時(shí)：

簽名串=rsapriKey_s

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

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

場(chǎng)景二方案：

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

簽名串=rsapriKey_s

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

客戶端用pubkey_s來驗(yàn)簽即可，可保證，報(bào)文不會(huì)被篡改，且來自真實(shí)合法的服務(wù)端