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

1、 引言

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

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

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

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

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

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

2、 系統的分析與設計

2．1 移動支付系統的基本組成部分

移動支付系統一般可以分為以下基本組成部分：

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

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

3） 移動支付平臺提供商：第三方移動支付平臺提供商是運營商和金融機構之間的銜接環節。

4） 用戶商家。

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

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

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

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

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

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

2．3 移動支付系統運作流程

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

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

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

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

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

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

6） 扣費成功，向用戶發送確認短信，同時告知相關移動支付系統交易成功，交易結束。

2．4 系統實現的重點

1） 安全性問題

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

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

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

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

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

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

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

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

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

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

數字簽名解決以下問題：

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

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

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

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

3、 J2ME客戶端的實現

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

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

A：用戶請求交易 / 交易操作結果

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

D：經過XML簽名的已加密請求信息 / 解析過的XML返回結果

E：組裝好的經過XML簽名的已加密請求信息的XML數據包 / 網絡通信模塊接收到的XML數據包

F：發向服務器的XML數據包 / 接收到的來自服務器的XML數據包

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

在客戶端系統的實現中，使用了一些第三方API庫：kXML和Bouncy Castle API。其中kXML是XML組裝/解析的工具，而Bouncy Castle API是J2ME應用程序專用的XML加密/解密和簽名/驗證的工具。

客戶端部分的主要模塊實現如下：

1） 數據庫訪問模塊

數據庫訪問模塊是所有其它模塊需要用到的模塊，這是因為它把整個J2ME客戶端需要用到的程序配置和用戶設置存取到J2ME的數據庫中。在J2ME MIDP中定義了一個簡單的基于記錄的數據庫管理系統（Record Management System，RMS），在RMS中Record Store等同于一般數據庫系統中的表（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樹，被解析成一個存放在存儲器中的節點結構，可以通過遍歷這棵樹獲取所有節點信息。它非常簡單易用，但是因為整棵樹存在于存儲器中造成存儲器的負擔。與DOM不同，Pull語法分析讓程序員從語法分析程序中"拉"出下一個事件，Pull語法分析使處理狀態改變更加容易，因為你可以發送分析器到不同的函數，維護它們自己的狀態變量。此外，Pull特別適用于J2ME環境中的需要保持盡可能地少的內存占用的情況，因此我們采用Pull方法進行XML的解析。定義接口如下：

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

6） 網絡通信模塊

在J2ME的MIDP 1.0 API中，網絡通信協議支持UDP、HTTP、Socket等等。雖然從理論上說可以使用Socket或UDP協議與外界進行通信，但是一些廠商的MIDP設備可能不支持這些協議，使用這些協議進行通信可能造成程序移植上的問題。而HTTP由于是當今互聯網最主要的通信協議，因此基本上所有廠商的移動終端設備都支持HTTP協議。因此我們采用HTTP協議進行通信。下面給出發送和接收數據的代碼：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發送數據

dos.flush();

dos.close();

DataInputStream dis = hc.openInputStream();

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

dis.close();

return strReceived;

}

4、 J2EE服務器端的實現

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

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

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

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

服務器端的主要模塊的實現如下：

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

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

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

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

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

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

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

5、 結束語

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

參考文獻
[1] Cay S.Horstmann，Gary Cornell，（譯）京京工作室，Java 2核心技術［M］，機械工業出版社，2001.6
[2] Paul Tremblett，（譯）王伯欣，J2ME無線Java應用開發［M］，人民郵電出版社，2002.9
[3] 盧軍，J2ME應用程序開發－手機、PDA程序開發捷徑［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