揭密支付安全：为什么你的交易无法被篡改

这是《百图解码支付系统设计与实现》专栏系列文章中的第（4）篇。也是支付安全系列的第（1）篇。

本文主要讲清楚支付系统中为什么要做签名验签，哪些是安全的算法，哪些是不安全的算法，以及对应的核心代码实现。

通过这篇文章，你可以了解到：

1. 什么是签名验签
2. 支付系统为什么一定要做签名验签
3. 哪些是安全的算法，哪些是不安全的算法
4. 常见签名验签算法核心代码
5. 联调中常见的问题

1. 什么是签名验签

在电子支付的万亿市场中，安全无疑是核心中的核心。有一种称之为“签名验签”的技术在支付安全领域发挥着至关重要的作用。那什么是签名验签呢？

签名验签是数字加密领域的两个基本概念。

签名：发送者将数据通过特定算法和密钥转换成一串唯一的密文串，也称之为数字签名，和报文信息一起发给接收方。

验签：接收者根据接收的数据、数字签名进行验证，确认数据的完整性，以证明数据未被篡改，且确实来自声称的发送方。如果验签成功，就可以确信数据是完好且合法的。

假设被签名的数据（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等，还涉及到填充方案，随机数生成，数据编码等。

2. 支付系统为什么一定要做签名验签

银行怎么判断扣款请求是从确定的支付平台发出来的，且数据没有被篡改？商户不承认发送过某笔交易怎么办？这都是签名验签技术的功劳。

签名验签主要解决3个问题：

1. 身份验证：确认支付信息是由真正的发送方发出，防止冒名顶替。

如果无法做身份验证，支付宝就无法知道针对你的账户扣款99块的请求是真实由你楼下小卖部发出去的，还是我冒充去扣的款。

1. 完整性校验：确认支付信息在传输过程中未被篡改，每一笔交易都是完整、准确的。

如果无法校验完整性，那么我在公共场景安装一个免费WIFI，然后截获你的微信转账请求，把接收者修改成我的账号，再转发给微信，微信就有可能会把钱转到我的账号里。

1. 防抵赖性：避免任何一方否则曾经进行过的交易，提供法律证据支持。

比如微信支付调用银行扣款100块，银行返回成功，商户也给用户发货了，几天后银行说这笔扣款成功的消息不是他们返回的，他们没有扣款。而签名验签就能让银行无法抵赖。

流程：

1. 双方先交换密钥，可以通过线下邮件交换，也可以通过线上自助平台交换。
2. 请求方发出交易报文前使用自己的私钥进行签名，接收方接收报文后先进行验签，验签通过后再进行业务处理。
3. 接收方处理完业务，返回前使用自己的私钥进行签名，请求方接收返回报文后先进行验签，验签通过后再进行业务处理。

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只是一种单纯的散列算法，其实是不适合做签名验签算法的，因为需要双方共用一个API密钥，一旦泄露，无法确认是哪方被泄露，也就是只解决了完整性校验，无法解决身份验证和防抵赖性。但因为使用简单，国内外仍然有不少的支付公司公司在大量使用。

4. 常见签名验签算法核心代码

下面以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密钥，就是交易双方共享的一个密钥，这样双方生成的哈希值才会一致。

5. 联调中常见的问题

不管是与商户的联调，还是与支付渠道（或银行）之间的联调，签名验签都是非常耗费精力的环节。验签不通过通常有以下几个情况：

1. 密钥不匹配：双方以为自己都配置了正确的密钥，但实际没有。
2. 数据编码不一致：比如一方使用GBK，一方使用UTF-8。
3. 原始数据选择不一致：比如接口文档要求拼接10个字段，但是代码实现却只拼接了9个字段。或者一方没有把空值放入计算，另一方把空值也放入计算。
4. 原始数据排序方式不一致：比如接口要求按key的升序排列，调用方却忘记排序就进行签名。
5. 字符转义不一致：特殊字段的转义必须保持一致。

解决上述问题的最好办法，就是让服务提供方提供一段示例代码，以及示例报文+示例签名，然后在本地使用main方法先跑成功，再移植到项目代码中。

6. 结束语

本章主要讲了签名验签名的概念，对于支付系统的重要性，以及常见签名验签名算法及JAVA代码实现。

但是还有一个同样非常重要的问题没有讲：如何安全储存密钥？如果密钥放在代码里或数据库里，开发人员是可以直接获得的，如果不小心泄露出去怎么办？

应对的解决方案就是创建一个密钥中心专门负责密钥的管理，无论加密解密还是签名验签，全部调用密钥中心来处理，业务系统不接触密钥明文。

那又来了一个新的问题：这个密钥中心如何设计和实现，才能既保证很高的安全性，又能有非常高的性能表现呢？

后面有机会再开一个密钥中心的设计和实现专题来聊。

7. 传送门

支付系统设计与实现是一个专业性非常强的领域，里面涉及到的很多设计思路和理论也可以应用到其它行业的软件设计中，比如幂等性，加解密，领域设计思想，状态机设计等。

在《百图解码支付系统设计与实现》的知识宇宙，每一篇深入浅出的文章都是一颗既独立但又彼此强关联的星球，有必要提供一个传送门以便让大家即刻到达想要了解的文章。

专栏地址：百图解码支付系统设计与实现

领域相关：

基本概念与概要设计：跟着图走，学支付：在线支付系统设计的图解教程

收单结算设计：支付交易的三重奏：收单、结算与拒付在支付系统中的协奏曲

技术专题：

与数据库自增ID不同的业务ID：交易流水号的艺术：掌握支付系统的业务ID生成指南

签名验签：揭密支付安全：为什么你的交易无法被篡改

加密解密：金融密语：揭秘支付系统的加解密艺术

日志格式设计规范：支付系统日志设计完全指南：构建高效监控和问题排查体系的关键基石

幂等性设计：避免重复扣款：分布式支付系统的幂等性原理与实践