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

随着数字支付的普及，支付安全成为了我们不可忽视的重要议题。本文将深入探讨支付系统中的一个关键安全主题——防篡改与防抵赖，揭示为何支付平台必须实施签名验签机制，以及如何确保交易的安全性和真实性。

———— / BEGIN / ————

今天主要讲清楚支付系统中常见的安全主题之一：防篡改与防抵赖。包括为什么支付平台所有对外服务接口要做签名验签，哪些是安全的算法，哪些是不安全的算法，以及对应的核心代码实现。

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

1. 什么是签名验签

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

3. 哪些是安全的算法，哪些是不安全的算法

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

5. 联调中常见的问题

在电子支付的万亿级市场中，安全无疑是核心中的核心。安全是一个很庞大的领域，“签名与验签”是安全领域里面一个重要的分支。那什么是签名验签呢？

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

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

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

假设被签名的数据（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）为例，示例代码如下：

}

签名输出是字节码，还需要编码，一般使用base64。

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

}

这里data已经是加了API密钥（也称为API KEY）。所谓的API密钥，就是交易双方共享的一个密钥，这样双方生成的哈希值才会一致。

联调中常见的问题

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

• 密钥不匹配：双方以为自己都配置了正确的密钥，但实际没有。

• 数据编码不一致：比如一方使用GBK，一方使用UTF-8。

• 原始数据选择不一致：比如接口文档要求拼接10个字段，但是代码实现却只拼接了9个字段。或者一方没有把空值放入计算，另一方把空值也放入计算。

• 原始数据排序方式不一致：比如接口要求按key的升序排列，调用方却忘记排序就进行签名。

• 字符转义不一致：特殊字段的转义必须保持一致。

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

结束语

主要讲了支付安全领域内的签名验签名相关内容，包括重要性，原理，常见算法及核心JAVA代码实现。

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

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

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

作者：隐墨星辰

来源微信公众号：隐墨星辰

品牌推广｜ 内容撰写｜广告投放｜培训合作