基于TOTP算法的移動(dòng)云安全支付系統(tǒng)開發(fā)

楊一帆

(陜西青年職業(yè)學(xué)院， 數(shù)字信息技術(shù)系， 陜西， 西安 710068)

0 引言

當(dāng)前移動(dòng)支付在國內(nèi)已經(jīng)得到了廣泛的普及，其中又以二維碼支付技術(shù)的應(yīng)用最為常見[1]，然而作為收款碼，靜態(tài)二維碼很容易被篡改或替換，從而使商家蒙受較大損失，通過移動(dòng)終端與支付平臺進(jìn)行的移動(dòng)支付也存在數(shù)據(jù)被竊取的風(fēng)險(xiǎn)。為此，本文圍繞TOTP算法設(shè)計(jì)了一種動(dòng)態(tài)二維碼移動(dòng)云支付系統(tǒng)，保證了移動(dòng)支付交易過程的完整性、可認(rèn)證性、時(shí)效性、唯一性和不可偽造性。

1 總體設(shè)計(jì)

1.1 總體架構(gòu)

該系統(tǒng)由云支付平臺和與其連接的多臺移動(dòng)設(shè)備組成，平臺與設(shè)備之間通過REST接口進(jìn)行通信。系統(tǒng)共包括3個(gè)結(jié)構(gòu)層：訪問層、服務(wù)層和資源層，其總體架構(gòu)如圖1所示。

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

訪問層主要負(fù)責(zé)用戶與系統(tǒng)的信息交互，其中包括PC瀏覽器、智能POS機(jī)、手機(jī)App等。

服務(wù)層作為系統(tǒng)的核心主要負(fù)責(zé)云支付功能的實(shí)現(xiàn)，為系統(tǒng)提供基礎(chǔ)支撐服務(wù)和核心業(yè)務(wù)服務(wù)。其中，基礎(chǔ)支撐部分主要包括加解密、密鑰管理、認(rèn)證鑒權(quán)、日志、通信、簽名等服務(wù)，核心業(yè)務(wù)部分主要包括交易訂單、商戶信息、用戶信息、風(fēng)險(xiǎn)評估、移動(dòng)支付等服務(wù)。

資源層中部署的關(guān)系型數(shù)據(jù)庫用于存儲(chǔ)交易相關(guān)數(shù)據(jù)，主要包括每次交易的商品信息、出售商品的商戶信息、購買商品客戶的支付信息、用戶賬戶信息等移動(dòng)支付相關(guān)信息。數(shù)據(jù)緩存方式為Redis分布式緩存。

1.2 系統(tǒng)功能設(shè)計(jì)

(1) 動(dòng)態(tài)支付

基于動(dòng)態(tài)二維碼的動(dòng)態(tài)支付是移動(dòng)云支付系統(tǒng)的核心功能，在交易過程中生成支付密鑰來保證支付的安全進(jìn)行，具體來說就是需要同時(shí)通過商家提供的訂單信息和客戶提供的支付密鑰，并在得到云端的認(rèn)證后才能完成支付。具體交易流程如圖2所示。

圖2 基于移動(dòng)云支付的交易流程

交易流程中包含2個(gè)重要環(huán)節(jié)。

① 生成支付二維碼。根據(jù)用戶的支付請求實(shí)時(shí)生成一種動(dòng)態(tài)二維碼并在生成后的60 s完成一次二維碼更新，直至支付完成，每個(gè)客戶在當(dāng)前交易過程中收到的二維碼都是當(dāng)前系統(tǒng)中唯一的[2]。

② 認(rèn)證支付密鑰。在系統(tǒng)接收到商家的訂單以及客戶的支付密鑰之后會(huì)立即開始基于時(shí)間的認(rèn)證。首先需要確定支付密鑰尚在有效期之內(nèi)，接下來采用TOTP算法生成一個(gè)6位的動(dòng)態(tài)口令，再將該口令與時(shí)間戮合成一個(gè)字符串并利用哈希算法SHA-256將其轉(zhuǎn)換為動(dòng)態(tài)支付密鑰。系統(tǒng)通過該密鑰和商家訂單的密鑰串與時(shí)間戮對客戶提交的支付密鑰進(jìn)行驗(yàn)證，二者相同即可完成交易。

(2) 風(fēng)險(xiǎn)評估程序

商家提交收款請求后系統(tǒng)會(huì)啟動(dòng)風(fēng)險(xiǎn)評估程序。該過程主要是針對客戶的個(gè)人信息、消費(fèi)習(xí)慣、消費(fèi)地點(diǎn)、消費(fèi)時(shí)間、消費(fèi)水平進(jìn)行個(gè)人支付安全性評估，主要目的是驗(yàn)證當(dāng)前交易是否與客戶的日常消費(fèi)習(xí)慣相符。具體評估流程如圖3所示。

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

風(fēng)險(xiǎn)評估是基于自定義規(guī)則匹配與樸素貝葉斯算法的結(jié)合進(jìn)行的，從當(dāng)次交易多方面屬性的樣本數(shù)據(jù)中進(jìn)行特征值提取，并據(jù)此對客戶的消費(fèi)行為進(jìn)行分類。如果系統(tǒng)認(rèn)定不符合客戶的消費(fèi)習(xí)慣則會(huì)要求客戶再一次進(jìn)行身份認(rèn)證，如果相符則開始進(jìn)行規(guī)則匹配。在此過程中，自定義規(guī)則主要匹配客戶的支付金額、消費(fèi)時(shí)間段與地點(diǎn)等[3]。

(3) 認(rèn)證鑒權(quán)

系統(tǒng)的認(rèn)證鑒權(quán)功能分2個(gè)部分進(jìn)行設(shè)計(jì)，即統(tǒng)一認(rèn)證和統(tǒng)一鑒權(quán)。

統(tǒng)一認(rèn)證是指客戶登錄系統(tǒng)所需的身份認(rèn)證。為了解決傳統(tǒng)的用戶名、密碼登錄模式的安全隱患問題，系統(tǒng)設(shè)計(jì)時(shí)加入了人臉識別、聲紋、指紋、短信等認(rèn)證方式。

統(tǒng)一鑒權(quán)是指客戶保持在線狀態(tài)并進(jìn)行操作的有效性鑒定。不同于傳統(tǒng)Web站點(diǎn)的Session模式，本文系統(tǒng)采用了適用于移動(dòng)設(shè)備的Token模式進(jìn)行鑒權(quán)。

認(rèn)證鑒權(quán)的實(shí)現(xiàn)過程[4]如下。

步驟1 移動(dòng)客戶端要求用戶輸入手機(jī)號碼以向其發(fā)送登錄驗(yàn)證碼。

步驟2 系統(tǒng)隨機(jī)生成6位驗(yàn)證碼，通過手機(jī)通信平臺發(fā)送給請求登錄的用戶。

步驟3 用戶在客戶端輸入接收到的驗(yàn)證碼并申請登錄。

步驟4 系統(tǒng)接收到用戶反饋的驗(yàn)證碼后，對用戶的登錄習(xí)慣(時(shí)間、地點(diǎn)等)進(jìn)行檢測。

步驟5 若用戶的登錄時(shí)間、地點(diǎn)與其日常登錄的時(shí)間、地點(diǎn)不符，則會(huì)通過客戶端界面提示用戶輸入密碼以進(jìn)一步確認(rèn)身份認(rèn)證。

步驟6 用戶身份驗(yàn)證獲得通過后系統(tǒng)生成一個(gè)與用戶相對應(yīng)的Token并將其發(fā)送給支付用戶的客戶端。

步驟7 用戶成功登錄客戶端后的其所有操作都需要在附帶Token的條件下進(jìn)行，系統(tǒng)持續(xù)對Token進(jìn)行驗(yàn)證以保證其登錄身份的有效性[5]。

步驟8 用戶離線或更換登錄設(shè)備后，之前系統(tǒng)為其提供的Token立即失效。

(4) 數(shù)據(jù)通信

為了保證商家、用戶所持的移動(dòng)客戶端與系統(tǒng)支付平臺之間的數(shù)據(jù)傳輸，系統(tǒng)內(nèi)部集成了通信模塊。數(shù)據(jù)采用HTTP協(xié)議進(jìn)行傳輸，以JSON為傳輸載體并在傳輸過程中對所有重要數(shù)據(jù)采取加密措施，帶有JSON數(shù)字簽名的數(shù)據(jù)將以完整、機(jī)密、不可更改的狀態(tài)在系統(tǒng)中進(jìn)行傳輸[6]。

系統(tǒng)利用AES對交易數(shù)據(jù)進(jìn)行加密，加密數(shù)據(jù)的共享密鑰再由RSA進(jìn)行加密，對于每一個(gè)未完成的交易系統(tǒng)都為其提供一個(gè)唯一存在的密鑰，AES共享密鑰則存儲(chǔ)于系統(tǒng)云端中[7]。交易過程中的加密流程如下。

步驟1 系統(tǒng)生成一個(gè)16位的數(shù)字key。

步驟2 系統(tǒng)通過RSA將之前生成的key加密，得到AESkey。

步驟3 系統(tǒng)利用AES算法對重要數(shù)據(jù)進(jìn)行加密。

步驟4 客戶端從JSON數(shù)據(jù)中提取出AESkey，再通過RSA對AESkey進(jìn)行解密，得到key。

步驟5 客戶端利用AES算法解密加密過的數(shù)據(jù)。

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

2.1 動(dòng)態(tài)支付功能的實(shí)現(xiàn)

當(dāng)交易過程進(jìn)行到支付環(huán)節(jié)時(shí)，消費(fèi)用戶的移動(dòng)客戶端通過OKHttp提交向商戶用戶支付款項(xiàng)請求，再請求的合法性得到驗(yàn)證后，系統(tǒng)會(huì)從數(shù)據(jù)庫的sequence中提取出交易序列號并結(jié)合當(dāng)前時(shí)間共同生成商家訂單號和用戶的16位密鑰，同時(shí)將密鑰與相應(yīng)的時(shí)間戮保存在數(shù)據(jù)庫中并發(fā)送給客戶端。

動(dòng)態(tài)密鑰的生成流程如圖4所示。客戶端得到系統(tǒng)的反饋后通過隨機(jī)密鑰和本地密鑰生成新密鑰K，然后運(yùn)用TOTP算法獲取一個(gè)6位的動(dòng)態(tài)口令。接下來利用哈希函數(shù)將新生成的動(dòng)態(tài)口令與時(shí)間戮結(jié)合在一起生成無法逆向推算的支付密鑰。最后客戶端通過Zxing根據(jù)支付密鑰和訂單號生成支付二維碼，為了保證支付過程的安全進(jìn)行，該二維碼每60 s更新一次。

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

系統(tǒng)在接收到客戶端反饋的交易信息后找到相應(yīng)的訂單，依據(jù)支付密鑰的生成規(guī)則生成相應(yīng)的密鑰并將其與客戶的支付密鑰進(jìn)行對比，若二者相同則同意支付并從客戶賬戶中扣除相應(yīng)的金額，若二者不同則拒絕繼續(xù)支付并在交易日志中保存當(dāng)次交易信息。

2.2 風(fēng)險(xiǎn)評估功能的實(shí)現(xiàn)

該功能基于SciKitlearn實(shí)現(xiàn)，該工具軟件能夠?qū)?shù)據(jù)進(jìn)行挖掘與分析，集成了降維、回歸、聚類等多種相關(guān)算法。

移動(dòng)云支付系統(tǒng)基于支付金額、支付時(shí)間、支付商品數(shù)量、收款商戶名、支付地點(diǎn)5個(gè)維度的特征數(shù)據(jù)來訓(xùn)練支付模型，從而對整個(gè)交易過程進(jìn)行風(fēng)險(xiǎn)評估。

當(dāng)用戶提出交易請求時(shí)，系統(tǒng)自動(dòng)提取特征數(shù)據(jù)，采用樸素貝葉斯算法完成模型的訓(xùn)練，最后對當(dāng)次交易進(jìn)行風(fēng)險(xiǎn)評估。系統(tǒng)對客戶的消費(fèi)行為進(jìn)行判定，若判定為正常則進(jìn)行規(guī)則匹配，否則要求用戶輸入支付密碼以進(jìn)行身份確認(rèn)。

2.3 認(rèn)證鑒權(quán)功能的實(shí)現(xiàn)

短信認(rèn)證的流程中，系統(tǒng)隨機(jī)生成一個(gè)6位的口令，利用Celery任務(wù)發(fā)布模塊將新口令以短信的形式發(fā)送給用戶，同時(shí)將其發(fā)送到Redis緩存中并為其設(shè)置一個(gè)過期時(shí)間。

移動(dòng)客戶端所返回的數(shù)據(jù)中包含用戶手機(jī)號、驗(yàn)證碼和有效時(shí)間三個(gè)屬性。其中，手機(jī)號碼用于系統(tǒng)生成提供給用戶的key，短信驗(yàn)證碼則作為Value。買房用戶提出支付請求后系統(tǒng)會(huì)從Redis中提取向該用戶發(fā)出的驗(yàn)證碼并與用戶輸入的驗(yàn)證碼進(jìn)行對比，在二者相同的情況下將用戶的ID轉(zhuǎn)換成附加了其身份信息的Token ID(令牌值)。以上過程總結(jié)如下。

(1) 在完整的JWT信息中，頭部header的type指的是JWT的類型，exp表示申請交易的時(shí)間，alg則是說明以HS256的方式進(jìn)行加密。

(2) 將時(shí)間戮和user_id添加到JWT的消息體playload中。

(3) 采用Base64分別對header和playload進(jìn)行編碼，將得到的字符串用“.”進(jìn)行連接，再運(yùn)行HMAC-SHA-256算法完成數(shù)據(jù)的加密操作，再利用Base64編碼加密數(shù)據(jù)，從而得到已經(jīng)簽名的字符串。

(4) 用“.”將上述3種編碼后的字符串連接，構(gòu)建一個(gè)header.playload.sign形式的Token。

(5) Token的校驗(yàn)。以“.”為分隔標(biāo)記將長字符串分解為header、playload和sign 3個(gè)獨(dú)立的字符串，再將header和playload 2個(gè)字符串組合為新字符串，運(yùn)行HMAC-SHA-256算法，結(jié)合密鑰對該字符串進(jìn)行加密，再與sign字符串進(jìn)行對比，若二者一致則從header中提取時(shí)間信息驗(yàn)證有效期，在有效期內(nèi)返回user_id值，如果已超時(shí)則要求用戶重新登錄。

用戶通過短信認(rèn)證通過系統(tǒng)驗(yàn)證后，系統(tǒng)會(huì)向其發(fā)送2個(gè)Token。

(1) 短期證書Token，用戶在客戶端進(jìn)行各種操作時(shí)所附帶的有效身份信息。

(2) 長期證書Refresh Token，在短期Token失效后系統(tǒng)所提供的新的Token身份信息，不能用于用戶的操作請求。

兩種Token的有效期不同，用戶退出登錄后2種Token都將被系統(tǒng)刪除，一旦Token過期失效則用戶必須通過Refresh Token來申請新的Token。

3 系統(tǒng)核心算法設(shè)計(jì)

3.1 TOTP算法

TOTP算法以時(shí)間為動(dòng)態(tài)因素，是一次性密碼算法HMAC的一種擴(kuò)展算法。其計(jì)算表達(dá)式[8]為

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

(1)

式中，K為1個(gè)Base32編碼的字符串,C為時(shí)間戮，且：

C=(T-T0)/X

(2)

式中，T為交易的時(shí)間戮,T0為起始時(shí)間，具體取值為0，X為更新時(shí)間間隔，通常情況下系統(tǒng)默認(rèn)值為60 s。

HMAC-SHA-1是1種由SHA1哈希函數(shù)衍生而來的新算法，在計(jì)算的過程中HMAC整合了消息數(shù)據(jù)與密鑰，最后通過計(jì)算輸出長度為160位的字符串。

Truncate函數(shù)的構(gòu)造過程如下。

(1) 采用HMAC-SHA-1算法將時(shí)間戮C與密鑰字符串K加密，得到一個(gè)新的字符串，長度20字節(jié)。

(2) 從新字符串最后一個(gè)字節(jié)中提取出最低的4位字符，并以其為截取密鑰字符串的下標(biāo)偏移量。

(3) 從截取到的下標(biāo)偏移量開始定位4個(gè)字節(jié)的字符串，利用大端的方式構(gòu)建一個(gè)整數(shù)。

(4) 將該整數(shù)的后6位數(shù)字轉(zhuǎn)換成字符串并返回。

TOTP算法下的動(dòng)態(tài)口令生成與認(rèn)證過程：采用TOTP算法生成的密鑰字符串K中含有靜態(tài)密鑰串key1與動(dòng)態(tài)密鑰串key2，其中key1是客戶端和系統(tǒng)的共享密鑰，key2則是系統(tǒng)在運(yùn)用相關(guān)算法后生成并交易發(fā)生時(shí)發(fā)送給移動(dòng)設(shè)備中的客戶端；基于TOTP算法，系統(tǒng)隨機(jī)生成1個(gè)6位的動(dòng)態(tài)口令，將其與時(shí)間戮整合并利用SHA-256算法生成動(dòng)態(tài)支付密鑰。

3.2 風(fēng)險(xiǎn)評估算法

系統(tǒng)對于整個(gè)交易過程的風(fēng)險(xiǎn)評估基于樸素貝葉斯算法進(jìn)行。算法表達(dá)式為

(3)

式中，C代表類別；X代表待分類項(xiàng)。式(3)的求解方法如下。

(1) 創(chuàng)建待分類項(xiàng)集合C={a1,a2,…，am}，am代表一種特征屬性。

(2) 創(chuàng)建類別集合C={Y1,Y2,…，Ym}。

(3) 對P(Y1X)，P(Y2X)，…，P(YnX)逐項(xiàng)進(jìn)行計(jì)算。

(4) 若P(YkX)=Max{P(Y1X)，P(Y2X)，…，P(YnX)}成立，則X可歸類到Y(jié)k類中。

風(fēng)險(xiǎn)評估的具體流程如圖5所示，系統(tǒng)基于五個(gè)維度的特征屬性進(jìn)行風(fēng)險(xiǎn)評估，設(shè)定支付時(shí)間為T，支付地點(diǎn)為L，支付金額為M，商戶名稱為S，商品名稱為L，則待分類想集合為X={T,L,M,S,L}。將X代入式(3)后該計(jì)算式轉(zhuǎn)換為

圖5 系統(tǒng)風(fēng)險(xiǎn)評估流程

(4)

式(4)的計(jì)算結(jié)果為

(5)

將P(Y|X)的正常值P(Yes)與異常值P(No)進(jìn)行比較，若P(Yes)>P(No)，則判定為正常支付。

4 系統(tǒng)測試與分析

4.1 測試環(huán)境

本次系統(tǒng)測試以CVM云服務(wù)器為移動(dòng)云支付系統(tǒng)的核心平臺。系統(tǒng)網(wǎng)絡(luò)中的HTTPS和反向代理服務(wù)由Nginx提供，在此環(huán)境下Python將具有更強(qiáng)的信號轉(zhuǎn)換能力，在緩沖效應(yīng)被減弱后末端負(fù)載也會(huì)相應(yīng)大幅減小。Python應(yīng)用服務(wù)器采用Gunicorn，使同步和異步工作模式能夠按需自由切換。系統(tǒng)數(shù)據(jù)使用MySQL服務(wù)器進(jìn)行存儲(chǔ)，采用Redis為緩存服務(wù)器。此外，由RabbitMQ進(jìn)行消息隊(duì)列處理，由Celery進(jìn)行分布式任務(wù)隊(duì)列處理。

將移動(dòng)支付App安裝在2部手機(jī)中，一部由商家使用，另一部由購物客戶使用。客戶完成商品選擇，商家掃描條形碼生成訂單，客戶在App中打開系統(tǒng)為其生成的動(dòng)態(tài)支付二維碼，提交訂單的商家掃描該二維碼收款，從而完成當(dāng)前訂單的支付。系統(tǒng)每60 s進(jìn)行一次動(dòng)態(tài)支付二維碼的更新。

4.2 系統(tǒng)測試

移動(dòng)云支付系統(tǒng)的測試分為風(fēng)險(xiǎn)評估功能測試與系統(tǒng)運(yùn)行性能測試兩個(gè)部分進(jìn)行。測試過程中基于樸素貝葉斯算法完成風(fēng)險(xiǎn)評估測試的項(xiàng)目訓(xùn)練，檢測買方用戶的支付行為并為其進(jìn)行自定義規(guī)則匹配；利用智能測試工具來獲取系統(tǒng)的性能指標(biāo)，本次測試主要檢測系統(tǒng)在大量用戶同時(shí)進(jìn)行操作情況下的運(yùn)行性能，主要指標(biāo)包括平均響應(yīng)時(shí)間、平均流量、單位時(shí)間內(nèi)請求處理數(shù)量、錯(cuò)誤率等。

選取2名用戶的完整交易數(shù)據(jù)分別作為用于訓(xùn)練或測試的黑樣本和白樣本，通過人工評定為樣本添加標(biāo)簽Label(正常樣本為0，異常樣本為1)，從600個(gè)樣本數(shù)據(jù)中選取150個(gè)異常樣本，其余均為正常樣本，部分樣本信息如表1所示。

表1 風(fēng)險(xiǎn)評估測試部分樣本信息

采用SciKitlearn工具中集成的GaussianNB函數(shù)對所選取的樣本進(jìn)行訓(xùn)練，運(yùn)行拉普拉斯平滑算法對每個(gè)x分量進(jìn)行數(shù)值+1處理，以此來避免零概率現(xiàn)象的發(fā)生。

測試過程中將樣本分為3份，采用3折交叉驗(yàn)證法得到風(fēng)險(xiǎn)評估測試的結(jié)果，其中2份作為訓(xùn)練集，其余1份作為測試集。具體評估結(jié)果如表2所示。

表2 風(fēng)險(xiǎn)評估結(jié)果

重新選取和分類樣本數(shù)據(jù)并進(jìn)行第二次和第三次3折交叉驗(yàn)證，評估結(jié)果如表3所示。

表3 三次風(fēng)險(xiǎn)評估結(jié)果

由表3中的數(shù)據(jù)可見，系統(tǒng)風(fēng)險(xiǎn)評估的平均準(zhǔn)確率達(dá)到84.9%，平均召回率達(dá)到85.7%，綜合評價(jià)指標(biāo)為85.3%，3次驗(yàn)證結(jié)果均無明顯差異，表明系統(tǒng)能夠正確辨別異常支付行為并結(jié)合自定義匹配規(guī)則進(jìn)行支付預(yù)警，從而有效避免用戶的資金損失。

由多名用戶同時(shí)登錄系統(tǒng)并進(jìn)行相關(guān)操作以驗(yàn)證多用戶并發(fā)訪問情況下的系統(tǒng)運(yùn)行性能。測試數(shù)量為26 577個(gè)、并發(fā)線程200個(gè)、每秒請求數(shù)量518個(gè)、平均響應(yīng)時(shí)間為0.229 s、平均流量為500 KB/s、錯(cuò)誤率為0%。由數(shù)據(jù)可見，在多用戶并發(fā)訪問的情況下系統(tǒng)正常運(yùn)行，網(wǎng)絡(luò)延遲較低，能夠?qū)Σ僮髡埱筮M(jìn)行快速響應(yīng)，總體抗壓能力較強(qiáng)。

5 總結(jié)

為了解決靜態(tài)支付二維碼安全性較低的問題，本文提出了一種基于TOTP算法的移動(dòng)支付云系統(tǒng)。利用TOTP算法生成動(dòng)態(tài)支付二維碼，使其具備時(shí)效性、唯一性、不可偽造性等安全特性；對JWT協(xié)議進(jìn)行優(yōu)化以實(shí)現(xiàn)認(rèn)證鑒權(quán)的功能；通過數(shù)字簽名保證系統(tǒng)傳輸數(shù)據(jù)的安全性和完整性；采用樸素貝葉斯算法和自定義規(guī)則匹配建立風(fēng)險(xiǎn)評估模型，對用戶的交易行為進(jìn)行判斷。測試結(jié)果表明，所提出的系統(tǒng)能夠在很大程度上提高移動(dòng)支付的安全性。