一種基于J2ME的移動支付系統(tǒng)的設計與實現(xiàn)

摘要：移動支付是移動電子商務中的最重要的部分之一。安全性、私密性、易用性是移動支付的最重要的幾個問題。目前有許多不同種類的技術(shù)能夠實現(xiàn)移動支付，其中J2ME憑借其多種顯著的優(yōu)勢成為了佼佼者。移動支付系統(tǒng)也有多種體系架構(gòu)，其中以第三方支付平臺為中心的架構(gòu)比較靈活、具有很強的可擴展性。本文討論一個基于J2ME的以第三方支付平臺為中心的移動支付系統(tǒng)的特點和優(yōu)越性，并給出這個系統(tǒng)詳細的設計與實現(xiàn)過程。
關(guān)鍵詞：移動支付;J2ME;XML加密;XML簽名

1、 引言

當前移動付費已經(jīng)相當普及，并受到來自銀行、零售業(yè)等移動行業(yè)以外企業(yè)的關(guān)注。移動支付是指交易雙方為通過手機、PDA、移動PC等移動設備進行商業(yè)交易。

移動支付根據(jù)涉及的金額的不同，一般可以分為以下兩類：

1）微支付（小額支付）：微支付是指交易額少于10美元，通常是指購買移動內(nèi)容業(yè)務。

2）宏支付：宏支付是指交易金額較大的支付行為。

對于宏支付方式來說，通過可靠的金融機構(gòu)進行交易鑒權(quán)是非常必要的；而對于微支付來說，使用移動網(wǎng)絡本身的SIM卡鑒權(quán)機制就能夠達到較高的安全性了。

與傳統(tǒng)支付方式的比較，移動支付的最大特點是交易靈活，方便快捷。但由于安全性和易用性問題未得到很好的解決，目前國內(nèi)的移動支付主要是小額支付為主。目前能夠實現(xiàn)移動支付的技術(shù)從理論上來說有很多，如SMS、WAP、J2ME等增值服務技術(shù)均能夠滿足移動支付業(yè)務的基本需要。其中J2ME憑借其可移植性、強大的JDK支持等等顯著的優(yōu)勢成為了未來移動支付技術(shù)的首選。

2、 系統(tǒng)的分析與設計

2．1 移動支付系統(tǒng)的基本組成部分

移動支付系統(tǒng)一般可以分為以下基本組成部分：

1） 移動運營商：移動運營商的主要任務是為移動支付提供通信渠道。

2） 金融機構(gòu)：一般是銀行，為用戶、商家之間的交易提供了不使用現(xiàn)金的渠道。

3） 移動支付平臺提供商：第三方移動支付平臺提供商是運營商和金融機構(gòu)之間的銜接環(huán)節(jié)。

4） 用戶商家。

2．2 以第三方移動支付平臺為中心的設計模式

目前，移動支付系統(tǒng)的設計模式主要有以下三種：

1） 以移動運營商為中心的設計模式；

2） 以銀行為中心的設計模式；

3） 以第三方移動支付平臺提供商為中心的設計模式。

其中，以第三方移動支付平臺提供商為中心的設計模式如圖1所示，它具有簡單、便捷、跨領(lǐng)域操作等另外兩種設計模式所不具備優(yōu)點。

2．3 移動支付系統(tǒng)運作流程

以第三方移動支付平臺提供商為中心的移動支付系統(tǒng)的運作流程如下：

1） 用戶發(fā)交易短信到移動支付平臺提供商的服務號；

2） 支付平臺收到短信后進行服務識別，并向用戶回復確認消息；

3） 用戶收到確認短信后回復，確認此次交易；

4） 支付平臺收到確認短信后，根據(jù)商品編號、價格以及相關(guān)注冊信息等查詢到用戶的銀行卡號碼；

5） 支付平臺嘗試向銀行發(fā)出扣費請求，如果扣費成功則轉(zhuǎn)入6），否則下發(fā)短信給用戶提示交易失??；

6） 扣費成功，向用戶發(fā)送確認短信，同時告知相關(guān)移動支付系統(tǒng)交易成功，交易結(jié)束。

2．4 系統(tǒng)實現(xiàn)的重點

1） 安全性問題

由于無線網(wǎng)絡本身幾乎不提供安全保護措施，因此移動支付過程中可能受到多種的攻擊行為。要實現(xiàn)安全的無線交易，必須要解決以下幾個問題：

鑒權(quán)（Authentication）：通信雙方必須標識其本身，沒有經(jīng)過鑒權(quán)的通信方將不能夠進行下一步操作。

數(shù)據(jù)完整性（Integrity）：確保交易他方或非法入侵者不能對交易的內(nèi)容進行修改，從而保證通信中的接收方收到的是原文。

數(shù)據(jù)機密性（Confidentiality）：防止合法或隱私數(shù)據(jù)為非法用戶所獲得，從而確保在交易過程中只有交易的雙方才能唯一知道交易的內(nèi)容。

不可否認性（Non－repudiation）：確保交易行為正確性，交易雙方均不能否認交易行為產(chǎn)生的事實。

2） 開發(fā)移動終端設備的應用程序的限制

開發(fā)移動終端設備的應用程序要受到多種條件的限制如：芯片處理能力弱，存儲空間小，堆內(nèi)存小，屏幕尺寸有限，按鍵少，網(wǎng)絡帶寬不足等。

2．5 安全性問題解決方法

要保護通信安全，實現(xiàn)安全的無線交易，必須要解決通信過程中的鑒權(quán)，數(shù)據(jù)完整性，數(shù)據(jù)機密性和不可否認性這幾個問題。而數(shù)據(jù)加密和數(shù)字簽名兩種安全措施的利器正好可以達到這個目的。

數(shù)據(jù)加密的方式多種多樣，如使用已經(jīng)很成熟的SSL/TLS和HTTPS對網(wǎng)絡連接進行加密，從而保護數(shù)據(jù)。此外其加密算法也同樣有很多的選擇，常用的有Triple DES、RSA等等算法。系統(tǒng)采用Triple DES來加密傳輸?shù)臋C密數(shù)據(jù)，RSA算法來加密Triple DES的密匙。

數(shù)字簽名解決以下問題：

鑒權(quán)：由于私匙與公匙是一一對應的，并且私匙只有用戶才能夠持有，因此實際上私匙成為了用戶的身份的唯一標志，就像一般的用戶名/密碼一樣可以在鑒權(quán)過程中識別用戶身份。

數(shù)據(jù)完整性：數(shù)據(jù)完整性主要是保證內(nèi)容不被篡改。在數(shù)字簽名的流程中，接收方在收到簽名及其原始消息后，會按照消息原文再生成一次摘要，然后與用公匙解密的摘要進行對比驗證。因此即使入侵者修改了原文，也會因為無法通過對比驗證而達不到破壞的目的。

不可否認性：因為特定的簽名信息只能由某個用戶通過私匙進行簽名，而不能由任何其他人實現(xiàn)，因此用戶無法否認經(jīng)過自己簽名的信息。

這里選擇XML作為客戶端與服務器通信的數(shù)據(jù)載體。使用XML不但可以以清晰的邏輯表示復雜的嵌套的數(shù)據(jù)結(jié)構(gòu)，而且因為XML是當今互聯(lián)網(wǎng)的主流的通信接口的標準，有很好的兼容性與擴展性。所以我們將使用XML加密與XML簽名解決本系統(tǒng)的安全性問題。

3、 J2ME客戶端的實現(xiàn)

整個J2ME客戶端的邏輯架構(gòu)是由若干個功能模塊組成的，這些功能模塊覆蓋了網(wǎng)絡通信、用戶界面、安全等各個方面的職能，并通過模塊間的通信共同實現(xiàn)了移動支付系統(tǒng)客戶端的功能。

邏輯結(jié)構(gòu)如圖2所示，其中A～F的意義如下：

A：用戶請求交易 / 交易操作結(jié)果

B：用戶輸入的交易請求信息 / 服務器端返回的交易結(jié)果

D：經(jīng)過XML簽名的已加密請求信息 / 解析過的XML返回結(jié)果

E：組裝好的經(jīng)過XML簽名的已加密請求信息的XML數(shù)據(jù)包 / 網(wǎng)絡通信模塊接收到的XML數(shù)據(jù)包

F：發(fā)向服務器的XML數(shù)據(jù)包 / 接收到的來自服務器的XML數(shù)據(jù)包

黑色雙箭頭所表示的是J2ME特有的RMS數(shù)據(jù)庫的數(shù)據(jù)。數(shù)據(jù)庫訪問模塊負責調(diào)用J2ME的RMS數(shù)據(jù)庫的功能接口，對用戶界面模塊用的個性化設置，XML加密和簽名用的私匙和公匙對，網(wǎng)絡通信模塊用的HTTP訪問地址和設置等等數(shù)據(jù)進行存取，而其它模塊則通過訪問數(shù)據(jù)庫模塊存取所需數(shù)據(jù)。

在客戶端系統(tǒng)的實現(xiàn)中，使用了一些第三方API庫：kXML和Bouncy Castle API。其中kXML是XML組裝/解析的工具，而Bouncy Castle API是J2ME應用程序?qū)Ｓ玫腦ML加密/解密和簽名/驗證的工具。

客戶端部分的主要模塊實現(xiàn)如下：

1） 數(shù)據(jù)庫訪問模塊

數(shù)據(jù)庫訪問模塊是所有其它模塊需要用到的模塊，這是因為它把整個J2ME客戶端需要用到的程序配置和用戶設置存取到J2ME的數(shù)據(jù)庫中。在J2ME MIDP中定義了一個簡單的基于記錄的數(shù)據(jù)庫管理系統(tǒng)（Record Management System，RMS），在RMS中Record Store等同于一般數(shù)據(jù)庫系統(tǒng)中的表（Table），它是記錄了一系列記錄的文件。

數(shù)據(jù)庫訪問模塊對RMS進行操作，并對外部模塊提供了兩個存取數(shù)據(jù)的接口：

按名稱保存數(shù)據(jù)到RMS的接口：public void setDataToRecordStore(String name, String data)

按名稱從RMS獲取數(shù)據(jù)的接口：public String getDataFromRecordStore(String name)

2） 用戶界面模塊

用戶界面模塊實現(xiàn)人機交互工能，接收用戶輸入，并把操作結(jié)果以友善的形式進行輸出。除了使用J2ME提供的Display、Screen、Label、Command、Alert、Form、TextField等高級用戶界面控件外，還需要使用J2ME提供的Canvas、Image等等低級用戶界面API，來實現(xiàn)動畫等特效。

3） XML加密/解密模塊

這兩個模塊負責對服務器端傳來的用RSA算法公匙加密的共享密匙進行解密，然后用共享密匙對機密信息使用Triple DES算法進行加密。

通過使用Bouncy Castle API密碼術(shù)包，我們可以輕松地對所需要傳輸?shù)慕灰渍埱罄锩娴臋C密信息進行XML加密和解密。它所提供的org.bouncycastle.crypto包有加密/解密中需要用到的絕大部分的類，另外org.bouncycastle.util包提供了包括Base64編碼轉(zhuǎn)換、Hex編碼轉(zhuǎn)換等有用的工具類。在Bouncy Castle API中，公匙、私匙和共享密匙都是對象，在試圖使用它們之前，必須要通過它們的主要參數(shù)重構(gòu)出這些密匙對象。RSA的公匙有Modulus和Exponent兩個主要參數(shù)，RSA私匙除了這兩個參數(shù)外，還有privExp、dp、dq、p、q、qInv等幾個參數(shù)，而Triple DES共享密匙只有單一的key參數(shù)。在傳遞這些密匙參數(shù)或加密的相關(guān)信息時，由于XML加密的很多元素指定使用Base64編碼，因此還需要用到Base64這個工具類。我們定義了一個Encryptor類來處理所有加密/解密的相關(guān)的問題。定義的接口如下：

TripleDES加密接口：public byte[] encryptTripleDES (byte[] data) throws CryptoException

RSA解密接口：public synchronized byte[] decryptRSA(byte[] data) throws CryptoException

4） XML簽名/驗證模塊

XML簽名過程中，首先生成原始數(shù)據(jù)的摘要，再對摘要進行簽名。生成摘要的算法一般使用SHA1算法。Bouncy Castle API包同樣提供了生成簽名用的摘要的SHA1Digest類，以及用于數(shù)字簽名的RSAEngine、PSSSigner等類。我們定義Signature類封裝所有的處理簽名的功能代碼。定義的接口如下：

生成摘要：private byte[] getDigest(String mesg) throws Exception

使用RSA私匙簽名：public byte[] RSASign(byte[] toSign) throws Exception

5） XML組裝/解析模塊

為了簡化問題，XML組裝可以使用簡單的字符串拼接來實現(xiàn)，而對于XML解析工作，我們使用kXML來處理。它是一個只占很小存儲空間的XML語法分析程序，對于J2ME應用程序非常適合。

kXML有一個非常獨特的DOM操作方法和被稱為Pull的語法分析方法。DOM是一個與XML相互作用的簡單方法，通常這個XML是一棵完整的XML樹，被解析成一個存放在存儲器中的節(jié)點結(jié)構(gòu)，可以通過遍歷這棵樹獲取所有節(jié)點信息。它非常簡單易用，但是因為整棵樹存在于存儲器中造成存儲器的負擔。與DOM不同，Pull語法分析讓程序員從語法分析程序中"拉"出下一個事件，Pull語法分析使處理狀態(tài)改變更加容易，因為你可以發(fā)送分析器到不同的函數(shù)，維護它們自己的狀態(tài)變量。此外，Pull特別適用于J2ME環(huán)境中的需要保持盡可能地少的內(nèi)存占用的情況，因此我們采用Pull方法進行XML的解析。定義接口如下：

根據(jù)XML節(jié)點名稱獲取對應值：private String getXMLNodeValue(String nodeName)

6） 網(wǎng)絡通信模塊

在J2ME的MIDP 1.0 API中，網(wǎng)絡通信協(xié)議支持UDP、HTTP、Socket等等。雖然從理論上說可以使用Socket或UDP協(xié)議與外界進行通信，但是一些廠商的MIDP設備可能不支持這些協(xié)議，使用這些協(xié)議進行通信可能造成程序移植上的問題。而HTTP由于是當今互聯(lián)網(wǎng)最主要的通信協(xié)議，因此基本上所有廠商的移動終端設備都支持HTTP協(xié)議。因此我們采用HTTP協(xié)議進行通信。下面給出發(fā)送和接收數(shù)據(jù)的代碼：public String sendAndReceiveByHttp(String url, String strToSend) throws Exception

{

HttpConnection hc = (HttpConnection)Connector.open(url, Connector.READ_WRITE);

hc.setRequestMethod(HttpConnection.POST);

hc.setRequestProperty(“Connection”, “Keep-Alive”);

DataOutputStream dos = hc.openDataOutputStream();

dos.writeUTF(strToSend);//向目的URL發(fā)送數(shù)據(jù)

dos.flush();

dos.close();

DataInputStream dis = hc.openInputStream();

String strReceived = dis.readUTF();//接收目的URL的響應數(shù)據(jù)

dis.close();

return strReceived;

}

4、 J2EE服務器端的實現(xiàn)

服務器端包含一些重要的模塊，如多個對外接口，后臺管理子系統(tǒng)，商家自服務子系統(tǒng)，OTA下載等等。這里我們對那些與J2ME客戶端重復的功能模塊如XML解析、加密、簽名等等略去不提，而把重點放在服務器端的獨有的實現(xiàn)細節(jié)上。服務器端邏輯結(jié)構(gòu)圖3所示。

A：由2.3描述的移動支付交易流程的各個步驟。

B：用戶通過在網(wǎng)站或通過發(fā)送短信點播WapPush鏈接的方式，由OTA服務器提供MIDlet的下載。其中每個MIDlet都已經(jīng)內(nèi)嵌了RSA的私匙－公匙對，而這些密匙對是由RSA密匙對管理模塊維護的。

C：商家登錄自服務子系統(tǒng)進行注冊帳號，發(fā)布、修改或刪除商品的信息。

服務器端的主要模塊的實現(xiàn)如下：

1） 交易接口及交易流程管理模塊：交易接口是指移動支付流程中負責處理服務器端與外界交互的業(yè)務邏輯的模塊，包括了用戶交易接口、銀行交易接口和商家交易接口。用戶交易接口負責處理與J2ME客戶端的交互，銀行交易接口負責處理使用用戶指定的銀行卡扣費的業(yè)務邏輯，商家交易接口負責處理通知商家交易結(jié)果的業(yè)務邏輯。而這三個接口由交易流程管理模塊進行整體上的協(xié)調(diào)管理。我們設計了一個交易記錄表TradeHistory來記錄必要的交易信息。

2） Triple DES密匙管理模塊：J2ME客戶端用于加密的Triple DES共享密匙是由服務器端接收到交易請求后，由系統(tǒng)隨機產(chǎn)生的，并同時產(chǎn)生與之對應的密匙名稱，并由CarriedKeyName元素把名稱帶回給J2ME客戶端。之后，系統(tǒng)把密匙名稱和密匙都存放到數(shù)據(jù)庫，在下一次有用該密匙加密的數(shù)據(jù)需要解密時，才從數(shù)據(jù)庫中根據(jù)密匙名稱查找出密匙進行解密。系統(tǒng)通過表DESede_Keys來存放TripleDES密匙。

3） OTA下載模塊：用戶通過Wap Push進入到OTA服務器提供的MIDlet的下載鏈接，從而獲取到MIDlet應用。OTA下載模塊主要是需要對Resin服務器做一些相應的設置，以及獲取RSA密匙對嵌入MIDlet中。

4） RSA密匙對管理模塊：RSA私匙－公匙組成的密匙對可用Bouncy Castle密碼術(shù)包生成。生成了密匙對后，需要把密匙對的主要參數(shù)存儲到數(shù)據(jù)庫中，供OTA下載模塊獲取并分配給每個不同的MIDlet應用實例。系統(tǒng)通過表RSA_Key_Params來存儲RSA密匙對的主要參數(shù)。

5） 商家自服務子系統(tǒng)：商家自服務系統(tǒng)是提供給商家注冊基本資料和發(fā)布、編輯商品的一個Browser/Server架構(gòu)的子系統(tǒng)。該子系統(tǒng)通過以下兩個表來存儲相關(guān)信息：商家基本信息表Sale_Info和商品資料表Product_Info。

6） 后臺管理子系統(tǒng)：管理員可以使用后臺管理子系統(tǒng)進行平臺的各方面的設置，如增刪帳號，審批商家的注冊申請，監(jiān)督商品的發(fā)布情況，以及監(jiān)控交易的情況等等。

7） 數(shù)據(jù)庫訪問模塊：數(shù)據(jù)庫訪問模塊：不同于J2ME客戶端的數(shù)據(jù)庫訪問模塊，服務器的數(shù)據(jù)庫訪問模塊可以做的更加強大。為應付高強度的數(shù)據(jù)庫訪問操作，可以針對查詢和更新操作在程序這個級別上進行優(yōu)化。對查詢操作設立一個查詢結(jié)果的緩沖區(qū)，將最近查詢或查詢頻率較高的查詢結(jié)果保存在緩沖區(qū)內(nèi)，以便以后的查詢就可以直接訪問緩沖區(qū)（內(nèi)存）而不必每次進行數(shù)據(jù)庫操作；對于更新操作，采用緩寫機制，接收到更新操作的請求后不馬上訪問數(shù)據(jù)庫，而是放入緩沖區(qū)，等積累到一定數(shù)量的操作后進行數(shù)據(jù)庫操作的批處理，或是定時把緩沖區(qū)中的更新操作執(zhí)行掉一部分。

5、 結(jié)束語

本論文創(chuàng)新點：論文分析了移動支付系統(tǒng)的三種方案，提出了一種以第三方支付平臺為中心的移動支付系統(tǒng)架構(gòu)，并討論在J2ME環(huán)境下原型系統(tǒng)的客戶端及服務端的技術(shù)方案設計, 給出支付系統(tǒng)中的安全性解決方法。該系統(tǒng)經(jīng)實際測試，性能良好，可較好的解決安全性和易用性問題，是一種較佳的移動支付解決方案。

參考文獻
[1] Cay S.Horstmann，Gary Cornell，（譯）京京工作室，Java 2核心技術(shù)［M］，機械工業(yè)出版社，2001.6
[2] Paul Tremblett，（譯）王伯欣，J2ME無線Java應用開發(fā)［M］，人民郵電出版社，2002.9
[3] 盧軍，J2ME應用程序開發(fā)－手機、PDA程序開發(fā)捷徑［M］，中國鐵道出版社，2002.9
[4] 聞怡洋，J2ME MIDP 1.0/2.0無線設備編程指南［M］，北京大學出版社，2004.7
[5] Kim Topley，（譯）張伶，林琪，J2ME技術(shù)手冊［M］，中國電力出版社，2004.2
[6] 崔巖， 劉永杰，周玉潔，一種適用于移動電子商務的微支付方案[J]， 計算機工程與應用， 2005年 第 41卷 第35期，P125-128
[7] 陳思，何煒，居悌;基于開放服務架構(gòu)的移動支付平臺[J]， 計算機工程, 2003年 第29卷 第20期，P165-168
[8] 何國輝, 甘俊英, 基于手機的移動電子商務應用研究[J], 微計算機信息， 2006年第22卷 第2-3期，P137-139