一种基于J2ME的移动支付系统的设计与实现

http://www.51eda.com/Article/electech/consumption/200705/9476.html 摘要：移动支付是移动电子商务中的最重要的部分之一。安全性、私密性、易用性是移动支付的最重要的几个问题。目前有许多不同种类的技术能够实现移动支付，其中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） 扣费成功，向用户发送确认短信，同时告知相关移动支付系统交易成功，交易结束。 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：用户输入的交易请求信息 / 服务器端返回的交易结果 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进行操作，并对外部模块提供了两个存取数据的接口： 按名称保存数据到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类封装所有的处理签名的功能代码。定义的接口如下： 生成摘要�