当前移动支付在国内已经得到了广泛的普及，其中又以二维码支付技术的应用最为常见,然而作为收款码，静态二维码很容易被篡改或替换，从而使商家蒙受较大损失，通过移动终端与支付平台进行的移动支付也存在数据被窃取的风险。为此，本文围绕TOTP算法设计了一种动态二维码移动云支付系统，保证了移动支付交易过程的完整性、可认证性、时效性、唯一性和不可伪造性。
1、总体设计
1.1 总体架构
该系统由云支付平台和与其连接的多台移动设备组成，平台与设备之间通过REST接口进行通信。系统共包括3个结构层：访问层、服务层和资源层，其总体架构如图1所示。
图1 移动云支付系统总体架构
访问层主要负责用户与系统的信息交互，其中包括PC浏览器、智能POS机、手机App等。
服务层作为系统的核心主要负责云支付功能的实现，为系统提供基础支撑服务和核心业务服务。其中，基础支撑部分主要包括加解密、密钥管理、认证鉴权、日志、通信、签名等服务，核心业务部分主要包括交易订单、商户信息、用户信息、风险评估、移动支付等服务。
资源层中部署的关系型数据库用于存储交易相关数据，主要包括每次交易的商品信息、出售商品的商户信息、购买商品客户的支付信息、用户账户信息等移动支付相关信息。数据缓存方式为Redis分布式缓存。
1.2 系统功能设计
(1) 动态支付
基于动态二维码的动态支付是移动云支付系统的核心功能，在交易过程中生成支付密钥来保证支付的安全进行，具体来说就是需要同时通过商家提供的订单信息和客户提供的支付密钥，并在得到云端的认证后才能完成支付。具体交易流程如图2所示。
图2 基于移动云支付的交易流程
交易流程中包含2个重要环节。
① 生成支付二维码。
根据用户的支付请求实时生成一种动态二维码并在生成后的60 s完成一次二维码更新，直至支付完成，每个客户在当前交易过程中收到的二维码都是当前系统中唯一的。
② 认证支付密钥。
在系统接收到商家的订单以及客户的支付密钥之后会立即开始基于时间的认证。首先需要确定支付密钥尚在有效期之内，接下来采用TOTP算法生成一个6位的动态口令，再将该口令与时间戮合成一个字符串并利用哈希算法SHA-256将其转换为动态支付密钥。系统通过该密钥和商家订单的密钥串与时间戮对客户提交的支付密钥进行验证，二者相同即可完成交易。
(2) 风险评估程序
商家提交收款请求后系统会启动风险评估程序。该过程主要是针对客户的个人信息、消费习惯、消费地点、消费时间、消费水平进行个人支付安全性评估，主要目的是验证当前交易是否与客户的日常消费习惯相符。具体评估流程如图3所示。
图3 系统风险评估流程
风险评估是基于自定义规则匹配与朴素贝叶斯算法的结合进行的，从当次交易多方面属性的样本数据中进行特征值提取，并据此对客户的消费行为进行分类。如果系统认定不符合客户的消费习惯则会要求客户再一次进行身份认证，如果相符则开始进行规则匹配。在此过程中，自定义规则主要匹配客户的支付金额、消费时间段与地点等。
(3) 认证鉴权
系统的认证鉴权功能分2个部分进行设计，即统一认证和统一鉴权。
统一认证是指客户登录系统所需的身份认证。为了解决传统的用户名、密码登录模式的安全隐患问题，系统设计时加入了人脸识别、声纹、指纹、短信等认证方式。
统一鉴权是指客户保持在线状态并进行操作的有效性鉴定。不同于传统Web站点的Session模式，本文系统采用了适用于移动设备的Token模式进行鉴权。
认证鉴权的实现过程如下。
步骤1 移动客户端要求用户输入手机号码以向其发送登录验证码。
步骤2 系统随机生成6位验证码，通过手机通信平台发送给请求登录的用户。
步骤3 用户在客户端输入接收到的验证码并申请登录。
步骤4 系统接收到用户反馈的验证码后，对用户的登录习惯(时间、地点等)进行检测。
步骤5 若用户的登录时间、地点与其日常登录的时间、地点不符，则会通过客户端界面提示用户输入密码以进一步确认身份认证。
步骤6 用户身份验证获得通过后系统生成一个与用户相对应的Token并将其发送给支付用户的客户端。
步骤7 用户成功登录客户端后的其所有操作都需要在附带Token的条件下进行，系统持续对Token进行验证以保证其登录身份的有效性。
步骤8 用户离线或更换登录设备后，之前系统为其提供的Token立即失效。
(4) 数据通信
为了保证商家、用户所持的移动客户端与系统支付平台之间的数据传输，系统内部集成了通信模块。数据采用HTTP协议进行传输，以JSON为传输载体并在传输过程中对所有重要数据采取加密措施，带有JSON数字签名的数据将以完整、机密、不可更改的状态在系统中进行传输。
系统利用AES对交易数据进行加密，加密数据的共享密钥再由RSA进行加密，对于每一个未完成的交易系统都为其提供一个唯一存在的密钥，AES共享密钥则存储于系统云端中。交易过程中的加密流程如下。
步骤1 系统生成一个16位的数字key。
步骤2 系统通过RSA将之前生成的key加密，得到AESkey。
步骤3 系统利用AES算法对重要数据进行加密。
步骤4 客户端从JSON数据中提取出AESkey, 再通过RSA对AESkey进行解密，得到key。
步骤5 客户端利用AES算法解密加密过的数据。
2、系统的实现
2.1 动态支付功能的实现
当交易过程进行到支付环节时，消费用户的移动客户端通过OKHttp提交向商户用户支付款项请求，再请求的合法性得到验证后，系统会从数据库的sequence中提取出交易序列号并结合当前时间共同生成商家订单号和用户的16位密钥，同时将密钥与相应的时间戮保存在数据库中并发送给客户端。
动态密钥的生成流程如图4所示。客户端得到系统的反馈后通过随机密钥和本地密钥生成新密钥K,然后运用TOTP算法获取一个6位的动态口令。接下来利用哈希函数将新生成的动态口令与时间戮结合在一起生成无法逆向推算的支付密钥。最后客户端通过Zxing根据支付密钥和订单号生成支付二维码，为了保证支付过程的安全进行，该二维码每60 s更新一次。
图4 动态密钥的生成流程
系统在接收到客户端反馈的交易信息后找到相应的订单，依据支付密钥的生成规则生成相应的密钥并将其与客户的支付密钥进行对比，若二者相同则同意支付并从客户账户中扣除相应的金额，若二者不同则拒绝继续支付并在交易日志中保存当次交易信息。
2.2 风险评估功能的实现
该功能基于SciKitlearn实现，该工具软件能够对数据进行挖掘与分析，集成了降维、回归、聚类等多种相关算法。
移动云支付系统基于支付金额、支付时间、支付商品数量、收款商户名、支付地点5个维度的特征数据来训练支付模型，从而对整个交易过程进行风险评估。
当用户提出交易请求时，系统自动提取特征数据，采用朴素贝叶斯算法完成模型的训练，最后对当次交易进行风险评估。系统对客户的消费行为进行判定，若判定为正常则进行规则匹配，否则要求用户输入支付密码以进行身份确认。
2.3 认证鉴权功能的实现
短信认证的流程中，系统随机生成一个6位的口令，利用Celery任务发布模块将新口令以短信的形式发送给用户，同时将其发送到Redis缓存中并为其设置一个过期时间。
移动客户端所返回的数据中包含用户手机号、验证码和有效时间三个属性。其中，手机号码用于系统生成提供给用户的key, 短信验证码则作为Value。买房用户提出支付请求后系统会从Redis中提取向该用户发出的验证码并与用户输入的验证码进行对比，在二者相同的情况下将用户的ID转换成附加了其身份信息的Token ID(令牌值)。以上过程总结如下。
(1) 在完整的JWT信息中，头部header的type指的是JWT的类型，exp表示申请交易的时间，alg则是说明以HS256的方式进行加密。
(2) 将时间戮和user_id添加到JWT的消息体playload中。
(3) 采用Base64分别对header和playload进行编码，将得到的字符串用“.”进行连接，再运行HMAC-SHA-256算法完成数据的加密操作，再利用Base64编码加密数据，从而得到已经签名的字符串。
(4) 用“.”将上述3种编码后的字符串连接，构建一个header.playload.sign形式的Token。
(5) Token的校验。以“.”为分隔标记将长字符串分解为header、playload和sign 3个独立的字符串，再将header和playload 2个字符串组合为新字符串，运行HMAC-SHA-256算法，结合密钥对该字符串进行加密，再与sign字符串进行对比，若二者一致则从header中提取时间信息验证有效期，在有效期内返回user_id值，如果已超时则要求用户重新登录。
用户通过短信认证通过系统验证后，系统会向其发送2个Token。
(1) 短期证书Token, 用户在客户端进行各种操作时所附带的有效身份信息。
(2) 长期证书Refresh Token, 在短期Token失效后系统所提供的新的Token身份信息，不能用于用户的操作请求。
两种Token的有效期不同，用户退出登录后2种Token都将被系统删除，一旦Token过期失效则用户必须通过Refresh Token来申请新的Token。
3、系统核心算法设计
3.1 TOTP算法
TOTP算法以时间为动态因素，是一次性密码算法HMAC的一种扩展算法。其计算表达式为
式中，K为1个Base32编码的字符串，C为时间戮，且：
式中，T为交易的时间戮，T0为起始时间，具体取值为0,X为更新时间间隔，通常情况下系统默认值为60 s。
HMAC-SHA-1是1种由SHA1哈希函数衍生而来的新算法，在计算的过程中HMAC整合了消息数据与密钥，最后通过计算输出长度为160位的字符串。
Truncate函数的构造过程如下。
(1) 采用HMAC-SHA-1算法将时间戮C与密钥字符串K加密，得到一个新的字符串，长度20字节。
(2) 从新字符串最后一个字节中提取出最低的4位字符，并以其为截取密钥字符串的下标偏移量。
(3) 从截取到的下标偏移量开始定位4个字节的字符串，利用大端的方式构建一个整数。
(4) 将该整数的后6位数字转换成字符串并返回。
TOTP算法下的动态口令生成与认证过程：采用TOTP算法生成的密钥字符串K中含有静态密钥串key1与动态密钥串key2,其中key1是客户端和系统的共享密钥，key2则是系统在运用相关算法后生成并交易发生时发送给移动设备中的客户端；基于TOTP算法，系统随机生成1个6位的动态口令，将其与时间戮整合并利用SHA-256算法生成动态支付密钥。
3.2 风险评估算法
系统对于整个交易过程的风险评估基于朴素贝叶斯算法进行。算法表达式为
式中，C代表类别；X代表待分类项。式(3)的求解方法如下。
(1) 创建待分类项集合C={a1,a2,…,am},am代表一种特征属性。
(2) 创建类别集合C={Y1,Y2,…,Ym}。
(3) 对P(Y1X),P(Y2X),…,P(YnX)逐项进行计算。
(4) 若P(YkX)=Max{P(Y1X),P(Y2X),…,P(YnX)}成立，则X可归类到Yk类中。
风险评估的具体流程如图5所示，系统基于五个维度的特征属性进行风险评估，设定支付时间为T,支付地点为L,支付金额为M,商户名称为S,商品名称为L,则待分类想集合为X={T,L,M,S,L}。将X代入式(3)后该计算式转换为
式(4)的计算结果为
将P(Y|X)的正常值P(Yes)与异常值P(No)进行比较，若P(Yes)>P(No),则判定为正常支付。
图5 系统风险评估流程
4、系统测试与分析
4.1 测试环境
本次系统测试以CVM云服务器为移动云支付系统的核心平台。系统网络中的HTTPS和反向代理服务由Nginx提供，在此环境下Python将具有更强的信号转换能力，在缓冲效应被减弱后末端负载也会相应大幅减小。Python应用服务器采用Gunicorn, 使同步和异步工作模式能够按需自由切换。系统数据使用MySQL服务器进行存储，采用Redis为缓存服务器。此外，由RabbitMQ进行消息队列处理，由Celery进行分布式任务队列处理。
将移动支付App安装在2部手机中，一部由商家使用，另一部由购物客户使用。客户完成商品选择，商家扫描条形码生成订单，客户在App中打开系统为其生成的动态支付二维码，提交订单的商家扫描该二维码收款，从而完成当前订单的支付。系统每60 s进行一次动态支付二维码的更新。
4.2 系统测试
移动云支付系统的测试分为风险评估功能测试与系统运行性能测试两个部分进行。测试过程中基于朴素贝叶斯算法完成风险评估测试的项目训练，检测买方用户的支付行为并为其进行自定义规则匹配；利用智能测试工具来获取系统的性能指标，本次测试主要检测系统在大量用户同时进行操作情况下的运行性能，主要指标包括平均响应时间、平均流量、单位时间内请求处理数量、错误率等。
选取2名用户的完整交易数据分别作为用于训练或测试的黑样本和白样本，通过人工评定为样本添加标签Label(正常样本为0,异常样本为1),从600个样本数据中选取150个异常样本，其余均为正常样本，部分样本信息如表1所示。
表1 风险评估测试部分样本信息
采用SciKitlearn工具中集成的GaussianNB函数对所选取的样本进行训练，运行拉普拉斯平滑算法对每个x分量进行数值+1处理，以此来避免零概率现象的发生。
测试过程中将样本分为3份，采用3折交叉验证法得到风险评估测试的结果，其中2份作为训练集，其余1份作为测试集。具体评估结果如表2所示。
表2 风险评估结果
重新选取和分类样本数据并进行第二次和第三次3折交叉验证，评估结果如表3所示。
表3 三次风险评估结果
由表3中的数据可见，系统风险评估的平均准确率达到84.9%,平均召回率达到85.7%,综合评价指标为85.3%,3次验证结果均无明显差异，表明系统能够正确辨别异常支付行为并结合自定义匹配规则进行支付预警，从而有效避免用户的资金损失。
由多名用户同时登录系统并进行相关操作以验证多用户并发访问情况下的系统运行性能。测试数量为26 577个、并发线程200个、每秒请求数量518个、平均响应时间为0.229 s、平均流量为500 KB/s、错误率为0%。由数据可见，在多用户并发访问的情况下系统正常运行，网络延迟较低，能够对操作请求进行快速响应，总体抗压能力较强。
5、总结
为了解决静态支付二维码安全性较低的问题，本文提出了一种基于TOTP算法的移动支付云系统。利用TOTP算法生成动态支付二维码，使其具备时效性、唯一性、不可伪造性等安全特性；对JWT协议进行优化以实现认证鉴权的功能；通过数字签名保证系统传输数据的安全性和完整性；采用朴素贝叶斯算法和自定义规则匹配建立风险评估模型，对用户的交易行为进行判断。测试结果表明，所提出的系统能够在很大程度上提高移动支付的安全性。
