楊一帆
(陜西青年職業(yè)學院, 數(shù)字信息技術(shù)系, 陜西, 西安 710068)
當前移動支付在國內(nèi)已經(jīng)得到了廣泛的普及,其中又以二維碼支付技術(shù)的應(yīng)用最為常見[1],然而作為收款碼,靜態(tài)二維碼很容易被篡改或替換,從而使商家蒙受較大損失,通過移動終端與支付平臺進行的移動支付也存在數(shù)據(jù)被竊取的風險。為此,本文圍繞TOTP算法設(shè)計了一種動態(tài)二維碼移動云支付系統(tǒng),保證了移動支付交易過程的完整性、可認證性、時效性、唯一性和不可偽造性。
該系統(tǒng)由云支付平臺和與其連接的多臺移動設(shè)備組成,平臺與設(shè)備之間通過REST接口進行通信。系統(tǒng)共包括3個結(jié)構(gòu)層:訪問層、服務(wù)層和資源層,其總體架構(gòu)如圖1所示。
圖1 移動云支付系統(tǒng)總體架構(gòu)
訪問層主要負責用戶與系統(tǒng)的信息交互,其中包括PC瀏覽器、智能POS機、手機App等。
服務(wù)層作為系統(tǒng)的核心主要負責云支付功能的實現(xiàn),為系統(tǒng)提供基礎(chǔ)支撐服務(wù)和核心業(yè)務(wù)服務(wù)。其中,基礎(chǔ)支撐部分主要包括加解密、密鑰管理、認證鑒權(quán)、日志、通信、簽名等服務(wù),核心業(yè)務(wù)部分主要包括交易訂單、商戶信息、用戶信息、風險評估、移動支付等服務(wù)。
資源層中部署的關(guān)系型數(shù)據(jù)庫用于存儲交易相關(guān)數(shù)據(jù),主要包括每次交易的商品信息、出售商品的商戶信息、購買商品客戶的支付信息、用戶賬戶信息等移動支付相關(guān)信息。數(shù)據(jù)緩存方式為Redis分布式緩存。
(1) 動態(tài)支付
基于動態(tài)二維碼的動態(tài)支付是移動云支付系統(tǒng)的核心功能,在交易過程中生成支付密鑰來保證支付的安全進行,具體來說就是需要同時通過商家提供的訂單信息和客戶提供的支付密鑰,并在得到云端的認證后才能完成支付。具體交易流程如圖2所示。
圖2 基于移動云支付的交易流程
交易流程中包含2個重要環(huán)節(jié)。
① 生成支付二維碼。根據(jù)用戶的支付請求實時生成一種動態(tài)二維碼并在生成后的60 s完成一次二維碼更新,直至支付完成,每個客戶在當前交易過程中收到的二維碼都是當前系統(tǒng)中唯一的[2]。
② 認證支付密鑰。在系統(tǒng)接收到商家的訂單以及客戶的支付密鑰之后會立即開始基于時間的認證。首先需要確定支付密鑰尚在有效期之內(nèi),接下來采用TOTP算法生成一個6位的動態(tài)口令,再將該口令與時間戮合成一個字符串并利用哈希算法SHA-256將其轉(zhuǎn)換為動態(tài)支付密鑰。系統(tǒng)通過該密鑰和商家訂單的密鑰串與時間戮對客戶提交的支付密鑰進行驗證,二者相同即可完成交易。
(2) 風險評估程序
商家提交收款請求后系統(tǒng)會啟動風險評估程序。該過程主要是針對客戶的個人信息、消費習慣、消費地點、消費時間、消費水平進行個人支付安全性評估,主要目的是驗證當前交易是否與客戶的日常消費習慣相符。具體評估流程如圖3所示。
圖3 系統(tǒng)風險評估流程
風險評估是基于自定義規(guī)則匹配與樸素貝葉斯算法的結(jié)合進行的,從當次交易多方面屬性的樣本數(shù)據(jù)中進行特征值提取,并據(jù)此對客戶的消費行為進行分類。如果系統(tǒng)認定不符合客戶的消費習慣則會要求客戶再一次進行身份認證,如果相符則開始進行規(guī)則匹配。在此過程中,自定義規(guī)則主要匹配客戶的支付金額、消費時間段與地點等[3]。
(3) 認證鑒權(quán)
系統(tǒng)的認證鑒權(quán)功能分2個部分進行設(shè)計,即統(tǒng)一認證和統(tǒng)一鑒權(quán)。
統(tǒng)一認證是指客戶登錄系統(tǒng)所需的身份認證。為了解決傳統(tǒng)的用戶名、密碼登錄模式的安全隱患問題,系統(tǒng)設(shè)計時加入了人臉識別、聲紋、指紋、短信等認證方式。
統(tǒng)一鑒權(quán)是指客戶保持在線狀態(tài)并進行操作的有效性鑒定。不同于傳統(tǒng)Web站點的Session模式,本文系統(tǒng)采用了適用于移動設(shè)備的Token模式進行鑒權(quán)。
認證鑒權(quán)的實現(xiàn)過程[4]如下。
步驟1 移動客戶端要求用戶輸入手機號碼以向其發(fā)送登錄驗證碼。
步驟2 系統(tǒng)隨機生成6位驗證碼,通過手機通信平臺發(fā)送給請求登錄的用戶。
步驟3 用戶在客戶端輸入接收到的驗證碼并申請登錄。
步驟4 系統(tǒng)接收到用戶反饋的驗證碼后,對用戶的登錄習慣(時間、地點等)進行檢測。
步驟5 若用戶的登錄時間、地點與其日常登錄的時間、地點不符,則會通過客戶端界面提示用戶輸入密碼以進一步確認身份認證。
步驟6 用戶身份驗證獲得通過后系統(tǒng)生成一個與用戶相對應(yīng)的Token并將其發(fā)送給支付用戶的客戶端。
步驟7 用戶成功登錄客戶端后的其所有操作都需要在附帶Token的條件下進行,系統(tǒng)持續(xù)對Token進行驗證以保證其登錄身份的有效性[5]。
步驟8 用戶離線或更換登錄設(shè)備后,之前系統(tǒng)為其提供的Token立即失效。
(4) 數(shù)據(jù)通信
為了保證商家、用戶所持的移動客戶端與系統(tǒng)支付平臺之間的數(shù)據(jù)傳輸,系統(tǒng)內(nèi)部集成了通信模塊。數(shù)據(jù)采用HTTP協(xié)議進行傳輸,以JSON為傳輸載體并在傳輸過程中對所有重要數(shù)據(jù)采取加密措施,帶有JSON數(shù)字簽名的數(shù)據(jù)將以完整、機密、不可更改的狀態(tài)在系統(tǒng)中進行傳輸[6]。
系統(tǒng)利用AES對交易數(shù)據(jù)進行加密,加密數(shù)據(jù)的共享密鑰再由RSA進行加密,對于每一個未完成的交易系統(tǒng)都為其提供一個唯一存在的密鑰,AES共享密鑰則存儲于系統(tǒng)云端中[7]。交易過程中的加密流程如下。
步驟1 系統(tǒng)生成一個16位的數(shù)字key。
步驟2 系統(tǒng)通過RSA將之前生成的key加密,得到AESkey。
步驟3 系統(tǒng)利用AES算法對重要數(shù)據(jù)進行加密。
步驟4 客戶端從JSON數(shù)據(jù)中提取出AESkey,再通過RSA對AESkey進行解密,得到key。
步驟5 客戶端利用AES算法解密加密過的數(shù)據(jù)。
當交易過程進行到支付環(huán)節(jié)時,消費用戶的移動客戶端通過OKHttp提交向商戶用戶支付款項請求,再請求的合法性得到驗證后,系統(tǒng)會從數(shù)據(jù)庫的sequence中提取出交易序列號并結(jié)合當前時間共同生成商家訂單號和用戶的16位密鑰,同時將密鑰與相應(yīng)的時間戮保存在數(shù)據(jù)庫中并發(fā)送給客戶端。
動態(tài)密鑰的生成流程如圖4所示??蛻舳说玫较到y(tǒng)的反饋后通過隨機密鑰和本地密鑰生成新密鑰K,然后運用TOTP算法獲取一個6位的動態(tài)口令。接下來利用哈希函數(shù)將新生成的動態(tài)口令與時間戮結(jié)合在一起生成無法逆向推算的支付密鑰。最后客戶端通過Zxing根據(jù)支付密鑰和訂單號生成支付二維碼,為了保證支付過程的安全進行,該二維碼每60 s更新一次。
圖4 動態(tài)密鑰的生成流程
系統(tǒng)在接收到客戶端反饋的交易信息后找到相應(yīng)的訂單,依據(jù)支付密鑰的生成規(guī)則生成相應(yīng)的密鑰并將其與客戶的支付密鑰進行對比,若二者相同則同意支付并從客戶賬戶中扣除相應(yīng)的金額,若二者不同則拒絕繼續(xù)支付并在交易日志中保存當次交易信息。
該功能基于SciKitlearn實現(xiàn),該工具軟件能夠?qū)?shù)據(jù)進行挖掘與分析,集成了降維、回歸、聚類等多種相關(guān)算法。
移動云支付系統(tǒng)基于支付金額、支付時間、支付商品數(shù)量、收款商戶名、支付地點5個維度的特征數(shù)據(jù)來訓練支付模型,從而對整個交易過程進行風險評估。
當用戶提出交易請求時,系統(tǒng)自動提取特征數(shù)據(jù),采用樸素貝葉斯算法完成模型的訓練,最后對當次交易進行風險評估。系統(tǒng)對客戶的消費行為進行判定,若判定為正常則進行規(guī)則匹配,否則要求用戶輸入支付密碼以進行身份確認。
短信認證的流程中,系統(tǒng)隨機生成一個6位的口令,利用Celery任務(wù)發(fā)布模塊將新口令以短信的形式發(fā)送給用戶,同時將其發(fā)送到Redis緩存中并為其設(shè)置一個過期時間。
移動客戶端所返回的數(shù)據(jù)中包含用戶手機號、驗證碼和有效時間三個屬性。其中,手機號碼用于系統(tǒng)生成提供給用戶的key,短信驗證碼則作為Value。買房用戶提出支付請求后系統(tǒng)會從Redis中提取向該用戶發(fā)出的驗證碼并與用戶輸入的驗證碼進行對比,在二者相同的情況下將用戶的ID轉(zhuǎn)換成附加了其身份信息的Token ID(令牌值)。以上過程總結(jié)如下。
(1) 在完整的JWT信息中,頭部header的type指的是JWT的類型,exp表示申請交易的時間,alg則是說明以HS256的方式進行加密。
(2) 將時間戮和user_id添加到JWT的消息體playload中。
(3) 采用Base64分別對header和playload進行編碼,將得到的字符串用“.”進行連接,再運行HMAC-SHA-256算法完成數(shù)據(jù)的加密操作,再利用Base64編碼加密數(shù)據(jù),從而得到已經(jīng)簽名的字符串。
(4) 用“.”將上述3種編碼后的字符串連接,構(gòu)建一個header.playload.sign形式的Token。
(5) Token的校驗。以“.”為分隔標記將長字符串分解為header、playload和sign 3個獨立的字符串,再將header和playload 2個字符串組合為新字符串,運行HMAC-SHA-256算法,結(jié)合密鑰對該字符串進行加密,再與sign字符串進行對比,若二者一致則從header中提取時間信息驗證有效期,在有效期內(nèi)返回user_id值,如果已超時則要求用戶重新登錄。
用戶通過短信認證通過系統(tǒng)驗證后,系統(tǒng)會向其發(fā)送2個Token。
(1) 短期證書Token,用戶在客戶端進行各種操作時所附帶的有效身份信息。
(2) 長期證書Refresh Token,在短期Token失效后系統(tǒng)所提供的新的Token身份信息,不能用于用戶的操作請求。
兩種Token的有效期不同,用戶退出登錄后2種Token都將被系統(tǒng)刪除,一旦Token過期失效則用戶必須通過Refresh Token來申請新的Token。
TOTP算法以時間為動態(tài)因素,是一次性密碼算法HMAC的一種擴展算法。其計算表達式[8]為
TOTP(K,C)=Truncat(HMAC-SHA-1(K,C))
(1)
式中,K為1個Base32編碼的字符串,C為時間戮,且:
C=(T-T0)/X
(2)
式中,T為交易的時間戮,T0為起始時間,具體取值為0,X為更新時間間隔,通常情況下系統(tǒng)默認值為60 s。
HMAC-SHA-1是1種由SHA1哈希函數(shù)衍生而來的新算法,在計算的過程中HMAC整合了消息數(shù)據(jù)與密鑰,最后通過計算輸出長度為160位的字符串。
Truncate函數(shù)的構(gòu)造過程如下。
(1) 采用HMAC-SHA-1算法將時間戮C與密鑰字符串K加密,得到一個新的字符串,長度20字節(jié)。
(2) 從新字符串最后一個字節(jié)中提取出最低的4位字符,并以其為截取密鑰字符串的下標偏移量。
(3) 從截取到的下標偏移量開始定位4個字節(jié)的字符串,利用大端的方式構(gòu)建一個整數(shù)。
(4) 將該整數(shù)的后6位數(shù)字轉(zhuǎn)換成字符串并返回。
TOTP算法下的動態(tài)口令生成與認證過程:采用TOTP算法生成的密鑰字符串K中含有靜態(tài)密鑰串key1與動態(tài)密鑰串key2,其中key1是客戶端和系統(tǒng)的共享密鑰,key2則是系統(tǒng)在運用相關(guān)算法后生成并交易發(fā)生時發(fā)送給移動設(shè)備中的客戶端;基于TOTP算法,系統(tǒng)隨機生成1個6位的動態(tài)口令,將其與時間戮整合并利用SHA-256算法生成動態(tài)支付密鑰。
系統(tǒng)對于整個交易過程的風險評估基于樸素貝葉斯算法進行。算法表達式為
(3)
式中,C代表類別;X代表待分類項。式(3)的求解方法如下。
(1) 創(chuàng)建待分類項集合C={a1,a2,…,am},am代表一種特征屬性。
(2) 創(chuàng)建類別集合C={Y1,Y2,…,Ym}。
(3) 對P(Y1X),P(Y2X),…,P(YnX)逐項進行計算。
(4) 若P(YkX)=Max{P(Y1X),P(Y2X),…,P(YnX)}成立,則X可歸類到Y(jié)k類中。
風險評估的具體流程如圖5所示,系統(tǒng)基于五個維度的特征屬性進行風險評估,設(shè)定支付時間為T,支付地點為L,支付金額為M,商戶名稱為S,商品名稱為L,則待分類想集合為X={T,L,M,S,L}。將X代入式(3)后該計算式轉(zhuǎn)換為
圖5 系統(tǒng)風險評估流程
(4)
式(4)的計算結(jié)果為
(5)
將P(Y|X)的正常值P(Yes)與異常值P(No)進行比較,若P(Yes)>P(No),則判定為正常支付。
本次系統(tǒng)測試以CVM云服務(wù)器為移動云支付系統(tǒng)的核心平臺。系統(tǒng)網(wǎng)絡(luò)中的HTTPS和反向代理服務(wù)由Nginx提供,在此環(huán)境下Python將具有更強的信號轉(zhuǎn)換能力,在緩沖效應(yīng)被減弱后末端負載也會相應(yīng)大幅減小。Python應(yīng)用服務(wù)器采用Gunicorn,使同步和異步工作模式能夠按需自由切換。系統(tǒng)數(shù)據(jù)使用MySQL服務(wù)器進行存儲,采用Redis為緩存服務(wù)器。此外,由RabbitMQ進行消息隊列處理,由Celery進行分布式任務(wù)隊列處理。
將移動支付App安裝在2部手機中,一部由商家使用,另一部由購物客戶使用。客戶完成商品選擇,商家掃描條形碼生成訂單,客戶在App中打開系統(tǒng)為其生成的動態(tài)支付二維碼,提交訂單的商家掃描該二維碼收款,從而完成當前訂單的支付。系統(tǒng)每60 s進行一次動態(tài)支付二維碼的更新。
移動云支付系統(tǒng)的測試分為風險評估功能測試與系統(tǒng)運行性能測試兩個部分進行。測試過程中基于樸素貝葉斯算法完成風險評估測試的項目訓練,檢測買方用戶的支付行為并為其進行自定義規(guī)則匹配;利用智能測試工具來獲取系統(tǒng)的性能指標,本次測試主要檢測系統(tǒng)在大量用戶同時進行操作情況下的運行性能,主要指標包括平均響應(yīng)時間、平均流量、單位時間內(nèi)請求處理數(shù)量、錯誤率等。
選取2名用戶的完整交易數(shù)據(jù)分別作為用于訓練或測試的黑樣本和白樣本,通過人工評定為樣本添加標簽Label(正常樣本為0,異常樣本為1),從600個樣本數(shù)據(jù)中選取150個異常樣本,其余均為正常樣本,部分樣本信息如表1所示。
表1 風險評估測試部分樣本信息
采用SciKitlearn工具中集成的GaussianNB函數(shù)對所選取的樣本進行訓練,運行拉普拉斯平滑算法對每個x分量進行數(shù)值+1處理,以此來避免零概率現(xiàn)象的發(fā)生。
測試過程中將樣本分為3份,采用3折交叉驗證法得到風險評估測試的結(jié)果,其中2份作為訓練集,其余1份作為測試集。具體評估結(jié)果如表2所示。
表2 風險評估結(jié)果
重新選取和分類樣本數(shù)據(jù)并進行第二次和第三次3折交叉驗證,評估結(jié)果如表3所示。
表3 三次風險評估結(jié)果
由表3中的數(shù)據(jù)可見,系統(tǒng)風險評估的平均準確率達到84.9%,平均召回率達到85.7%,綜合評價指標為85.3%,3次驗證結(jié)果均無明顯差異,表明系統(tǒng)能夠正確辨別異常支付行為并結(jié)合自定義匹配規(guī)則進行支付預(yù)警,從而有效避免用戶的資金損失。
由多名用戶同時登錄系統(tǒng)并進行相關(guān)操作以驗證多用戶并發(fā)訪問情況下的系統(tǒng)運行性能。測試數(shù)量為26 577個、并發(fā)線程200個、每秒請求數(shù)量518個、平均響應(yīng)時間為0.229 s、平均流量為500 KB/s、錯誤率為0%。由數(shù)據(jù)可見,在多用戶并發(fā)訪問的情況下系統(tǒng)正常運行,網(wǎng)絡(luò)延遲較低,能夠?qū)Σ僮髡埱筮M行快速響應(yīng),總體抗壓能力較強。
為了解決靜態(tài)支付二維碼安全性較低的問題,本文提出了一種基于TOTP算法的移動支付云系統(tǒng)。利用TOTP算法生成動態(tài)支付二維碼,使其具備時效性、唯一性、不可偽造性等安全特性;對JWT協(xié)議進行優(yōu)化以實現(xiàn)認證鑒權(quán)的功能;通過數(shù)字簽名保證系統(tǒng)傳輸數(shù)據(jù)的安全性和完整性;采用樸素貝葉斯算法和自定義規(guī)則匹配建立風險評估模型,對用戶的交易行為進行判斷。測試結(jié)果表明,所提出的系統(tǒng)能夠在很大程度上提高移動支付的安全性。