廣東
隨著數字支付的普及，支付安全成為了我們不可忽視的重要議題。本文將深入探討支付系統中的一個關鍵安全主題——防篡改與防抵賴，揭示為何支付平臺必須實施簽名驗簽機制，以及如何確保交易的安全性和真實性。
———— / BEGIN / ————
今天主要講清楚支付系統中常見的安全主題之一：防篡改與防抵賴。包括為什么支付平臺所有對外服務接口要做簽名驗簽，哪些是安全的算法，哪些是不安全的算法，以及對應的核心代碼實現。
通過這篇文章，你可以了解到：
什么是簽名驗簽
支付系統為什么一定要做簽名驗簽
哪些是安全的算法，哪些是不安全的算法
常見簽名驗簽算法核心代碼
聯調中常見的問題
什么是數字簽名驗簽
在電子支付的萬億級市場中，安全無疑是核心中的核心。安全是一個很龐大的領域，“簽名與驗簽”是安全領域里面一個重要的分支。那什么是簽名驗簽呢？
簽名驗簽是數字加密領域的兩個基本概念。
簽名：發送者將數據通過特定算法和密鑰轉換成一串唯一的密文串，也稱之為數字簽名，和報文信息一起發給接收方。
驗簽：接收者根據接收的數據、數字簽名進行驗證，確認數據的完整性，以證明數據未被篡改，且確實來自聲稱的發送方。如果驗簽成功，就可以確信數據是完好且合法的。
假設被簽名的數據（m），簽名串（Σ），散列函數（H），私鑰（Pr），公鑰（Pu），加密算法（S），解密算法（S^），判斷相等（eq）。
簡化后的數學公式如下：
簽名：Σ=S[H(m), Pr]。
驗簽：f(v)=[H(m) eq S^(Σ, Pu)]。
流程如下：
簽名流程：
散列消息：對消息(m)應用散列函數（H）生成散列值（h）。
加密散列值：使用發送方的私鑰 ( Pr ) 對散列值 ( h ) 進行加密，生成簽名 ( Σ )。Σ = S(h, Pr)
把數字簽名（Σ）和原始消息（m）一起發給接收方。
驗簽流程：
散列收到的消息：使用同樣的散列函數 ( H ) 對消息 ( m ) 生成散列值 ( h’ )，也就是：h’ = H(m)。
解密簽名：使用發送方的公鑰 ( Pu ) 對簽名 (Σ ) 進行解密，得到散列值 ( h )，也就是：h = S^(Σ, Pu)。
比較散列值：比較解密得到的散列值 ( h ) 與直接對消息 ( m ) 散列得到的 ( h’ ) 是否一致。驗證成功條件：h = h’ 。
如果兩個散列值相等，那么驗簽成功，消息（m)被認為是完整沒有被篡改，且確實來自聲稱的發送方。如果不一致，就是驗簽失敗，消息可能被篡改，或者簽名是偽造的。
現實中的算法會復雜非常多，比如RSA，ECDSA等，還涉及到填充方案，隨機數生成，數據編碼等。
支付系統為什么一定要做簽名驗簽
銀行怎么判斷扣款請求是從確定的支付平臺發出來的，且數據沒有被篡改？商戶不承認發送過某筆交易怎么辦？簽名驗簽技術專門解密類似的問題。
簽名驗簽主要解決3個問題：
1）身份驗證：確認支付信息是由真正的發送方發出，防止冒名頂替。
如果無法做身份驗證，支付寶就無法知道針對你的賬戶扣款99塊的請求是真實由你樓下小賣部發出去的，還是我冒充去扣的款。
2）完整性校驗：確認支付信息在傳輸過程中未被篡改，每一筆交易都是完整、準確的。
如果無法校驗完整性，那么我在公共場景安裝一個免費WIFI，然后截獲你的微信轉賬請求，把接收者修改成我的賬號，再轉發給微信，微信就有可能會把錢轉到我的賬號里。
3）防抵賴性：避免任何一方否認曾經進行過的交易，提供法律證據支持。
比如微信支付調用銀行扣款100塊，銀行返回成功，商戶也給用戶發貨了，幾天后銀行說這筆扣款成功的消息不是他們返回的，他們沒有扣款。而簽名驗簽就能讓銀行無法抵賴。
流程：
雙方先交換密鑰，可以通過線下郵件交換，也可以通過線上自助平臺交換。
請求方發出交易報文前使用自己的私鑰進行簽名，接收方接收報文后先進行驗簽，驗簽通過后再進行業務處理。
接收方處理完業務，返回前使用自己的私鑰進行簽名，請求方接收返回報文后先進行驗簽，驗簽通過后再進行業務處理。
安全簽名驗簽算法推薦
安全一直是一個相對的概念，很多曾經是安全的算法，隨著計算機技術的發展，已經不安全了，以后到了量子計算的時代，現在大部分的算法都將不再安全。
一般而言，安全同時取決于算法和密鑰長度。比如SHA-256就比MD5更安全，RSA-2048就比RSA-1024更安全。
已經被認為不安全的算法有MD5、SHA-1等算法，容易受到碰撞攻擊，不應該在支付系統中使用。
仍然被認為是安全的算法有：SHA-256，SHA-3， RSA-1024，RSA-2048，ECDSA等。
當前最常見推薦的算法是RSA-2048。RSA-1024以前使用得多，但因為密鑰長度較短，也已經不再推薦使用。
SHA-256和MD5一樣，只是一種單純的散列算法，其實是不適合做簽名驗簽算法的，因為需要雙方共用相同取值的密鑰，一旦泄露，無法確認是被哪方泄露，也就是只解決了完整性校驗，無法解決身份驗證和防抵賴性。但因為使用簡單，國內外仍然有不少的支付公司在大量使用。
常見簽名驗簽算法核心代碼
下面以RSA（SHA256withRSA）為例，示例代碼如下：
}簽名輸出是字節碼，還需要編碼，一般使用base64。
如果使用SHA-256（很多公司仍在使用，但不推薦），如下：
}這里data已經是加了API密鑰（也稱為API KEY）。所謂的API密鑰，就是交易雙方共享的一個密鑰，這樣雙方生成的哈希值才會一致。
聯調中常見的問題
不管是與商戶的聯調，還是與支付渠道（或銀行）之間的聯調，簽名驗簽都是非常耗費精力的環節。驗簽不通過通常有以下幾個情況：
密鑰不匹配：雙方以為自己都配置了正確的密鑰，但實際沒有。
數據編碼不一致：比如一方使用GBK，一方使用UTF-8。
原始數據選擇不一致：比如接口文檔要求拼接10個字段，但是代碼實現卻只拼接了9個字段。或者一方沒有把空值放入計算，另一方把空值也放入計算。
原始數據排序方式不一致：比如接口要求按key的升序排列，調用方卻忘記排序就進行簽名。
字符轉義不一致：特殊字段的轉義必須保持一致。
解決上述問題的最好辦法，就是讓服務提供方提供一段示例代碼，以及示例報文+示例簽名，然后在本地使用main方法先跑成功，再移植到項目代碼中。
結束語
主要講了支付安全領域內的簽名驗簽名相關內容，包括重要性，原理，常見算法及核心JAVA代碼實現。
但是還有一個同樣非常重要的問題沒有講：如何安全儲存密鑰？如果密鑰放在代碼里或數據庫里，開發人員是可以直接獲得的，如果不小心泄露出去怎么辦？
應對的解決方案就是創建一個密鑰中心專門負責密鑰的管理，無論加密解密還是簽名驗簽，全部調用密鑰中心來處理，業務系統不接觸密鑰明文。
那又來了一個新的問題：這個密鑰中心如何設計和實現，才能既保證很高的安全性，又能有非常高的性能表現呢？后面有時間再單獨聊聊。
作者：隱墨星辰
來源微信公眾號：隱墨星辰
品牌推廣｜ 內容撰寫｜廣告投放｜培訓合作
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
