基于TOTP算法的移動云安全支付系統開發

楊一帆

(陜西青年職業學院， 數字信息技術系， 陜西， 西安 710068)

0 引言

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

1 總體設計

1.1 總體架構

該系統由云支付平臺和與其連接的多臺移動設備組成，平臺與設備之間通過REST接口進行通信。系統共包括3個結構層：訪問層、服務層和資源層，其總體架構如圖1所示。

圖1 移動云支付系統總體架構

訪問層主要負責用戶與系統的信息交互，其中包括PC瀏覽器、智能POS機、手機App等。

服務層作為系統的核心主要負責云支付功能的實現，為系統提供基礎支撐服務和核心業務服務。其中，基礎支撐部分主要包括加解密、密鑰管理、認證鑒權、日志、通信、簽名等服務，核心業務部分主要包括交易訂單、商戶信息、用戶信息、風險評估、移動支付等服務。

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

1.2 系統功能設計

(1) 動態支付

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

圖2 基于移動云支付的交易流程

交易流程中包含2個重要環節。

① 生成支付二維碼。根據用戶的支付請求實時生成一種動態二維碼并在生成后的60 s完成一次二維碼更新，直至支付完成，每個客戶在當前交易過程中收到的二維碼都是當前系統中唯一的[2]。

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

(2) 風險評估程序

商家提交收款請求后系統會啟動風險評估程序。該過程主要是針對客戶的個人信息、消費習慣、消費地點、消費時間、消費水平進行個人支付安全性評估，主要目的是驗證當前交易是否與客戶的日常消費習慣相符。具體評估流程如圖3所示。

圖3 系統風險評估流程

風險評估是基于自定義規則匹配與樸素貝葉斯算法的結合進行的，從當次交易多方面屬性的樣本數據中進行特征值提取，并據此對客戶的消費行為進行分類。如果系統認定不符合客戶的消費習慣則會要求客戶再一次進行身份認證，如果相符則開始進行規則匹配。在此過程中，自定義規則主要匹配客戶的支付金額、消費時間段與地點等[3]。

(3) 認證鑒權

系統的認證鑒權功能分2個部分進行設計，即統一認證和統一鑒權。

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

統一鑒權是指客戶保持在線狀態并進行操作的有效性鑒定。不同于傳統Web站點的Session模式，本文系統采用了適用于移動設備的Token模式進行鑒權。

認證鑒權的實現過程[4]如下。

步驟1 移動客戶端要求用戶輸入手機號碼以向其發送登錄驗證碼。

步驟2 系統隨機生成6位驗證碼，通過手機通信平臺發送給請求登錄的用戶。

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

步驟4 系統接收到用戶反饋的驗證碼后，對用戶的登錄習慣(時間、地點等)進行檢測。

步驟5 若用戶的登錄時間、地點與其日常登錄的時間、地點不符，則會通過客戶端界面提示用戶輸入密碼以進一步確認身份認證。

步驟6 用戶身份驗證獲得通過后系統生成一個與用戶相對應的Token并將其發送給支付用戶的客戶端。

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

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

(4) 數據通信

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

系統利用AES對交易數據進行加密，加密數據的共享密鑰再由RSA進行加密，對于每一個未完成的交易系統都為其提供一個唯一存在的密鑰，AES共享密鑰則存儲于系統云端中[7]。交易過程中的加密流程如下。

步驟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的一種擴展算法。其計算表達式[8]為

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

(1)

式中，K為1個Base32編碼的字符串,C為時間戮，且：

C=(T-T0)/X

(2)

式中，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 風險評估算法

系統對于整個交易過程的風險評估基于樸素貝葉斯算法進行。算法表達式為

(3)

式中，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)后該計算式轉換為

圖5 系統風險評估流程

(4)

式(4)的計算結果為

(5)

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

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協議進行優化以實現認證鑒權的功能；通過數字簽名保證系統傳輸數據的安全性和完整性；采用樸素貝葉斯算法和自定義規則匹配建立風險評估模型，對用戶的交易行為進行判斷。測試結果表明，所提出的系統能夠在很大程度上提高移動支付的安全性。