移動云安全支付系統(tǒng)設(shè)計與實現(xiàn)

曹鵬飛 李 杰 楊 君

(三江學(xué)院計算機(jī)科學(xué)與工程學(xué)院 江蘇 南京 210012)

0 引 言

現(xiàn)如今移動支付已成為人們?nèi)粘Ｉ钪胁豢扇笔У囊徊糠郑脩羰褂弥悄苁謾C(jī)就可以完成支付業(yè)務(wù)，技術(shù)主要有：藍(lán)牙支付技術(shù)、NFC支付技術(shù)、二維碼支付技術(shù)、人臉識別支付技術(shù)[1-2]。

隨著移動支付技術(shù)的發(fā)展，移動支付的安全問題隨之出現(xiàn)，眾多用戶使用靜態(tài)二維碼作為收款碼，但靜態(tài)條碼容易被偽造，誤導(dǎo)客戶掃描偽碼，實施欺詐，導(dǎo)致賬戶資金被盜刷、個人敏感信息泄露等風(fēng)險問題。在移動支付交易過程中，移動終端與支付平臺之間的通信安全也至關(guān)重要，一旦交易過程中的數(shù)據(jù)被竊取，信息被篡改。不法分子就能夠獲得用戶、商戶交易的相關(guān)信息，并對交易過程的數(shù)據(jù)進(jìn)行偽造、重放等攻擊。

本文針對移動支付中二維碼易偽造、易被篡改、變造，易攜帶木馬等問題，設(shè)計一套基于TOTP算法的動態(tài)二維碼支付方案，保證交易的不可為造性、實時性、唯一性、時效性、可認(rèn)證性、完整性。

1 方案設(shè)計

1.1 總體架構(gòu)設(shè)計

系統(tǒng)由多終端設(shè)備與云支付平臺組成，各終端通過設(shè)計的REST接口與云支付平臺進(jìn)行交互。系統(tǒng)共分為三層：訪問層、服務(wù)層、資源層。總體系統(tǒng)框架如圖1所示。

圖1 移動安全支付系統(tǒng)總體架構(gòu)

訪問層即訪問云端的方式，分別有手機(jī)APP、智能POS機(jī)、PC瀏覽器。

服務(wù)層是整個移動支付系統(tǒng)的核心，包含了云端支付系統(tǒng)的功能，包括：核心業(yè)務(wù)服務(wù)和基礎(chǔ)支撐服務(wù)。核心業(yè)務(wù)服務(wù)包含動態(tài)支付、風(fēng)險評估、后臺管理、用戶模塊、商戶模塊、訂單模塊。基礎(chǔ)支撐服務(wù)包含簽名、通信、日志、密鑰管理、認(rèn)證鑒權(quán)、加密解密等模塊。

資源層主要是存放移動支付系統(tǒng)信息的實體，使用關(guān)系型數(shù)據(jù)庫存儲賬戶信息、支付信息、商戶信息、商品信息等支付平臺數(shù)據(jù)。使用分布式緩存(Redis)對熱點數(shù)據(jù)進(jìn)行緩存。隨著系統(tǒng)業(yè)務(wù)量增大，采用RabbitMQ作為消息系統(tǒng)，能夠解決數(shù)據(jù)投遞，非阻塞操作和推送通知，異步處理和工作隊列的問題等。針對一般文件存儲，可使用第三方存儲服務(wù)，利用主流CDN和自建CDN節(jié)點的優(yōu)勢，在性能和成本之間尋求平衡。

1.2 主要功能設(shè)計

1.2.1 動態(tài)支付功能設(shè)計

動態(tài)支付是移動云支付系統(tǒng)的核心部分，支付密鑰是標(biāo)記交易的唯一標(biāo)識符，只有商家通過發(fā)送訂單信息和客戶生成的支付密鑰才能申請交易。云端對支付密鑰進(jìn)行認(rèn)證后完成支付交易，支付流程如圖2所示。

圖2 支付流程

支付流程由兩個部分構(gòu)成：

1) 支付二維碼產(chǎn)生 用戶在支付時產(chǎn)生的二維碼由基于時間規(guī)則算法動態(tài)生成的。在整個支付過程中支付二維碼每60 s生成一次，每個用戶的支付二維碼都是唯一的。二維碼有效時間在支付完成或超時立即失效。相對于靜態(tài)二維碼的易偽造、成本低、易竊取等缺點，動態(tài)二維碼能保證其不可為造性、實時性、唯一性、時效性、可認(rèn)證性、完整性。

2) 支付密鑰認(rèn)證 云移動支付系統(tǒng)收到交易訂單和支付密鑰后，要對密鑰進(jìn)行基于時間的認(rèn)證。先驗證是否在有效期內(nèi)，然后通過TOTP算法[3]生成6位動態(tài)口令，將6位動態(tài)口令和時間戳合成的字符串通過哈希算法SHA-256生成動態(tài)支付密鑰[3]。當(dāng)云端服務(wù)器接收到交易過程產(chǎn)生的動態(tài)支付密鑰后，根據(jù)支付訂單號查詢其所對應(yīng)的TOTP中密鑰串K和時間戳，與當(dāng)前時間生成支付密鑰并與用戶生成的支付密鑰進(jìn)行驗證。如相同則交易正確，否則表明支付超時或被篡改偽造。

1.2.2 風(fēng)險評估功能設(shè)計

用戶的風(fēng)險評估是在商戶發(fā)送收款請求時進(jìn)行的。針對用戶的個人信息、消費水平、消費時間、地點和習(xí)慣等方面進(jìn)行安全性分析，評估當(dāng)前消費是否為該用戶的正常購物行為。風(fēng)險評估流程如圖3所示。

圖3 風(fēng)險評估流程

系統(tǒng)采用樸素貝葉斯算法[4]與自定義規(guī)則匹配相結(jié)合的方式來實現(xiàn)支付風(fēng)險評估。根據(jù)用戶交易過程中產(chǎn)生的樣本數(shù)據(jù)，提取特征值屬性，對用戶的支付行為行進(jìn)分類。若結(jié)果異常，則交易不被允許，要求用戶進(jìn)行二次身份認(rèn)證。若結(jié)果正常則對用戶支付的相關(guān)數(shù)據(jù)進(jìn)行規(guī)則匹配。自定義規(guī)則匹配用戶常用的地點、支付時間、支付金額等限制。如果在用戶預(yù)設(shè)范圍內(nèi)則通過則允許支付，否則要求二次身份認(rèn)證。

1.2.3 認(rèn)證鑒權(quán)模塊設(shè)計

在移動云支付系統(tǒng)中認(rèn)證鑒權(quán)包括：統(tǒng)一的認(rèn)證服務(wù)和統(tǒng)一鑒權(quán)服務(wù)。

統(tǒng)一認(rèn)證服務(wù)主要是在用戶執(zhí)行操作時，提供我是我本人的身份證明[5]。常見的身份認(rèn)證用戶名和密碼的輸入是存在被竊取的風(fēng)險。現(xiàn)如今人臉識別、指紋、短信、聲紋是用戶認(rèn)證主要方式。能夠有效地避免不法分子通過自動化工具進(jìn)行密碼爆破和竊取。

統(tǒng)一鑒權(quán)服務(wù)是在用戶認(rèn)證會話的維持和維護(hù)有效性[6]。大多數(shù)Web站點使用Session，其主要功能是保持會話信息，對用戶相關(guān)信息的存儲和對用戶進(jìn)行驗證，而在移動系統(tǒng)中要使用Token來對用戶的身份鑒權(quán)。

認(rèn)證鑒權(quán)主要流程如下：

1) 客戶端通過獲取登錄驗證碼請求提交用戶手機(jī)號獲取登錄驗證碼。

2) 云端支付平臺生成6位隨機(jī)驗證碼，通過第三方短信/語音平臺發(fā)送至用戶手機(jī)。

3) 客戶端得到短信/語音驗證碼后進(jìn)行登錄請求。

4) 云端支付平臺短信/語音驗證通過后，云端支付平臺對用戶進(jìn)行登錄地點/時間異常檢查。

5) 如果用戶不在常用的地點或不在常規(guī)時間段登錄，將會要求用戶輸入密碼進(jìn)行二次身份認(rèn)證。

6) 云端支付平臺驗證后通過相應(yīng)的方法生成一個Token與該用戶進(jìn)行關(guān)聯(lián)，并生成的Token返回給客戶端。

7) 客戶端在所有的請求中都需要攜帶Token進(jìn)行認(rèn)證，云端支付平臺通過解析Token來對客戶端進(jìn)行身份檢測。

8) 當(dāng)用戶退出登錄或在其他設(shè)備登錄時，之前的Token將會失效。

1.2.4 通信功能模塊設(shè)計

通信功能模塊是連接移動端和云端支付平臺的橋梁，用來保證用戶、商戶和云端支付系統(tǒng)之間信息傳遞的安全性。

為保證交易安全性，系統(tǒng)傳輸模式使用HTTPS協(xié)議，使用JSON格式作為數(shù)據(jù)的載體，對通信過程中關(guān)鍵數(shù)據(jù)進(jìn)行加密操作。對JSON數(shù)據(jù)進(jìn)行數(shù)字簽名，能夠有效地保證數(shù)據(jù)完整性、機(jī)密性和不可抵賴性。

在通信過程中采用AES加密數(shù)據(jù)，使用RSA密鑰對AES共享密鑰進(jìn)行二次加密。云端支付系統(tǒng)為每一個用戶生成私鑰，而公鑰存儲在云端，具體加密方案設(shè)計流程如下：

1) 云端支付平臺隨機(jī)生成16個數(shù)字Key。

2) 云端支付平臺使用RSA公鑰將隨機(jī)生成的Key加密生成AESkey。

3) 云端支付平臺通過AES算法結(jié)合Key對關(guān)鍵數(shù)據(jù)加密。

4) 客戶端通過提取JOSN數(shù)據(jù)中AESkey，使用RSA私鑰對AESKey解出Key。

5) 客戶端通過AES算法結(jié)合Key對關(guān)鍵數(shù)據(jù)解密。

2 系統(tǒng)實現(xiàn)

移動安全支付系統(tǒng)采用Android系統(tǒng)作為用戶客戶端，智能POS機(jī)作為商戶客戶端。整個云端支付系統(tǒng)使用Redis作為高速緩存，使用RabbitMQ作為消息隊列系統(tǒng)，完成各個模塊之間的通信，使用Celery作為任務(wù)分發(fā)模塊。

2.1 動態(tài)支付模塊實現(xiàn)

動態(tài)支付是整個移動支付平臺中關(guān)鍵的功能。當(dāng)用戶在線下商店選完商品需要支付時，客戶端通過使用OKHttp發(fā)送支付請求。當(dāng)云端支付系統(tǒng)驗證請求合法性后，通過從數(shù)據(jù)庫設(shè)定的Sequence中取出序列號和當(dāng)前日期組成唯一的預(yù)支付訂單號和生成的16位隨機(jī)密鑰Key、當(dāng)前時間戳存入數(shù)據(jù)庫并返回給用戶。

如圖4所示，客戶端接收到云端支付系統(tǒng)返回的數(shù)據(jù)后，客戶端利用本地共享密鑰和隨機(jī)密鑰生成新的密鑰K，通過TOTP算法生成了6位動態(tài)口令。之后利用哈希函數(shù)HASH-256對6位動態(tài)口令與云端返回的時間戳拼接成的字符串進(jìn)行生成不可逆的支付密鑰。最后客戶端利用ZXing[8]將“預(yù)支付訂單號&支付密鑰”拼接成的字符串生成支付二維碼，支付二維碼隨著時間每60 s更換一次。

圖4 動態(tài)密鑰生成流程

云端支付系統(tǒng)在收到訂單信息后，通過查詢預(yù)支付訂單表，根據(jù)支付密鑰規(guī)則重新生成當(dāng)前密鑰同訂單中的商戶上傳的支付密鑰進(jìn)行比對。如果相同就通過事務(wù)處理扣除用戶相應(yīng)的支付金額，增加商戶的資金。如果不相同，則返回支付失敗，并記錄。

2.2 風(fēng)險評估模塊實現(xiàn)

該模塊由SciKit learn實現(xiàn)，它是一款數(shù)據(jù)挖掘和數(shù)據(jù)分析工具，擁有分類、回歸、聚類、降維等相關(guān)學(xué)習(xí)算法和模型[9]。

本文通過提取用戶支付地點、支付商戶名、支付商品數(shù)量、支付時間和支付金額這五個維度特征數(shù)據(jù)進(jìn)行訓(xùn)練，對系統(tǒng)支付過程的風(fēng)險進(jìn)行評估。

當(dāng)商戶發(fā)出交易指令后，系統(tǒng)自動提取支付地點、支付商戶名、商品數(shù)量、支付時間和支付金額，使用樸素貝葉斯算法進(jìn)行訓(xùn)練樣本模型，最后對本次用戶支付行為進(jìn)行支付風(fēng)險判斷。

用戶行為通過了樸素貝葉算法的異常識別后，系統(tǒng)將再進(jìn)行規(guī)則匹配。如果匹配不通過，則要求用戶輸入支付密碼，進(jìn)一步確認(rèn)身份，完成認(rèn)證。

2.3 認(rèn)證鑒權(quán)模塊實現(xiàn)

如圖5所示，系統(tǒng)生成6位隨機(jī)數(shù)后通過Celery異步發(fā)送給用戶，并設(shè)置過期時間存入緩存Redis中。

圖5 短信發(fā)送流程

返回的數(shù)據(jù)由三個屬性構(gòu)成：用戶手機(jī)號、超時時間、驗證碼。將用戶手機(jī)號碼作為Key，驗證碼作為Value。云端支付系統(tǒng)直接從Redis中獲取號當(dāng)前手機(jī)對應(yīng)的驗證碼與用戶輸入進(jìn)行驗證，驗證通過將用戶ID轉(zhuǎn)換生成攜帶身份信息的令牌值(Token ID)。具體過程如下：

1) JWT頭部header中typ為type縮寫，代表是JWT，alg表示加密方式為HS256，exp代表當(dāng)前時間。

2) 在JWT的消息體playload中添加user_id和時間戳。

3) 簽名(Sign)。其過程如圖6所示，把header、playload分別使用Base64編碼，使用‘.’將經(jīng)過編碼后的字符串進(jìn)行連接，執(zhí)行HMAC-SHA-256算法加密，對加密后的數(shù)據(jù)使用Base64編碼，生成簽名的字符串。

圖6 Sign過程

4) 生成Token。把Base64編碼后header和playload以及sign用‘.’連接起來即header.playload.sign，就生成了Token。

5) 校驗Token。首先用將字符串按‘.’切分三段字符串，分別得到header、playload和sign。然后將header.playload拼裝用密鑰和HAMC SHA-256算法進(jìn)行加密然后得到新的字符串和Sign進(jìn)行比對。如果一致數(shù)據(jù)正確，則從head取出exp對存活期進(jìn)行判斷，如果超時則要求重新登錄，如果在存活期內(nèi)返回user_id值。

用戶短信登錄認(rèn)證成功后，系統(tǒng)將簽發(fā)兩個Token：

1) Token，短期證書，用于客戶端的正常服務(wù)請求所攜帶的認(rèn)證信息。

2) Refresh Token，較長期的證書，用于Token失效后，自動申請新的Token所需攜帶的認(rèn)證信息，不可直接用于服務(wù)請求。

分別給這兩個Token設(shè)置不同的有效期。在用戶退出登錄時通過客戶端將Token和Refresh Token進(jìn)行銷毀。在Refresh有效期內(nèi)，在Token過期時客戶端通過Refresh Token獲取新的Token。當(dāng)Refresh過期后，需要用戶重新認(rèn)證登錄。

3 核心算法

3.1 基于TOTP算法的動態(tài)支付密鑰技術(shù)

TOTP(基于時間的一次性密碼算法)是支持時間作為動態(tài)因素基于HMAC一次性密碼算法的擴(kuò)展[10]。

TOTP計算公式如下：

TOTP(K,C)=Truncate(HMAC-SHA-1(K,C))

(1)

式中：K是密鑰串(Base32字符串)；C是時間戳。

C=(T-T0)/X

(2)

式中：T是當(dāng)前時間戳；T0取值為0；X表示時間步長，默認(rèn)是30 s。

HMAC-SHA-1是從 SHA1 哈希函數(shù)構(gòu)造的一種哈希算法，HMAC將密鑰與消息數(shù)據(jù)混合，輸出長度為 160 位哈希。

Truncate是函數(shù)，實現(xiàn)如下：

1) 將密鑰串K與時間戳C通過HMAC-SHA-1加密，得到一個長度為20字節(jié)的密串。

2) 取出密串的最后一個字節(jié)的低4位，作為截取加密串的下標(biāo)偏移量。

3) 按照下標(biāo)偏移量開始，獲取4個字節(jié)，按照大端方式組合成一個整數(shù)。

4) 截取這個整數(shù)的后6位轉(zhuǎn)成字符串返回。

如圖7所示，因為TOTP的動態(tài)性，其中密鑰串K分別由靜態(tài)密鑰串key1和動態(tài)密鑰串key2組成。靜態(tài)密鑰串key1是客戶端與云端支付平臺的共享密鑰；動態(tài)密鑰key2是由云端支付平臺隨機(jī)生成并下發(fā)給客戶端。客戶端則通過TOTP算法生成6位動態(tài)口令，將生成的動態(tài)口令與時間戳相結(jié)合，最后通過哈希算法SHA-256生成動態(tài)支付密鑰。

圖7 TOTP算法的生成與認(rèn)證

3.2 基于樸素貝葉斯算法的風(fēng)險評估算法

樸素貝葉斯(Naive Bayes)是貝葉斯算法中的分支之一，是常見的一種分類方法，簡稱NB算法[11]。公式如下：

(3)

式中：C為類別；X為待分類項；P(C|X)為X的狀態(tài)下是C的概率大小。求解過程如下：

1) 設(shè)置待分類項X={a1,a2,…,am}，每個a為X一個特征屬性。

2) 確定類別集合C={Y1,Y2,…,Ym}。

3) 計算P(Y1|X)，P(Y2|X),…，P(Yn|X)。

4) 如果P(Yk|X)=Max{P(Y1|X)，P(Y2|X),…，P(Yn|X)},則X屬于Yk類。

如圖8所示，系統(tǒng)選取支付時間，支付地點、商戶、支付金額、支付商品數(shù)量五個維度作為特征屬性，設(shè)定用戶的支付地點為L，支付時間T，支付商戶S，支付商品G，支付金額M，即X={L,T,S,G,M}。

圖8 貝葉斯風(fēng)險評估流程圖

將X代入式(3)運算：

(4)

結(jié)果如下：

(5)

式中：P(L|Y)正常支付情況下L的概率；P(L)為所有情況下L的概率。計算P(Y|X)支付正常為P(Yes)，計算P(N|X)支付異常為P(No)，如P(Yes)>P(No)則表明支付正常，反之則支付異常。

4 系統(tǒng)運行與測試

4.1 系統(tǒng)運行

本系統(tǒng)中所需要的服務(wù)器采用騰訊云CVM服務(wù)器，整體部署方案如圖9所示。整個云端支付系統(tǒng)使用Nginx作為HTTPS服務(wù)器和反向代理，不僅可以提高Python的I/O處理能力，還可以緩沖響應(yīng)，減輕后端壓力。Gunicorn作為Python應(yīng)用服務(wù)器，易于配置管理，能夠按需求切換異步和同步工作模式。數(shù)據(jù)庫服務(wù)器采用MySQL，緩存服務(wù)器使用Redis，消息隊列使用RabbitMQ。Celery作為分布式任務(wù)隊列系統(tǒng)。

圖9 系統(tǒng)部署方案

1) 服務(wù)器端軟硬件配置環(huán)境：

(1) 服務(wù)器類別：騰訊云CVM服務(wù)器。

(2) 服務(wù)器機(jī)型配置：標(biāo)準(zhǔn)型S1；CPU：16核；內(nèi)存：8 GB；硬盤：帶寬：100 Mbit/s。

(3) 操作系統(tǒng)：Ubuntu Server 16.04.1 LTS 64位。

(4) 應(yīng)用服務(wù)器：Nginx 1.10.3 (Ubuntu)，Gunicorn-19.8.1；Python 3.6。

(5) 數(shù)據(jù)庫系統(tǒng)：MySQL 5.6，Redis 3.2.9。

(6) 消息隊列系統(tǒng)：RabbitMQ 3.5.7-1。

(7) 分布式任務(wù)隊列：Celery 4.1.0。

2) 客戶端軟硬件配置環(huán)境

客戶端使用安卓(Android)系統(tǒng)作為運行終端。運行配置如下：

(1) 手機(jī)型號：ONEPLUS A3010；

(2) 安卓版本：Android 7.1.1；

(3) 運行內(nèi)存：6 GB；

(4) 存儲內(nèi)存：128 GB。

云端系統(tǒng)搭建完成后，在兩部手機(jī)上安裝移動支付APP。一部充當(dāng)普通用戶，另一部當(dāng)作商戶，分別注冊各自賬號。用戶在需要購買商品時，在商家確定商品后，用戶只在需要支付的時候打開支付二維碼，商家進(jìn)行掃描二維碼收款。其中二維碼每60 s更新一次，動態(tài)更新達(dá)到了基本的設(shè)計需求。系統(tǒng)運行如圖10所示。

圖10 系統(tǒng)運行

4.2 系統(tǒng)測試

4.2.1 測試指標(biāo)

本系統(tǒng)測試分為風(fēng)險評估測試、主要功能測試與性能測試。

風(fēng)險評估測試?yán)脴闼刎惾~斯算法在實驗環(huán)境進(jìn)行訓(xùn)練，對用戶的異常支付行為進(jìn)行識別和匹配。

功能測試主要使用黑盒測試[12]，通過各個功能編寫測試用例，按照測試用例進(jìn)行測試，驗證結(jié)果的正確性。檢查系統(tǒng)各個功能是否能夠滿足生成環(huán)境需求，包括短信登錄認(rèn)證、密鑰生成分發(fā)、機(jī)密信息加密解密、動態(tài)支付密鑰生成與認(rèn)證、風(fēng)險評估等功能模塊。

性能測試通過自動化的測試工具來對系統(tǒng)的各項性能指標(biāo)進(jìn)行測試[13]。系統(tǒng)性能測試主要測試系統(tǒng)的高并發(fā)性能，包括：平均響應(yīng)時間、每秒處理請求數(shù)量、平均流量和錯誤率等。

4.2.2 風(fēng)險評估測試

在實驗環(huán)境下使用樸素貝葉斯算法進(jìn)行訓(xùn)練，通過統(tǒng)計兩個用戶的購物數(shù)據(jù)，分別訓(xùn)練或測試使用的白樣本和黑樣本。通過人工標(biāo)簽Label(0為正常，1為異常)共600條，其中150份為異常樣本，450份為正常樣本，部分訓(xùn)練樣本如表1所示。

表1 訓(xùn)練樣本

通過Scikit-Learn中的GaussianNB函數(shù)進(jìn)行訓(xùn)練，采用拉普拉斯平滑法，對每個分量x的計數(shù)加1可以避免零概率問題。

實驗將數(shù)據(jù)樣本分為3份，采用3折交叉驗證，兩份為訓(xùn)練集，另一份為測試集。具體異常判斷結(jié)果統(tǒng)計如表2所示。

表2 判斷結(jié)果統(tǒng)計表

對樣本數(shù)據(jù)進(jìn)行打亂，再次進(jìn)行三次3折交叉驗證。具體數(shù)據(jù)如表3所示。

表3 三次3折交叉驗證統(tǒng)計表

經(jīng)測平均準(zhǔn)確率能達(dá)到80%以上，召回率在84%左右，綜合標(biāo)價指標(biāo)均達(dá)0.8，而且數(shù)據(jù)都比較平穩(wěn)，沒有太大的浮動。可以看出樸素貝葉斯算法在一定程度上能有效地辨別異常支付的能力，再結(jié)合移動支付系統(tǒng)的自定義匹配規(guī)則，能夠?qū)Υ蟛糠值奈ｋU支付行為進(jìn)行預(yù)警，有效地保障用戶的資金安全。

4.2.3 主要功能測試

Token獲取、密鑰更新、生成測試、風(fēng)險評估功能測試，如表4所示。

表4 功能測試用例

4.2.4 性能測試

本系統(tǒng)性能測試主要測試系統(tǒng)的高并發(fā)性能，包括：平均響應(yīng)時間、每秒處理請求數(shù)量、平均流量和錯誤率等。具體測試用例如表5所示。采用專業(yè)測試工具Apache Jmeter[14]，用于壓力和性能測試，測試結(jié)果如表6所示。

表5 性能測試用例

表6 性能測試表

根據(jù)測試數(shù)據(jù)看出系統(tǒng)整體性能良好，在網(wǎng)絡(luò)狀態(tài)良好的情況下延遲較低，響應(yīng)及時，能正常運行。

5 結(jié) 語

本文為移動云安全支付設(shè)計了一套可靠的解決方案。通過與TOTP算法相結(jié)合設(shè)計出一種新型動態(tài)二維碼支付方式，保證二維碼的不可偽造性、唯一性、時效性等安全性；通過改進(jìn)現(xiàn)有的JWT協(xié)議建立完整的認(rèn)證鑒權(quán)模式；在通信過程中，采用數(shù)字簽名確保數(shù)據(jù)的完整性、安全性，同時具有不可抵賴性和防止重放等功能；采用了一種基于樸素貝葉斯算法和自定規(guī)則的風(fēng)險評估模型，經(jīng)過測試能夠在一定程度上提升移動支付系統(tǒng)的安全性。