移动支付，又称为手机支付，指交易双方在手机上使用移动网络通信实现的商业交易，它具有移动性、及时性、定制化和集成性的优点。截至 2021 年 6 月，我国网民规模达 10.11 亿，其中使用手机上网的比例为 99.6%。因此，移动支付目前已经成为主流的支付方式。
然而，随之而来的众多安全问题也引起了各部门的高度重视，而支付信息造假，被拦截和篡改是其中的主要问题之一。不法分子利用计算机系统漏洞、木马病毒、移动端虚假授权对支付信息进行破坏和获取，将真实的信息进行伪造或篡改，诱导用户进行错误交易的例子屡见不鲜。
针对以上问题，本文提出了一种移动支付报文的安全传输方案。该方案将对称加密算法与非对称加密算法相结合，让移动支付报文在传输过程中实现“一次一密”，端到端的防止非法分子对报文进行伪造和篡改，从而保证用户的资金安全。
1、相关概念
1.1 对称加密算法
指发送方的加密密钥与接收方的解密密钥为同一个密钥的加密算法，如图 1。常用的对称加密算法有 AES256,AES128,DES,3DES 等。
图1 对称加密算法示意图
1.2 非对称加密算法
指发送方使用公钥加密，接收方使用私钥解密的加密算法。其中，公钥与私钥一一对应，使用某公钥加密的密文，必须使用与其对应的私钥才能解密，如图 2。常用的对称加密算法有 RSA,ECC,DSA 等。
图2 非对称加密算法示意图
1.3 AndroidKeyStore
在安卓手机系统中，AndroidKeyStore 提供了基于硬件保护的密钥存储服务。其实现原理是:AndroidKeyStore 通过安卓系统框架中Library 层 的 KeyStore 服 务 向 手 机 的 TEE ( Trusted Execution Environment）独立模块请求密钥生成操作，并将密钥信息存储在 TEE环境内，从而达到利用硬件来保证密钥在存储过程中的安全性。其原理示意图如图 3。
图3 AndroidKeyStore 服务的原理示意图
1.4 KeyChain
KeyChain是苹果手机系统为用户和应用程序提供的用于存储敏感数据的安全容器，如 WiFi 密码，VPN 凭证等。其本质是一个SQLite 数据库，位于/private/var/keychains/目录下。KeyChain 中保存的数据都经过苹果手机系统级加密，且不存放在应用程序自有的Sandbox 中，即使对应用程序进行反编译也无法获取。因此，能够保障敏感数据的存储安全。其存储结构如图 4。
图4 KeyChain 的存储结构示意图
1.5 其他概念
加密机：加密机是通过国家商用密码主管部门鉴定并批准使用的国内自主开发的主机加密设备。
客户端：指在移动支付中，发起请求和接收响应的一方，如 APP、H5 前端页面等。
服务端：指在移动支付中，接收请求和返回响应的一方。
请求报文：指客户端向服务端发起的请求信息内容。
响应报文：指服务端向客户端返回的响应信息内容。
2、移动支付报文的安全传输方案
本方案采用对称加密算法与非对称加密算法相结合的方式对移动支付客户端与服务端之间的请求和响应报文进行加解密，实现“一次一密”，从而确保报文的双向安全传输。该方案主要包含以下四个组成部分。
2.1 请求报文的加解密
客户端对请求报文的加密过程是：首先随机生成一个对称密钥，随后使用该随机对称密钥对请求报文进行加密，最后在使用服务端的公钥对该随机对称密钥进行加密后，连同请求报文的密文一起发往服务端。详见算法 1。
算法 1. 请求报文的加密算法
输入：请求报文 ReqMsg;
输 出 ： 请 求 报 文 密 文 EncryReqMsg ； 随 机 对 称 密 钥 密 文EncryReqRandSymKey。
1. BEGIN
2. 生成加密请求报文的随机对称密钥 ReqRandSymKey;
3. 获取服务端公钥 ServerP ubKey;
4. EncryReqMsg=E{ReqRandSymKey, ReqMsg}；
5. EncryReqRandSymKey=E{ServerPubKey, ReqRandSymKey}；
6. END
其中，E{K,P}代表使用密钥 K 对数据 P 加密。
服务端对请求报文的解密过程是：首先使用服务端的私钥对随机对称密钥的密文进行解密，随后使用对称密钥的明文对请求报文的密文进行解密，最后使用请求报文的明文完成业务逻辑处理。详见算法 2。
算法 2. 请求报文的解密算法
输 入 ： 请 求 报 文 密 文 EncryReqMsg ； 随 机 对 称 密 钥 密 文EncryReqRandSymKey。
输出：请求报文明文 ReqMsg。
1. BEGIN
2. 生成服务端私钥 ServerP vtKey;
3.ReqRandSymKey=D{ServerPvtKey,EncryReqRandSymKey}；
4.ReqMsg=D{ReqRandSymKey,EncryReqMsg}；
5.END
其中，D{K,P}代表使用密钥K对数据P进行解密。
2.2响应报文的加解密
服务端对响应报文的加密过程是：首先随机生成一个对称密钥，随后使用该随机对称密钥对响应报文进行加密，最后在使用客户端的公钥对该随机对称密钥进行加密后，连同响应报文密文一起返回给客户端。详见算法 3。
算法3.响应报文的加密算法
输入：响应报文RspMsg;
输 出 ： 响 应 报 文 密 文 EncryRspMsg ； 随 机 对 称 密 钥 密 文EncryRspRandSymKey。
1. BEGIN
2.生成加密响应报文的随机对称密钥RspRandSymKey;
3.获取客户端公钥ClientPubKey;
4. EncryRspMsg=E{RspRandSymKey, RspMsg}；
5.EncryRspRandSymKey=E{ClientPubKey,RspRandSymKey}；
6.END
客户端对响应报文的解密过程是：首先使用客户端的私钥对随机对称密钥的密文进行解密，随后使用对称密钥的明文对响应报文的密文进行解密，最后使用响应报文的明文完成业务逻辑处理。详见算法4。
算法 4. 响应报文的解密算法
输 入 ： 响 应 报 文 密 文 EncryRspMsg ； 随 机 对 称 密 钥 密 文EncryRspRandSymKey。
输出：响应报文 RspMsg。
1. BEGIN
2. 生成客户端私钥 ClientPvtKey;
3.RspRandSymKey=D{ClientPvtKey,EncryRspRandSymKey}；
4.RspMsg=D{RspRandSymKey,EncryRspMsg}；
5. END
2.3 私钥的安全存取
在对移动支付报文的加解密过程中，私钥的保密性至关重要。因此，私钥的安全存取方案无论对于客户端还是服务端来说，都是重中之重。
对于客户端来说，私钥将基于手机系统的 AndroidKeyStore（安卓手机）或 KeyChain（苹果手机）服务进行安全存取；对于服务端来说，私钥将被严格封存在加密机中，即服务端的应用程序将无法触碰私钥，仅能进行输入请求密文和获取请求明文的操作。这些举措都将确保私钥不被暴露，任何非法的第三方都无法获知。
2.4 公私钥对的定期更新
为进一步提升本方案的安全性，还应对客户端和服务端的公私钥对分别进行定期更新。
对于客户端来说，按登录的会话生命周期进行更新，即一旦某次登录的会话有效期结束，则立即将当前使用的公私钥对置为失效，并重新生成公私钥对用于新的登录会话。
对于服务端来说，按客户端的版本生命周期进行更新，即每发布一个或几个新的版本，就为该新版本重新生成公私钥对。与此同时，为避免维护过多的公私钥对，对于用户数已较少的客户端旧版本，将其对应的公私钥对置为失效。
3、实现结果与分析
图5 第一笔支付密码校验的请求和响应报文
将本方案中的对称加密算法选择为 AES256，非对称加密算法选择为 RSA 进行实现后，随机抽取两笔支付密码校验的请求和响应报文如图 5 和图 6。
图6 第二笔支付密码校验的请求和响应报文
不难看出，这两笔随机交易的请求和响应报文都迥异，达到了移动支付报文双向传输“一次一密”的预期目标。
4、结语
针对移动支付信息被伪造或篡改后导致用户资金损失的问题，本文提出了一种移动支付报文的安全传输方案，将对称加密算法与非对称加密算法相结合，实现了报文在客户端和服务端之间“一次一密”的安全双向传输。为进一步提升和确保报文的不可抵赖性和完整性提供了借鉴和指导，后续将研究在本方案中引入数字签名技术的可行性。
