支付平台架构：终端安全技术实现

前蚂蚁集团宣布即将IPO之后，9月11日晚间，以金融支付起家的京东数科也要上市了。近年来，第三方支付业务的资金规模不断扩大，支付业务量稳步增长，“第三方支付”及“移动支付”已成为年度搜索热词，支付平台作为互联网产品及其在商业化过程中信息流和资金流的支撑，也成为国外内各大互联网公司必建的基础平台之一。

安全交易是互联网产品电子商务发展的核心内容之一，支付系统的安全则是安全交易的关键所在。

对于从事支付行业的第三方支付机构来说，终端数据的安全防护无疑是支付业务发展的重要保证之一，是安全防护长城的第一关。支付系统一般会采用安全加密、访问授权、传输安全等方法来保障终端数据的安全。

---

本文选自《支付平台架构：业务、规划、设计与实现》一书，将详细介绍支付平台终端安全的技术实现。

终端安全技术实现

首先讲解在本地加密存储的方法，加密方法有两种：对称加解密和非对称加解密。

实用场景：支付系统中有部分配置文件的内容需要加密存储在本地，例如：跳转服务器的地址或支付SDK的运行参数在使用过程中需要先解密再使用。对于这种场景，比较适合采用对称加密算法。 当然，也可以使用非对称加密。但由于非对称加密适用于安全级别较高、运算速度较慢及私钥一般不在终端存储等场景中，所以在技术选型上面不宜使用。

说到对称加密算法，可以选择使用以下几种方案。
这里的终端安全示例代码以Android操作系统为例，并且使用Java来实现安全加密、访问授权和传输安全。

一、中低安全级别的数据（DES）

数据加密标准DES（Data Encryption Standard）是使用对称密钥加密的一种块加密算法，处理数据的速度较快，性能较好，通常适用于对大块数据加解密的场景中。

该算法的明显缺点是密钥较短，这意味着可以通过暴力破解来解密，降低了加密的安全性，但仍然适用于对支付系统配置文件的安全加密等场景中。

以下是基于Android系统的DES加密的代码实现： 对应的解密函数如下：

这样就实现了加解密函数，只需在加密时调用encryptByDES函数，将明文数据和8位Key传入就可以得到密文数据，然后在使用时以相同的Key值和密文调用decryptByDES函数完成密文解密得到明文信息。

在以上代码中还使用了Base64编码方式，可以将二进制数据编码成可见的ASCII码字符串数据。在Android系统中Base64（完整类名为android.util.Base64）已经是一种内置的工具类的编码转换算法，很多人都把Base64当成一个加解密算法，但从严格意义上来说，它不能算是一种加解密算法，只能算是一种编码格式的转换算法。

二、DES算法演进之3DES

在DES基础之上进化了三重数据加密算法（3DES），该算法使用了K1、K2、K3对同一组明文进行多重加密，其基本原理是对每个数据块都使用三次DES加密，如果密钥小于64位，则其加密强度与DES一致，一般建议采用的密钥超过64位。

3DES的加密函数示例如下：

其中涉及的加密编码方式和填充方式包括3DES-ECB、3DES-CBC、3DES-CTR、3DES-OFB和3DES-CFB。

解密函数示例如下：

其中三重数据加密算法的密钥长度是128位。除了3DES算法，还有人演算出N-DES（N重数据加密算法）。

高安全级别的数据（AES）

由于密钥长度过短、弱密钥等缺点的存在，DES容易被暴力破解。随着计算机性能不断提升，DES被暴力破解的频率越来越高。所以，美国国家标准与技术研究院（NIST）在1997年放弃了对DES的官方支持，研发出DES的替代者AES（Advanced Encryption Standard，高级加密标准）。

在Android系统上使用AES与使用DES的实现难度、代码量和写法相差无几，比DES速度更快、性能更高，在实际的开发过程中建议采用AES算法对数据进行加解密，其加密代码如下： 解密代码如下：

针对对称加解密算法都有一个密钥需要存储的问题，目前有三种实现方案。

（1）生成密钥之后，可以将其保存在存储设备中，例如密钥文件或Android系统的SharedPreferences中，在使用时将其读取到内存中。

（2）生成密钥之后，依据固定的设备特性（例如DeviceId、OSID等）将密钥信息上送到服务器端，在应用启动时将密钥信息获取到本地使用，由于移动网络通信存在不确定性，所以不推荐采用这种方案。

（3）将密钥放在 NDK 代码中，然后采用数据位移或拆分等方案，再拼装为真正的密钥数据。这种算法的破解难度较高，也较安全，推荐采用这种存储方案。

非对称加密（RSA）

RSA是一种非对称加密算法，由三位数学家Rivest、Shamir和Adleman设计，其核心思想为将密钥分成以下两把密钥，简称密钥对。

在密钥对中有一个公钥，还有一个私钥。

• 公钥（Public Key）

  是密钥对中完全公开的部分，任何人都可以得到它，适用于客户端-服务端模型。

• 私钥（Private Key）

  是密钥对中保密的一部分，一般在服务端安全存储，不允许在客户端存储。

可以使用OpenSSL工具的命令生成公私钥，也可以使用开发语言生成公私钥。
（1）生成RSA算法的私钥时，使用以下命令：openssl genrsa -out rsa_private_key.pem 2048

（2）使用以下命令将X509编码文件转换成PKCS8编码格式：openssl pkcs8 -in rsa_private_key.pem -out rsa_private_key_pkcs8.pem -nocrypt -topk8

（3）导出私钥对应的X509编码公钥文件：openssl rsa -in rsa_private_key.pem -out rsa_public_key.pem -pubout

注意 ——

可以使用Java代码从rsa_private_key_pkcs8.pem文件中读取私钥信息并生成数字签名，再使用rsa_public_key.pem公钥文件验证数字签名的正确性。

Java虚拟机也提供了内置的方法来生成公私钥，代码如下：

有了公私钥数据之后，就可以对数据进行加解密处理和数据加签、验签了，加解密过程如下。 其中，加密数据的一方使用公开获得的公钥（一般推荐使用1024位密钥，密钥越长越安全，也意味着加密性能越差），对明文数据进行加密得到密文： （2）解密的一方具有私钥，拿到密文时，使用对应的私钥进行解密：

（3）如果解密失败，则代表公钥或私钥不匹配（不是一个密钥对），这也说明如果没有对应的私钥，则解不出密文中的内容。

RSA 一般只适用于小数据块的加解密场景中（例如加密动态密钥、短的关键数据），加解密速度较AES和DES慢。

传输安全

数据的传输安全需要满足以下条件。

防窥探 数据明文受到保护，不应该被黑客和恶意用户识别、利用。保护数据不被窥探是一项重要的指标，发送者和接收者双方都需要实现加密技术，保证数据无法被第三方破解和解密。

防篡改 保护数据在传输过程中的完整性，必须确认不会在数据传输过程中被截获和篡改。

防伪造 能识别数据发送方是否具有合法性，并且能确认发送方的真实性。下面讲解相应的技术实现方案。

▊1、防窥探

数据一般通过计算机网络进行传输，除了有从一个发送方（发送节点）发送到接收方（接收节点）的简单场景，还有复杂的场景（经过N个网络节点传输才能到达最终目的地）。随着节点的增多，在这个传输过程中被截获、监听的风险越来越高。

（例如：现在常用的网络数据抓包软件就有Fiddler、Wireshark等，可以监听到网络层都采用了什么协议、调用了哪些API，以及发送参数、返回的响应数据分别是什么。）

在客户端一般采用公开的通道加密方案保证通道数据无法被窥探。

TLS（Transport Layer Security）又叫作安全传输层协议，主要用于在两个通信应用程序之间提供保密性和数据完整性。

Android系统对应的实现如下。

首先，读取自己的证书并初始化TLS的工厂类： 然后，获取Socket工厂类，创建Socket连接，开始TLS握手：

▊ 2、防篡改

在某支付场景中，客户端与服务端的请求被黑客截获并将支付订单的金额修改为0.1元（原订单金额10元），由于未在这个过程中对订单数据进行防篡改校验，导致了商户的商品被便宜卖掉，造成了商户的经济损失。

数据防篡改的主要手段是针对数据进行客户端加签，在服务端接收数据时验证加签数据是否与签名一致。加签的过程实质上是发送端针对待发送的原始数据进行一定的处理（例如字符串去空格、字段排序、数据加密）后针对数据加签生成签名摘要数据，这部分摘要数据一般不会参与加密。接收端在收到数据之后，先将签名摘要数据和加密数据取出来，然后解密已加密的数据块得到原始数据，最后像发送端一样进行处理，生成签名摘要数据。如果生成的摘要数据与发送端传送过来的一致，则表示数据没被篡改过，否则表示数据在传输过程中被篡改。

下面讲解对防篡改的数据进行签名和验签的过程。

（1）对原始数据去空格，进行参数字段排序（升序或降序）和拼接。

（2）将原始数据（待签名内容）根据参数字段名称进行排序，可以保证加签、验签的双方待验证参数内容的一致性。例如：排序升序规则按照第一个字符的ASCII码值递增排序，如果遇到相同的字符，则依据第2个字符排递增序，以此类推。将排序后的参数拼接成“参数=参数值”的格式，并且把这些参数使用“&”字符连接起来。 （3）生成摘要数据，常用的摘要算法有MD5、SHA-1等。下面使用MD5生成摘要数据：

（4）使用非对称加密算法RSA，利用客户端的公钥对摘要值进行加密，将数据通过网络发送给接收方进行验证。

接收方在接收到数据之后进行验签，与加签的过程基本一致。

（1）参数排序。将收到的参数内容（key=value字典）根据参数名称进行排序，其排序规则与签名方保持一致，对参数字符串去空格和拼接，其拼接方式与签名方保持一致，生成待生成摘要的原参数字符串。

（2）生成摘要数据。使用相同的摘要算法（MD5）计算得到验签方的摘要值。

（3）进行非对称解密。使用RSA非对称加密算法，对收到的加密摘要数据使用私钥进行解密，并得到签名方的原始摘要值。

（4）摘要数据对比。如果签名方的摘要数值等于验签方计算出来的摘要值，则表示验签成功，否则验签失败。

（完）

相关图书

《支付平台架构：业务、规划、设计与实现》
曹兵强 著

移动支付虽已普及，但其高门槛另使绝大多数技术人员没机会深入了解支付平台的架构和设计技巧。

《支付平台架构：业务、规划、设计与实现》一书梳理支付平台的各个业务和技术细节，讲解支付架构原理和技术实现。既有支付领域端到端的全链路设计思路，也有关键技术方案的实现细节和经验总结。是一本国内少见且非常具有参考价值的好书。

▊作者简介

曹兵强

毕业于华南师范大学，阿里巴巴技术专家。

现担任阿里互娱支付平台客户端技术负责人，曾任职于阿里巴巴集团移动事业群、天猫精灵人工智能实验室、互动娱乐事业部等部门。曾在金融行业和电信行业从事支付结算信息系统研发和技术管理多年，负责融合支付、预付卡支付、交易反欺诈和风控安全等工作，拥有“支付安全处理方法、装置及系统”“用户终端及支付方式检测装置与方法”“防自动刷红包的装置与方法及服务端”等多篇支付相关的国内外专利提案。