場景一
轉賬交易:
假設我要做個轉賬的app叫支付寶,要完成轉賬的功能,轉賬時,需要輸入對方支付寶賬號和姓名,然后點擊轉賬,輸入支付密碼,就可以完成轉賬的功能。
實現方式,客戶端通過http協議發送轉賬報文給服務端
報文無加密和簽名機制
現在用戶甲要轉賬給用戶乙。
安全隱患
網絡傳輸不安全,如果有人截取客戶端請求報文,進行篡改,比如篡改收款方的支付寶賬號和真實姓名,那么服務端就會把錢轉到別的地方去。
結論:需要防止報文被篡改
場景二
某商城A要接支付寶移動支付,大致流程:
客戶端app調用支付寶的sdk發送支付報文
客戶端接收支付寶服務端的處理響應
商戶服務端接收支付寶服務端的交易成功通知
客戶端發送請求的安全隱患同場景一
服務端接收通知時,存在如下隱患,黑客甲,去商城A
人為模擬支付寶的通知報文,將訂單變成成功。
這是一個通知報文要做簽名的案例
需要注意的是,步驟2和3同樣需要做簽名驗證
結論:需要確認報文來自真實合法的服務端(其實在商戶對商戶的通信過程中,也需要確認報文來自真實合法的客戶端)
場景一和場景二的最終結論
安全網絡通信過程中,需要防止報文被篡改
安全網絡通信過程中,需要客戶端和服務端雙方確認對方的身份,即交易完成后,不可抵賴
方案一 對稱加密簽名機制
具體方案:用一種對稱加密算法將報文加密,并得出一個簽名串
舉例: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來驗簽即可,可保證,報文不會被篡改,且來自真實合法的服務端
-
APP
+關注
關注
33文章
1573瀏覽量
72446 -
支付寶
+關注
關注
2文章
457瀏覽量
24843 -
區塊鏈
+關注
關注
111文章
15562瀏覽量
105933
發布評論請先 登錄
相關推薦
評論