一種基于J2ME的移動支付系統(tǒng)的設計與實現
摘要：移動支付是移動電子商務中的最重要的部分之一。安全性、私密性、易用性是移動支付的最重要的幾個問題。目前有許多不同種類的技術能夠實現移動支付，其中J2ME憑借其多種顯著的優(yōu)勢成為了佼佼者。移動支付系統(tǒng)也有多種體系架構，其中以第三方支付平臺為中心的架構比較靈活、具有很強的可擴展性。本文討論一個基于J2ME的以第三方支付平臺為中心的移動支付系統(tǒng)的特點和優(yōu)越性，并給出這個系統(tǒng)詳細的設計與實現過程。
關鍵詞：移動支付; J2ME; XML加密; XML簽名
1、 引言
當前移動付費已經相當普及，并受到來自銀行、零售業(yè)等移動行業(yè)以外企業(yè)的關注。移動支付是指交易雙方為通過手機、PDA、移動PC等移動設備進行商業(yè)交易。
移動支付根據涉及的金額的不同，一般可以分為以下兩類：
1）微支付（小額支付）：微支付是指交易額少于10美元，通常是指購買移動內容業(yè)務。
2）宏支付：宏支付是指交易金額較大的支付行為。
對于宏支付方式來說，通過可靠的金融機構進行交易鑒權是非常必要的；而對于微支付來說，使用移動網絡本身的SIM卡鑒權機制就能夠達到較高的安全性了。
與傳統(tǒng)支付方式的比較，移動支付的最大特點是交易靈活，方便快捷。但由于安全性和易用性問題未得到很好的解決，目前國內的移動支付主要是小額支付為主。目前能夠實現移動支付的技術從理論上來說有很多，如SMS、WAP、J2ME等增值服務技術均能夠滿足移動支付業(yè)務的基本需要。其中J2ME憑借其可移植性、強大的JDK支持等等顯著的優(yōu)勢成為了未來移動支付技術的首選。
2、 系統(tǒng)的分析與設計
2．1 移動支付系統(tǒng)的基本組成部分
移動支付系統(tǒng)一般可以分為以下基本組成部分：
1） 移動運營商：移動運營商的主要任務是為移動支付提供通信渠道。
2） 金融機構：一般是銀行，為用戶、商家之間的交易提供了不使用現金的渠道。
3） 移動支付平臺提供商：第三方移動支付平臺提供商是運營商和金融機構之間的銜接環(huán)節(jié)。
4） 用戶商家。
2．2 以第三方移動支付平臺為中心的設計模式
目前，移動支付系統(tǒng)的設計模式主要有以下三種：
1） 以移動運營商為中心的設計模式；
2） 以銀行為中心的設計模式；
3） 以第三方移動支付平臺提供商為中心的設計模式。
其中，以第三方移動支付平臺提供商為中心的設計模式如圖1所示，它具有簡單、便捷、跨領域操作等另外兩種設計模式所不具備優(yōu)點。
2．3 移動支付系統(tǒng)運作流程
以第三方移動支付平臺提供商為中心的移動支付系統(tǒng)的運作流程如下：
1） 用戶發(fā)交易短信到移動支付平臺提供商的服務號；
2） 支付平臺收到短信后進行服務識別，并向用戶回復確認消息；
3） 用戶收到確認短信后回復，確認此次交易；
4） 支付平臺收到確認短信后，根據商品編號、價格以及相關注冊信息等查詢到用戶的銀行卡號碼；
5） 支付平臺嘗試向銀行發(fā)出扣費請求，如果扣費成功則轉入6），否則下發(fā)短信給用戶提示交易失?。?/P>
6） 扣費成功，向用戶發(fā)送確認短信，同時告知相關移動支付系統(tǒng)交易成功，交易結束。
2．4 系統(tǒng)實現的重點
1） 安全性問題
由于無線網絡本身幾乎不提供安全保護措施，因此移動支付過程中可能受到多種的攻擊行為。要實現安全的無線交易，必須要解決以下幾個問題：
•鑒權（Authentication）：通信雙方必須標識其本身，沒有經過鑒權的通信方將不能夠進行下一步操作。
•數據完整性（Integrity）：確保交易他方或非法入侵者不能對交易的內容進行修改，從而保證通信中的接收方收到的是原文。
•數據機密性（Confidentiality）：防止合法或隱私數據為非法用戶所獲得，從而確保在交易過程中只有交易的雙方才能唯一知道交易的內容。
•不可否認性（Non－repudiation）：確保交易行為正確性，交易雙方均不能否認交易行為產生的事實。
2） 開發(fā)移動終端設備的應用程序的限制
開發(fā)移動終端設備的應用程序要受到多種條件的限制如：芯片處理能力弱，存儲空間小，堆內存小，屏幕尺寸有限，按鍵少，網絡帶寬不足等。
2．5 安全性問題解決方法
要保護通信安全，實現安全的無線交易，必須要解決通信過程中的鑒權，數據完整性，數據機密性和不可否認性這幾個問題。而數據加密和數字簽名兩種安全措施的利器正好可以達到這個目的。
數據加密的方式多種多樣，如使用已經很成熟的SSL/TLS和HTTPS對網絡連接進行加密，從而保護數據。此外其加密算法也同樣有很多的選擇，常用的有Triple DES、RSA等等算法。系統(tǒng)采用Triple DES來加密傳輸的機密數據，RSA算法來加密Triple DES的密匙。
數字簽名解決以下問題：
鑒權：由于私匙與公匙是一一對應的，并且私匙只有用戶才能夠持有，因此實際上私匙成為了用戶的身份的唯一標志，就像一般的用戶名/密碼一樣可以在鑒權過程中識別用戶身份。
數據完整性：數據完整性主要是保證內容不被篡改。在數字簽名的流程中，接收方在收到簽名及其原始消息后，會按照消息原文再生成一次摘要，然后與用公匙解密的摘要進行對比驗證。因此即使入侵者修改了原文，也會因為無法通過對比驗證而達不到破壞的目的。
不可否認性：因為特定的簽名信息只能由某個用戶通過私匙進行簽名，而不能由任何其他人實現，因此用戶無法否認經過自己簽名的信息。
這里選擇XML作為客戶端與服務器通信的數據載體。使用XML不但可以以清晰的邏輯表示復雜的嵌套的數據結構，而且因為XML是當今互聯網的主流的通信接口的標準，有很好的兼容性與擴展性。所以我們將使用XML加密與XML簽名解決本系統(tǒng)的安全性問題。
3、 J2ME客戶端的實現
整個J2ME客戶端的邏輯架構是由若干個功能模塊組成的，這些功能模塊覆蓋了網絡通信、用戶界面、安全等各個方面的職能，并通過模塊間的通信共同實現了移動支付系統(tǒng)客戶端的功能。
邏輯結構如圖2所示，其中A～F的意義如下：
A：用戶請求交易 / 交易操作結果
B：用戶輸入的交易請求信息 / 服務器端返回的交易結果
|
|
D：經過XML簽名的已加密請求信息 / 解析過的XML返回結果
E：組裝好的經過XML簽名的已加密請求信息的XML數據包 / 網絡通信模塊接收到的XML數據包
F：發(fā)向服務器的XML數據包 / 接收到的來自服務器的XML數據包
黑色雙箭頭所表示的是J2ME特有的RMS數據庫的數據。數據庫訪問模塊負責調用J2ME的RMS數據庫的功能接口，對用戶界面模塊用的個性化設置，XML加密和簽名用的私匙和公匙對，網絡通信模塊用的HTTP訪問地址和設置等等數據進行存取，而其它模塊則通過訪問數據庫模塊存取所需數據。
在客戶端系統(tǒng)的實現中，使用了一些第三方API庫：kXML和Bouncy Castle API。其中kXML是XML組裝/解析的工具，而Bouncy Castle API是J2ME應用程序專用的XML加密/解密和簽名/驗證的工具。
客戶端部分的主要模塊實現如下：
1） 數據庫訪問模塊
數據庫訪問模塊是所有其它模塊需要用到的模塊，這是因為它把整個J2ME客戶端需要用到的程序配置和用戶設置存取到J2ME的數據庫中。在J2ME MIDP中定義了一個簡單的基于記錄的數據庫管理系統(tǒng)（Record Management System，RMS），在RMS中Record Store等同于一般數據庫系統(tǒng)中的表（Table），它是記錄了一系列記錄的文件。
數
據庫訪問模塊對RMS進行操作，并對外部模塊提供了兩個存取數據的接口：
按名稱保存數據到RMS的接口：public void setDataToRecordStore(String name, String data)
按名稱從RMS獲取數據的接口：public String getDataFromRecordStore(String name)
2） 用戶界面模塊
用戶界面模塊實現人機交互工能，接收用戶輸入，并把操作結果以友善的形式進行輸出。除了使用J2ME提供的Display、Screen、Label、Command、Alert、Form、TextField等高級用戶界面控件外，還需要使用J2ME提供的Canvas、Image等等低級用戶界面API，來實現動畫等特效。
3） XML加密/解密模塊
這兩個模塊負責對服務器端傳來的用RSA算法公匙加密的共享密匙進行解密，然后用共享密匙對機密信息使用Triple DES算法進行加密。
通過使用Bouncy Castle API密碼術包，我們可以輕松地對所需要傳輸的交易請求里面的機密信息進行XML加密和解密。它所提供的org.bouncycastle.crypto包有加密/解密中需要用到的絕大部分的類，另外org.bouncycastle.util包提供了包括Base64編碼轉換、Hex編碼轉換等有用的工具類。在Bouncy Castle API中，公匙、私匙和共享密匙都是對象，在試圖使用它們之前，必須要通過它們的主要參數重構出這些密匙對象。RSA的公匙有Modulus和Exponent兩個主要參數，RSA私匙除了這兩個參數外，還有privExp、dp、dq、p、q、qInv等幾個參數，而Triple DES共享密匙只有單一的key參數。在傳遞這些密匙參數或加密的相關信息時，由于XML加密的很多元素指定使用Base64編碼，因此還需要用到Base64這個工具類。我們定義了一個Encryptor類來處理所有加密/解密的相關的問題。定義的接口如下：
TripleDES加密接口：public byte[] encryptTripleDES (byte[] data) throws CryptoException
RSA解密接口：public synchronized byte[] decryptRSA(byte[] data) throws CryptoException
4） XML簽名/驗證模塊
XML簽名過程中，首先生成原始數據的摘要，再對摘要進行簽名。生成摘要的算法一般使用SHA1算法。Bouncy Castle API包同樣提供了生成簽名用的摘要的SHA1Digest類，以及用于數字簽名的RSAEngine、PSSSigner等類。我們定義Signature類封裝所有的處理簽名的功能代碼。定義的接口如下：
生成摘要：private byte[] getDigest(String mesg) throws Exception
使用RSA私匙簽名：public byte[] RSASign(byte[] toSign) throws Exception
5） XML組裝/解析模塊
為了簡化問題，XML組裝可以使用簡單的字符串拼接來實現，而對于XML解析工作，我們使用kXML來處理。它是一個只占很小存儲空間的XML語法分析程序，對于J2ME應用程序非常適合。
kXML有一個非常獨特的DOM操作方法和被稱為Pull的語法分析方法。DOM是一個與XML相互作用的簡單方法，通常這個XML是一棵完整的XML樹，被解析成一個存放在存儲器中的節(jié)點結構，可以通過遍歷這棵樹獲取所有節(jié)點信息。它非常簡單易用，但是因為整棵樹存在于存儲器中造成存儲器的負擔。與DOM不同，Pull語法分析讓程序員從語法分析程序中"拉"出下一個事件，Pull語法分析使處理狀態(tài)改變更加容易，因為你可以發(fā)送分析器到不同的函數，維護它們自己的狀態(tài)變量。此外，Pull特別適用于J2ME環(huán)境中的需要保持盡可能地少的內存占用的情況，因此我們采用Pull方法進行XML的解析。定義接口如下：
根據XML節(jié)點名稱獲取對應值：private String getXMLNodeValue(String nodeName)
6） 網絡通信模塊
在J2ME的MIDP 1.0 API中，網絡通信協(xié)議支持UDP、HTTP、Socket等等。雖然從理論上說可以使用Socket或UDP協(xié)議與外界進行通信，但是一些廠商的MIDP設備可能不支持這些協(xié)議，使用這些協(xié)議進行通信可能造成程序移植上的問題。而HTTP由于是當今互聯網最主要的通信協(xié)議，因此基本上所有廠商的移動終端設備都支持HTTP協(xié)議。因此我們采用HTTP協(xié)議進行通信。下面給出發(fā)送和接收數據的代碼：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ā)送數據
dos.flush();
dos.close();
DataInputStream dis = hc.openInputStream();
String strReceived = dis.readUTF();//接收目的URL的響應數據
dis.close();
return strReceived;
}
4、 J2EE服務器端的實現
服務器端包含一些重要的模塊，如多個對外接口，后臺管理子系統(tǒng)，商家自服務子系統(tǒng)，OTA下載等等。這里我們對那些與J2ME客戶端重復的功能模塊如XML解析、加密、簽名等等略去不提，而把重點放在服務器端的獨有的實現細節(jié)上。服務器端邏輯結構圖3所示。
A：由2.3描述的移動支付交易流程的各個步驟。
B：用戶通過在網站或通過發(fā)送短信點播WapPush鏈接的方式，由OTA服務器提供MIDlet的下載。其中每個MIDlet都已經內嵌了RSA的私匙－公匙對，而這些密匙對是由RSA密匙對管理模塊維護的。
C：商家登錄自服務子系統(tǒng)進行注冊帳號，發(fā)布、修改或刪除商品的信息。
服務器端的主要模塊的實現如下：
1） 交易接口及交易流程管理模塊：交易接口是指移動支付流程中負責處理服務器端與外界交互的業(yè)務邏輯的模塊，包括了用戶交易接口、銀行交易接口和商家交易接口。用戶交易接口負責處理與J2ME客戶端的交互，銀行交易接口負責處理使用用戶指定的銀行卡扣費的業(yè)務邏輯，商家交易接口負責處理通知商家交易結果的業(yè)務邏輯。而這三個接口由交易流程管理模塊進行整體上的協(xié)調管理。我們設計了一個交易記錄表TradeHistory來記錄必要的交易信息。
2） Triple DES密匙管理模塊：J2ME客戶端用于加密的Triple DES共享密匙是由服務器端接收到交易請求后，由系統(tǒng)隨機產生的，并同時產生與之對應的密匙名稱，并由CarriedKeyName元素把名稱帶回給J2ME客戶端。之后，系統(tǒng)把密匙名稱和密匙都存放到數據庫，在下一次有用該密匙加密的數據需要解密時，才從數據庫中根據密匙名稱查找出密匙進行解密。系統(tǒng)通過表DESede_Keys來存放TripleDES密匙。
3） OTA下載模塊：用戶通過Wap Push進入到OTA服務器提供的MIDlet的下載鏈接，從而獲取到MIDlet應用。OTA下載模塊主要是需要對Resin服務器做一些相應的設置，以及獲取RSA密匙對嵌入MIDlet中。
4） RSA密匙對管理模塊：RSA私匙－公匙組成的密匙對可用Bouncy Castle密碼術包生成。生成了密匙對后，需要把密匙對的主要參數存儲到數據庫中，供OTA下載模塊獲取并分配給每個不同的MIDlet應用實例。系統(tǒng)通過表RSA_Key_Params來存儲RSA密匙對的主要參數。
5） 商家自服務子系統(tǒng)：商家自服務系統(tǒng)是提供給商家注冊基本資料和發(fā)布、編輯商品的一個Browser/Server架構的子系統(tǒng)。該子系統(tǒng)通過以下兩個表來存儲相關信息：商家基本信息表Sale_Info和商品資料表Product_Info。
6） 后臺管理子系統(tǒng)：管理員可以使用后臺管理子系統(tǒng)進行平臺的各方面的設置，如增刪帳號，審批商家的注冊申請，監(jiān)督商品的發(fā)布情況，以及監(jiān)控交易的情況等等。
7） 數據庫訪問模塊：數據庫訪問模塊：不同于J2ME客戶端的數據庫訪問模塊，服務器的數據庫訪問模塊可以做的更加強大。為應付高強度的數據庫訪問操作，可以針對查詢和更新操作在程序這個級別上進行優(yōu)化。對查詢操作設立一個查詢結果的緩沖區(qū)，將最近查詢或查詢頻率較高的查詢結果保存在緩沖區(qū)內，以便以后的查詢就可以直接訪問緩沖區(qū)（內存）而不必每次進行數據庫操作；對于更新操作，采用緩寫機制，接收到更新操作的請求后不馬上訪問數據庫，而是放入緩沖區(qū)，等積累到一定數量的操作后進行數據庫操作的批處理，或是定時把緩沖區(qū)中的更新操作執(zhí)行掉一部分。
5、 結束語
本論文創(chuàng)新點：論文分析了移動支付系統(tǒng)的三種方案，提出了一種以第三方支付平臺為中心的移動支付系統(tǒng)架構，并討論在J2ME環(huán)境下原型系統(tǒng)的客戶端及服務端的技術方案設計, 給出支付系統(tǒng)中的安全性解決方法。該系統(tǒng)經實際測試，性能良好，可較好的解決安全性和易用性問題，是一種較佳的移動支付解決方案。
參考文獻
[1] Cay S.Horstmann，Gary Cornell，（譯）京京工作室，Java 2核心技術［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技術手冊［M］，中國電力出版社，2004.2
[6] 崔巖， 劉永杰，周玉潔，一種適用于移動電子商務的微支付方案[J]， 計算機工程與應用， 2005年 第 41卷 第35期，P125-128
[7] 陳思，何煒，居悌;基于開放服務架構的移動支付平臺[J]， 計算機工程, 2003年 第29卷 第20期，P165-168
[8] 何國輝, 甘俊英, 基于手機的移動電子商務應用研究[J], 微計算機信息， 2006年第22卷 第2-3期，P137-139
下載文檔
