曹鵬飛 李 杰 楊 君

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

0 引 言

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

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

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

1 方案設(shè)計(jì)

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

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

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

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

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

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

1.2 主要功能設(shè)計(jì)

1.2.1 動(dòng)態(tài)支付功能設(shè)計(jì)

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

圖2 支付流程

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

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

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

1.2.2 風(fēng)險(xiǎn)評估功能設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通信功能模塊是連接移動(dòng)端和云端支付平臺的橋梁，用來保證用戶、商戶和云端支付系統(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)為每一個(gè)用戶生成私鑰，而公鑰存儲在云端，具體加密方案設(shè)計(jì)流程如下：

1) 云端支付平臺隨機(jī)生成16個(gè)數(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)實(shí)現(xiàn)

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

2.1 動(dòng)態(tài)支付模塊實(shí)現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 核心算法

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

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

TOTP計(jì)算公式如下：

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

(1)

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

C=(T-T0)/X

(2)

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

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

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

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

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

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

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

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

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

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

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

(3)

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

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

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

3) 計(jì)算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í)間，支付地點(diǎn)、商戶、支付金額、支付商品數(shù)量五個(gè)維度作為特征屬性，設(shè)定用戶的支付地點(diǎn)為L，支付時(shí)間T，支付商戶S，支付商品G，支付金額M，即X={L,T,S,G,M}。

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

將X代入式(3)運(yùn)算：

(4)

結(jié)果如下：

(5)

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

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

4.1 系統(tǒng)運(yùn)行

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

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

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

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

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

(2) 安卓版本：Android 7.1.1；

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

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

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

圖10 系統(tǒng)運(yùn)行

4.2 系統(tǒng)測試

4.2.1 測試指標(biāo)

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

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

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

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

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

在實(shí)驗(yàn)環(huán)境下使用樸素貝葉斯算法進(jìn)行訓(xùn)練，通過統(tǒng)計(jì)兩個(gè)用戶的購物數(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)練，采用拉普拉斯平滑法，對每個(gè)分量x的計(jì)數(shù)加1可以避免零概率問題。

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

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

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

表3 三次3折交叉驗(yàn)證統(tǒng)計(jì)表

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

4.2.3 主要功能測試

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

表4 功能測試用例

4.2.4 性能測試

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

表5 性能測試用例

表6 性能測試表

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

5 結(jié) 語

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