摘要：移动支付是移动电子商务中的最重要的部分之一。安全性、私密性、易用性是移动支付的最重要的几个问题。目前有许多不同种类的技术能够实现移动支付，其中J2ME凭借其多种显著的优势成为了佼佼者。移动支付系统也有多种体系架构，其中以第三方支付平台为中心的架构比较灵活、具有很强的可扩展性。本文讨论一个基于J2ME的以第三方支付平台为中心的移动支付系统的特点和优越性，并给出这个系统详细的设计与实现过程。

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的密匙。

数字签名解决以下问题：

l 鉴权：由于私匙与公匙是一一对应的，并且私匙只有用户才能够持有，因此实际上私匙成为了用户的身份的唯一标志，就像一般的用户名/密码一样可以在鉴权过程中识别用户身份。

l 数据完整性：数据完整性主要是保证内容不被篡改。在数字签名的流程中，接收方在收到签名及其原始消息后，会按照消息原文再生成一次摘要，然后与用公匙解密的摘要进行对比验证。因此即使入侵者修改了原文，也会因为无法通过对比验证而达不到破坏的目的。

l 不可否认性：因为特定的签名信息只能由某个用户通过私匙进行签名，而不能由任何其他人实现，因此用户无法否认经过自己签名的信息。

这里选择XML作为客户端与服务器通信的数据载体。使用XML不但可以以清晰的逻辑表示复杂的嵌套的数据结构，而且因为XML是当今互联网的主流的通信接口的标准，有很好的兼容性与扩展性。所以我们将使用XML加密与XML签名解决本系统的安全性问题。

3、J2ME客户端的实现

整个J2ME客户端的逻辑架构是由若干个功能模块组成的，这些功能模块覆盖了网络通信、用户界面、安全等各个方面的职能，并通过模块间的通信共同实现了移动支付系统客户端的功能。

逻辑结构如图2所示，其中A～F的意义如下：

A：用户请求交易 / 交易操作结果

B：用户输入的交易请求信息 / 服务器端返回的交易结果

C：经过XML加密的请求信息/ 经过XML签名认证的返回结果

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进行操作，并对外部模块提供了两个存取数据的接口：

l 按名称保存数据到RMS的接口：public void setDataToRecordStore(String name, String data)

l 按名称从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类来处理所有加密/解密的相关的问题。定义的接口如下：

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

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

4） XML签名/验证模块

XML签名过程中，首先生成原始数据的摘要，再对摘要进行签名。生成摘要的算法一般使用SHA1算法。Bouncy Castle API包同样提供了生成签名用的摘要的SHA1Digest类，以及用于数字签名的RSAEngine、PSSSigner等类。我们定义Signature类封装所有的处理签名的功能代码。定义的接口如下：

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

l 使用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的解析。定义接口如下：

l 根据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解析、加密、签名等等略去不提，而把重点放在服务器端的独有的实现细节上。

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环境下原型系统的客户端及服务端的技术方案设计, 给出支付系统中的安全性解决方法。该系统经实际测试，性能良好，可较好的解决安全性和易用性问题，是一种较佳的移动支付解决方案。