一種基于J2ME的移動(dòng)支付系統的設計與實(shí)現

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

1、 引言

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

移動(dòng)支付根據涉及的金額的不同，一般可以分為以下兩類(lèi)：

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

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

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

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

2、 系統的分析與設計

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

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

1） 移動(dòng)運營(yíng)商：移動(dòng)運營(yíng)商的主要任務(wù)是為移動(dòng)支付提供通信渠道。

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

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

4） 用戶(hù)商家。

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

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

1） 以移動(dòng)運營(yíng)商為中心的設計模式；

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

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

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

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

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

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

2） 支付平臺收到短信后進(jìn)行服務(wù)識別，并向用戶(hù)回復確認消息；

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

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

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

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

2．4 系統實(shí)現的重點(diǎn)

1） 安全性問(wèn)題

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

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

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

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

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

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

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

2．5 安全性問(wèn)題解決方法

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

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

數字簽名解決以下問(wèn)題：

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

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

不可否認性：因為特定的簽名信息只能由某個(gè)用戶(hù)通過(guò)私匙進(jìn)行簽名，而不能由任何其他人實(shí)現，因此用戶(hù)無(wú)法否認經(jīng)過(guò)自己簽名的信息。

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

3、 J2ME客戶(hù)端的實(shí)現

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

邏輯結構如圖2所示，其中A～F的意義如下：

A：用戶(hù)請求交易 / 交易操作結果

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

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

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

F：發(fā)向服務(wù)器的XML數據包 / 接收到的來(lái)自服務(wù)器的XML數據包

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

在客戶(hù)端系統的實(shí)現中，使用了一些第三方API庫：kXML和Bouncy Castle API。其中kXML是XML組裝/解析的工具，而B(niǎo)ouncy Castle API是J2ME應用程序專(zhuān)用的XML加密/解密和簽名/驗證的工具。

客戶(hù)端部分的主要模塊實(shí)現如下：

1） 數據庫訪(fǎng)問(wèn)模塊

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

數據庫訪(fǎng)問(wèn)模塊對RMS進(jìn)行操作，并對外部模塊提供了兩個(gè)存取數據的接口：

按名稱(chēng)保存數據到RMS的接口：public void setDataToRecordStore(String name, String data)

按名稱(chēng)從RMS獲取數據的接口：public String getDataFromRecordStore(String name)

2） 用戶(hù)界面模塊

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

3） XML加密/解密模塊

這兩個(gè)模塊負責對服務(wù)器端傳來(lái)的用RSA算法公匙加密的共享密匙進(jìn)行解密，然后用共享密匙對機密信息使用Triple DES算法進(jìn)行加密。

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

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

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

4） XML簽名/驗證模塊

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

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

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

5） XML組裝/解析模塊

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

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

根據XML節點(diǎn)名稱(chēng)獲取對應值：private String getXMLNodeValue(String nodeName)

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

在J2ME的MIDP 1.0 API中，網(wǎng)絡(luò )通信協(xié)議支持UDP、HTTP、Socket等等。雖然從理論上說(shuō)可以使用Socket或UDP協(xié)議與外界進(jìn)行通信，但是一些廠(chǎng)商的MIDP設備可能不支持這些協(xié)議，使用這些協(xié)議進(jìn)行通信可能造成程序移植上的問(wèn)題。而HTTP由于是當今互聯(lián)網(wǎng)最主要的通信協(xié)議，因此基本上所有廠(chǎng)商的移動(dòng)終端設備都支持HTTP協(xié)議。因此我們采用HTTP協(xié)議進(jìn)行通信。下面給出發(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服務(wù)器端的實(shí)現

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

A：由2.3描述的移動(dòng)支付交易流程的各個(gè)步驟。

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

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

服務(wù)器端的主要模塊的實(shí)現如下：

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

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

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

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

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

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

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

5、 結束語(yǔ)

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

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