中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

隨著數字支付的普及，支付安全成為了我們不可忽視的重要議題。本文將深入探討支付系統中的一個關鍵安全主題——防篡改與防抵賴，揭示為何支付平臺必須實施簽名驗簽機制，以及如何確保交易的安全性和真實性。

今天主要講清楚支付系統中常見的安全主題之一：防篡改與防抵賴。包括為什么支付平臺所有對外服務接口要做簽名驗簽，哪些是安全的算法，哪些是不安全的算法，以及對應的核心代碼實現。

通過這篇文章，你可以了解到：

1. 什么是簽名驗簽
2. 支付系統為什么一定要做簽名驗簽
3. 哪些是安全的算法，哪些是不安全的算法
4. 常見簽名驗簽算法核心代碼
5. 聯調中常見的問題

一、什么是數字簽名驗簽

在電子支付的萬億級市場中，安全無疑是核心中的核心。安全是一個很龐大的領域，“簽名與驗簽”是安全領域里面一個重要的分支。那什么是簽名驗簽呢？

簽名驗簽是數字加密領域的兩個基本概念。

1. 簽名：發送者將數據通過特定算法和密鑰轉換成一串唯一的密文串，也稱之為數字簽名，和報文信息一起發給接收方。
2. 驗簽：接收者根據接收的數據、數字簽名進行驗證，確認數據的完整性，以證明數據未被篡改，且確實來自聲稱的發送方。如果驗簽成功，就可以確信數據是完好且合法的。

假設被簽名的數據（m），簽名串（Σ），散列函數（H），私鑰（Pr），公鑰（Pu），加密算法（S），解密算法（S^），判斷相等（eq）。

簡化后的數學公式如下：

簽名：Σ=S[H(m), Pr]。

驗簽：f(v)=[H(m) eq S^(Σ, Pu)]。

流程如下：

簽名流程：

1. 散列消息：對消息(m)應用散列函數（H）生成散列值（h）。
2. 加密散列值：使用發送方的私鑰 ( Pr ) 對散列值 ( h ) 進行加密，生成簽名 ( Σ )。Σ = S(h, Pr)

把數字簽名（Σ）和原始消息（m）一起發給接收方。

驗簽流程：

1. 散列收到的消息：使用同樣的散列函數 ( H ) 對消息 ( m ) 生成散列值 ( h’ )，也就是：h’ = H(m)。
2. 解密簽名：使用發送方的公鑰 ( Pu ) 對簽名 (Σ ) 進行解密，得到散列值 ( h )，也就是：h = S^(Σ, Pu)。
3. 比較散列值：比較解密得到的散列值 ( h ) 與直接對消息 ( m ) 散列得到的 ( h’ ) 是否一致。驗證成功條件：h = h’ 。

如果兩個散列值相等，那么驗簽成功，消息（m)被認為是完整沒有被篡改，且確實來自聲稱的發送方。如果不一致，就是驗簽失敗，消息可能被篡改，或者簽名是偽造的。

現實中的算法會復雜非常多，比如RSA，ECDSA等，還涉及到填充方案，隨機數生成，數據編碼等。

二、支付系統為什么一定要做簽名驗簽

銀行怎么判斷扣款請求是從確定的支付平臺發出來的，且數據沒有被篡改？商戶不承認發送過某筆交易怎么辦？簽名驗簽技術專門解密類似的問題。

簽名驗簽主要解決3個問題：

1）身份驗證：確認支付信息是由真正的發送方發出，防止冒名頂替。

如果無法做身份驗證，支付寶就無法知道針對你的賬戶扣款99塊的請求是真實由你樓下小賣部發出去的，還是我冒充去扣的款。

2）完整性校驗：確認支付信息在傳輸過程中未被篡改，每一筆交易都是完整、準確的。

如果無法校驗完整性，那么我在公共場景安裝一個免費WIFI，然后截獲你的微信轉賬請求，把接收者修改成我的賬號，再轉發給微信，微信就有可能會把錢轉到我的賬號里。

3）防抵賴性：避免任何一方否認曾經進行過的交易，提供法律證據支持。

比如微信支付調用銀行扣款100塊，銀行返回成功，商戶也給用戶發貨了，幾天后銀行說這筆扣款成功的消息不是他們返回的，他們沒有扣款。而簽名驗簽就能讓銀行無法抵賴。

流程：

1. 雙方先交換密鑰，可以通過線下郵件交換，也可以通過線上自助平臺交換。
2. 請求方發出交易報文前使用自己的私鑰進行簽名，接收方接收報文后先進行驗簽，驗簽通過后再進行業務處理。
3. 接收方處理完業務，返回前使用自己的私鑰進行簽名，請求方接收返回報文后先進行驗簽，驗簽通過后再進行業務處理。

三、安全簽名驗簽算法推薦

安全一直是一個相對的概念，很多曾經是安全的算法，隨著計算機技術的發展，已經不安全了，以后到了量子計算的時代，現在大部分的算法都將不再安全。

一般而言，安全同時取決于算法和密鑰長度。比如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）為例，示例代碼如下：

import java.security.KeyFactory;

import java.security.PrivateKey;

import java.security.PublicKey;

import java.security.Signature;

import java.security.spec.PKCS8EncodedKeySpec;

import java.security.spec.X509EncodedKeySpec;

public class RSASignatureUtil {

   // 使用私鑰對數據進行簽名

   public static byte[] sign(byte[] data, byte[] privateKey) throws Exception {

       PKCS8EncodedKeySpec pkcs8KeySpec = new PKCS8EncodedKeySpec(privateKey);

       KeyFactory keyFactory = KeyFactory.getInstance("RSA");

       PrivateKey priKey = keyFactory.generatePrivate(pkcs8KeySpec);

       Signature signature = Signature.getInstance("SHA256withRSA");

       signature.initSign(priKey);

       signature.update(data);

       return signature.sign();

   }

   // 使用公鑰驗證簽名

   public static boolean verify(byte[] data, byte[] publicKey, byte[] signatureBytes) throws Exception {

       X509EncodedKeySpec keySpec = new X509EncodedKeySpec(publicKey);

       KeyFactory keyFactory = KeyFactory.getInstance("RSA");

       PublicKey pubKey = keyFactory.generatePublic(keySpec);

       Signature signature = Signature.getInstance("SHA256withRSA");

       signature.initVerify(pubKey);

       signature.update(data);

       return signature.verify(signatureBytes);

   }

}

簽名輸出是字節碼，還需要編碼，一般使用base64。

如果使用SHA-256（很多公司仍在使用，但不推薦），如下：

import java.security.MessageDigest;

public class SHA256Util {

   // 使用SHA-256對數據進行散列

   public static byte[] hash(byte[] data) throws Exception {

       MessageDigest digest = MessageDigest.getInstance("SHA-256");

       return digest.digest(data);

   }

}

這里data已經是加了API密鑰（也稱為API KEY）。所謂的API密鑰，就是交易雙方共享的一個密鑰，這樣雙方生成的哈希值才會一致。

五、聯調中常見的問題

不管是與商戶的聯調，還是與支付渠道（或銀行）之間的聯調，簽名驗簽都是非常耗費精力的環節。驗簽不通過通常有以下幾個情況：

1. 密鑰不匹配：雙方以為自己都配置了正確的密鑰，但實際沒有。
2. 數據編碼不一致：比如一方使用GBK，一方使用UTF-8。
3. 原始數據選擇不一致：比如接口文檔要求拼接10個字段，但是代碼實現卻只拼接了9個字段。或者一方沒有把空值放入計算，另一方把空值也放入計算。
4. 原始數據排序方式不一致：比如接口要求按key的升序排列，調用方卻忘記排序就進行簽名。
5. 字符轉義不一致：特殊字段的轉義必須保持一致。

解決上述問題的最好辦法，就是讓服務提供方提供一段示例代碼，以及示例報文+示例簽名，然后在本地使用main方法先跑成功，再移植到項目代碼中。

六、結束語

主要講了支付安全領域內的簽名驗簽名相關內容，包括重要性，原理，常見算法及核心JAVA代碼實現。

但是還有一個同樣非常重要的問題沒有講：如何安全儲存密鑰？如果密鑰放在代碼里或數據庫里，開發人員是可以直接獲得的，如果不小心泄露出去怎么辦？

應對的解決方案就是創建一個密鑰中心專門負責密鑰的管理，無論加密解密還是簽名驗簽，全部調用密鑰中心來處理，業務系統不接觸密鑰明文。

那又來了一個新的問題：這個密鑰中心如何設計和實現，才能既保證很高的安全性，又能有非常高的性能表現呢？后面有時間再單獨聊聊。