四川大学软件工程硕士专业学位论文(设计)范本 题目:基于PKI技术的网上安全支付原型系统设计与实现 作者: 完成日期:2007年 8 月 10 日 培养单位 四 川 大 学 指导教师 指导教师 高级工程师 工程领域 软件工程 授予学位日期 年 月 日 基于PKI技术的网上安全支付原型系统设计
工程领域:软件工程 研究生 指导教师 摘 要 随着电子商务的应用发展,网上支付已经成为必然。针对网上安全支付技术,世界范围内提出了许许多多的理论模式和解决方案,这些理论与方案在不同的国家和地理范围内也有其独特的发展和应用。论文在深入研究网上支付理论和解决方案的基础上,对适合我国国情的安全支付技术进行了探讨。 作者受单位指派参与项目论证,方案设计,以及工程实施的整个过程后,经总结而形成本论文,论文所设计和实现的网上安全支付原型系统采用基于公钥基础设施的体系结构,遵循和参照国际上先进的安全电子交易协议SET1.0/2.0、抽象语法标记语言ASN.1等标准,以有效性、机密性、完整性、可靠性为设计原则,基于JDK1.2及以上版本开发,所实现的原型系统由电子钱包、支付服务器、支付网关等部分组成,并给出了商家服务器、银行网络的接口和出口。论文分别描述了该系统的运作原理、标准和流程,并提交了相应程序代码。 论文所设计和实现的网上安全支付原型系统设计与同类产品设计相比,具有以下特点:基于PKI安全体系结构,拥有自主版权的可信PKI安全平台;采用PKI DISA数字信息安全助理存储证书,用户使用更加安全、方便;公网消息格式遵循SET1.0/2.0、ASN.1、HTTP1.0和MIME1.0规范,与金融网络通信的消息格式遵循ISO8583规范,保证了系统的通用性;一个支付网关可以与多个银行系统连接,多个支付网关可以并行处理,提高了系统的利用率和可扩展性。突出强化支付监管功能,易于实现业务管理。 关键词: PKI、电子支付、支付网关、支付服务器、电子钱包 Design of Online Secure Payment Prototype System Based on PKI Technology Field: Software Engineering Graduate Student: WuPeng Supervisor:FangYong ZhaoHuaTing
Abstract As the development of e-commerce application, online payment has become inevitable. A lot of theoretical models and solutions have been brought forward for online secure payment technology in worldwide area. They have their unique development and application in different countries and geographical areas. On the basis of in-depth research on online payment theory and solutions, my paper discuss the secure payment technology which is suitable for China's national conditions. Assigned by my company, I have involved in project feasibility studies, program design and the entire process of the implementation of the project. After summing up the project, I finished this paper. A online secure payment prototype system has been designed and realized in it. The system based on the Public Key Infrastructure Architecture, followed and referred to the advanced international Secure Electronic Transaction protocol SET1.0/2.0, Abstract Syntax Notation Language ASN.1 and other standards. It kept to the design principles of validity, confidentiality, integrity and reliability and developed on JDK1.2 and above versions. The prototype system consisted of electronic wallet, payment servers, payment gateway and other components. Further, it gived the interface and exit of merchant servers and bank network. This paper described the operation principle, standards and processes of the system and then submitted the correspondence program code. Compared with the similar product, the design of our online secure payment prototype system has the the following features: first it based on PKI security architecture and owned credible PKI security platform of independent copyright; Second, it adopted PKI DISA digital information security assistant store certificate which makes it more safe and convenient for users; third the message format of public network followed SET1.0/2.0, ASN.1, HTTP1.0 and MIME1.0 norms while the financial network message format kept to ISO8583 standard, ensuring the generality of the system; last, a payment gateway can connect with a number of banking system and many payment gateways can make parallel processing which increased system’s utilization and scalability. In a word, our system gives prominence to payment management funtion and is easy to realize operation management. KeyWords: PKI; electronic payment; payment gateway; payment server; electronic wallet 目 录 第1章绪 论1 1.1网上安全支付技术的理论与实践情况以及发展现状1 1.1.1现有电子商务交易协议分析1 1.1.2在线交易主要模式分析3 1.1.3现阶段我国网上安全支付技术的发展情况6 1.2对电子商务安全问题的探讨7 1.2.1有效性7 1.2.2机密性7 1.2.3完整性7 1.2.4可靠性/抗抵赖性/鉴别8 1.2.5可审计性8 1.3论文的主要工作8 第2章系统总体设计10 2.1系统体系结构设计目标和适用范围10 2.1.1设计目标10 2.1.2适用范围10 2.2系统的运行环境和要求11 2.2.1运行环境11 2.2.2系统要求11 2.3系统体系结构11 2.3.1系统说明12 2.3.2角色组成12 2.3.3关系描述13 2.3.4系统架构15 2.3.5层次模型16 2.4体系业务流程17 2.4.1SET认证流程17 2.4.2SET交易流程20 第3章PKI接口及数据封装层设计24 3.1概述24 3.1.1功能概述24 3.1.2结构概述24 3.2PKI接口24 3.2.1支付规范要求24 3.2.2本系统实现31 3.3数据封装31 3.3.1说明31 3.3.2ASN.1规范32 第4章支付协议层设计33 4.1概述33 4.2采用和支持的消息对34 4.2.1支付初始化消息对(PinitReq/PinitRes)34 4.2.2支付消息对(PReq/PRes)34 4.2.3查询消息对(InqReq/InqRes)34 4.2.4认证授权消息对(AuthReq/AuthRes)35 4.2.5退款请求消息对(CredReq/CredRes)35 4.3典型数据结构36 4.3.1TransIDs36 4.3.2PI (Payment Instruction)39 4.3.3主账号数据(PANData)43 4.3.4详细销售(SaleDetail)44 4.3.5请求和响应消息标签(RRTags)51 4.3.6金额数据区(Amount Fields)51 4.3.7日期数据(Date Fields)52 4.4消息的一般流程52 4.5消息结构55 4.5.1消息封装(Message Wrapper)55 4.5.2初始化消息57 4.6数据封装与分解58 4.7支付协议层的结构与实现58 4.7.1支付协议层的基本结构58 4.7.2支付协议层的结构实现59 4.7.3支付协议层与其它各层之间的关系与接口59 第5章支付网关设计60 5.1概述60 5.2支付网关体系结构60 5.3授权服务(AUTHORIZATION SERVICE)60 5.4付款服务(CAPTURE SERVICE)61 5.5退款服务(CREDIT REQUEST)61 5.6查询服务62 5.7统计服务62 5.8配置服务62 5.8.1证书管理62 5.8.2数据库连接管理62 5.8.3系统启动管理62 第6章支付服务器设计67 6.1概述67 6.2软件体系结构67 6.2.1对象/软总线结构67 6.2.2各请求模块结构68 6.3各服务的功能与处理68 6.3.1商家订单服务68 6.3.2支付过程初始化服务68 6.3.3支付初始化服务(Payment Init Service)68 6.3.4支付服务(Purchase Service)68 6.3.5查询服务(Inquery Service)69
[1][2][3][4][5] 6.3.6退款服务(Credit Service)69 6.3.7商家查询服务69 6.3.8统计服务69 6.3.9配置服务69 第7章电子钱包设计71 7.1概述71 7.2电子钱包体系结构71 7.3支付管理器72 7.4支付卡管理模块72 7.5交易管理模块73 7.6用户管理模块73 7.7电子钱包支付管理器模块设计与实现73 7.7.1支付/查询操作函数73 7.7.2信息显示函数74 7.7.3支付初始化消息74 7.7.4支付请求接口函数程序片断79 第8章结束语85 参考文献86 致谢88 声明89
第1章 绪 论 1.1 网上安全支付技术的理论与实践情况以及发展现状 针对网上安全支付技术,世界范围内提出了许许多多的理论模式和解决方案,这些理论与方案在不同的国家和地理范围内也有其独特的发展和应用。因此,有必要对它们进行全面彻底的研究,才能保证开发出适合我国国情的安全支付技术。 1.1.1 现有电子商务交易协议分析 随着电子商务的兴起,人们已经研究了许多电子商务协议,已经实现的主要有Digicash、FirstVirtual、SSL、SET,但是目前常用的是SSL和SET[1]。 1. Digicash是一个匿名的数字现金协议。 所谓匿名,是指消费者在消费中不会暴露其身份,例如现金交易(虽然钞票有号码,但交易中一般不会加以记录)。该协议的步骤如下[1][2]: (1) 消费者从银行取款,他收到一个加密的数字标记(Token),此Token可当钱用; (2) 消费者对该Token作加密变换,使之仍能被商家检验其有效性,但已不能追踪消费者的身份; (3) 消费者在某商家消费时,可以使用该Token购物或购买服务,消费者可以进一步对该Token用密码变换以纳入商家的身份; (4) 商家检验该Token以确认以前未收到过此Toekn; (5) 商家给消费者发货; (6) 商家将该电子Token发送到银行; (7) 银行检验该Token的唯一性。 至此,消费者的身份仍保密,除非银行查出该Token被消费者重复使用,则消费者的身份将会暴露,消费者的欺诈行为也会暴露。 在以上的第3步如果发生了通信故障,则消费者无法判断商家究竟是否已收到该电子Token。此时消费者有两种选择: (1) 将其电子Token返回给银行或到另一商家处消费。如果消费者这样做了,而商家在第3步已收到了该Token,则当商家去银行将该Token兑现时会发现该Token的重复使用。 (2) 消费者不采取行动,既不另行消费也不退还给银行。如果消费者这样做了,而商家在第3步事实上未收到该Token,则商家自然不会发货。这样一来,消费者既未收到所购之物,也未花费该电子货币,肯定受到了损失。 可见该数字现金协议是有缺陷的。 2. FirstVirtual FirstVirtual允许客户自由地购买商品,然后FirstVirtual使用E-mail同客户证实每一笔交易。FirstVirtual对通信安全持怀疑态度并采取某种加密形式,将每个电子商务交易转换为信用卡交易。FirstVirtual比Digicash要好一些,但比其他电子商务系统要差[4]。 3. SSL Netscape的安全套接层协议(SSL,Secure Socket Layer)使用加密的办法建立一个安全的通信通道以便将客户的信用卡号传送给商家[5]。它等价于使用一个安全电话连接将用户的信用卡通过电话读给商家。这一协议当然不能防止心术不正的商家的欺诈,因为该商家掌握了客户的信用卡号。商家欺诈是信用卡所面临的最严重的问题之一。 4. SET SET(Secure Electronic Transaction)是Visa和MasterCard联合开发的一个协议,它具有很强的安全性。该协议由若干以前发表的协议形成,它们是:STT(Visa/Microsoft)、SEPP(MasterCard)和iKP协议族(IBM)[7][10]。SET及其适合的诸协议是基于安全信用卡协议的一个例子。按照SET,客户将采购请求和价格进行数字签名,然后用银行公共密钥将付款信息(例如信用卡号)加密。商家认可该采购并将该请求传给银行,银行加工该请求,若价格匹配,则银行对客户的账号扣款并指令商家完成该笔买卖。 5. Netbill 卡内基.梅隆大学(现加州大学克利分校)的J.D.Tygar教授的研究组开发了Netbill协议,已经获得CyberCash的商业用途许可。Netbill协议涉及三方:客户、商家和Netbill服务器。客户持有的Netbill账号等价于一个虚拟电子信用卡账号。协议步骤如下[6]: (1)客户向商家查询某商品价格。 (2)商家向该客户报价。 (3)客户告知商家他接受该报价。 (4)商家将所有请求的信息商品(例如一个软件或一首歌曲)用密钥K加密后发送给客户。 (5)客户准备一份电子采购订单(Electronic Purchase Order,EPO),即三元式(价格、加密商品的密码单据、超时值)的数字签名值,并将该已数字签名的EPO发送给商家。 (6)商家对该EPO进行会签,同时也签署密钥K,然后将此二者送给Netbill服务器。 (7)Netbill服务器验证EPO签名和会签。然后检查客户的账号,保证有足够的资金以便批准该交易,同时检查EPO上的超时值是否过期。确认没有问题时,Netbill服务器即从客户的账号上将相当于商品价格的资金划往商家的账号上,并存储密钥K和加密商品的密码单据。然后准备一份包含值K的签好的收据,将该收据发给商家。 (8)商家记下该收据单传给客户,然后客户将第4步收到的加密信息商品解密,得到可以使用的商品。 Netbill协议就这样传送商品的加密拷贝,并在Netbill服务器的契据中记下解密密钥。 1.1.2 在线交易主要模式分析 在美国,电子商务服务流程完全按照物理上实际存在的商务流程设计,使得电子商务工作流程与传统的商业系统很好地结合在一起[15]。用户使用方便,感觉与实际购物环境无大的区别。 从实现技术方面来讲,在线商务最关键的问题是如何完全地实现在线支付功能,并保证交易各方的安全保密。最初的电子商务不包括在线支付功能,在线商务只负责商品浏览和下订单,付款则通过其他途径解决,如电话、传真、传统支付网络等。 在Internet上提供了电子商务服务的模式完全按照传统的商务和交易的工作流程进行设计,实现的技术由简单到复杂。目前,在线电子商务具有以下几种模式[17][19]。 1. 支付系统无安全措施的模式 (1) 流程:用户从商家订货,信用卡信息通过电话、传真等非网上传送手段进行传输; (2) 特点:风险由商家承担;信用卡信息可以在线传送,但无安全措施。 2. 通过第三方经纪人支付的模式 用户在第三方付费系统服务器上开一个账号,用户使用账号付费,交易成本很低,对小额交易很适用。 (1) 流程:用户在网上经纪人处开账号,网上经纪人持有用户账号和信用卡号,用户用账号从商家订货,商家将用户账号提供给经纪人,经纪人验证商家身份,给用户发送E-mail,要求用户确认购买和支付后,将信用卡信息传给银行,完成支付过程。 (2) 特点:用户账号的开设不通过网络;信用卡信息不在开放的网络上传送;使用E-mail来确认用户身份,防止伪造;商家自由度大,无风险;支付是通过双方都信任的第三方(经纪人)完成的。 由FVC公司提出的支付系统方案,1997年3月,FVC公司宣布该系统已拥有35万用户。 3. 电子现金支付模式 用户用现金服务器账号中预先存入的现金来购买电子货币证书,这些电子货币就有了价值,可以在商业领域中进行流通。电子货币的主要优点是匿名性,缺点是需要一个大型的数据库存储用户完成的交易和E-Cash序列号以防止重复消费。这种模式适用于小额交易。 (1) 流程:用户在E-Cash发布银行开E-Cash账号,购买E-Cash,然后使用PC E-Cash终端软件从E-Cash银行取出一定数量的E-Cash存在硬盘上,通常少于100美元。用户从同意接收E-Cash的商家订货,使用E-Cash支付所购商品的费用。接收E-Cash的商家与E-Cash发放银行之间进行清算,E-Cash银行将用户购买商品的钱支付给商家。 (2) 特点:银行和商家之间应有协议和授权关系;用户、商家和E-Cash银行都需使用E-Cash软件;适用于小的交易量(MiniPayment);身份验证是由E-Cash银行本身完成的——E-Cash银行在发放E-Cash时使用了数字签名,商家在每次交易中将E-Cash传送给E-Cash银行,由E-Cash银行验证用户支持的E-Cash是否有效(伪造或使用过等);E-Cash银行负责用户和商家之间资金的转移;有现金特点,可以存、取、转让。 Digicash公司提供了一种E-Cash模式的系统。目前使用该系统发布E-Cash的银行有10多家,包括一些世界著名银行。IBM的Mini-pay系统提供了另一种E-Cash模式。该产品使用RSA公共密钥数字签名,交易各方的身份认证是通过证书来完成的,电子货币的证书当天有效。该产品主要用于网上的小额交易。 4. 支付系统使用简单加密的模式 使用这种模式付费时,用户信用卡号码被加密。采用的技术有SHTTP、SSL等。这种加密的信息只有业务提供商或第三方付费处理系统能够识别。由于用户进行在线购物时只需一个信用卡号,所以这种付费方式给用户带来了方便。这种方式需要一系列的加密、授权、认证及相关信息传送,交易成本较高,所以对小额交易而言是不适用的。 (1) 特点:部分或全部信息加密;使用对称和非对称加密技术;可能使用身份验证证书;采用防伪造的数字签名。 (2) 流程:以CyberCash安全Internet信用卡支付系统为例,CyberCash用户从CyberCash商家订货后,通过电子钱包将信用卡信息加密后传给CyberCash商家服务器;商家服务器验证接收到的信息的有效性和完整性后,将用户加密的信用卡信息传给CyberCash服务器,商家服务器看不到用户的信用卡信息;CyberCash服务器验证商家身份后,将用户加密的信用卡信息转移到非Internet的安全地方解密,然后将用户信用卡信息通过安全专网传送到商家银行;商家银行通过与一般银行之间的电子通道从用户信用卡发行银行得到证实后,将结果传送给CyberCash服务器,CyberCash服务器通知商家服务器交易完成或拒绝,商家通知用户。整个过程大约历时15到20秒。
[1][2][3][4][5] 交易过程中每进行一步,交易各方都以数字签名来确认身份,用户和商家都须使用CyberCash软件。签名是用户、商家在注册系统时产生的,而且本身不能修改。用户信用卡加密后存在微机上。加密技术使用工业标准,使用56位DES和768到1024位RSA公开/秘密密钥对来产生数字签名。 CyberCash支持多种信用卡,如Visa、MasterCard、American Express Card等。 5. SET模式 SET是安全电子交易的简称,它是一个在开放网(Internet)上实现安全电子交易的协议标准。商务活动的基本要求是保证交易的保密性、数据的完整性、安全的认证机制和可交互操作性。相应的电子商务的安全措施有[23][24]: 数据加密——保证数据安全传输; 认证——确定发送者的真实身份; 预防交易防抵赖——确保发放不能否认曾向收方发过信息,收方不能在收到信息后否认已经收到信息; 授权——决定用户是否有权执行某一项特殊的操作。 (1) 使用技术:SET协议规定了交易各方进行安全交易的具体流程。SET协议主要使用的技术包括:对称密钥加密、公共密钥加密、哈希算法、数字签名技术以及公共密钥授权机制等。SET通过使用公共密钥和对称密钥方式加密保证了数据的保密性,通过使用数字签名来确定数据是否被篡改,保证数据的一致性和完整性,并可以防御交易方抵赖。 交易各方之间的信息传送都使用SET协议以保证其安全性。电子钱包是SET在用户端的实现,电子商家是SET在商家的实现,支付网关是银行金融系统和Internet网之间的借口,完成来往数据在SET协议和现存银行交易系统协议(如ISO8583协议)之间的转换是SET在金融方面的实现。 (2) 使用情况:IBM公司宣布其电子商务产品Net.Commerce支持SET。IBM建立了世界第一个Internet环境下的SET付款系统——丹麦SET付款系统,新加坡花旗付款系统也采用了IBM的SET付款系统。 1.1.3 现阶段我国网上安全支付技术的发展情况 改革开放以来,我国在商品生产领域、经营流通领域以及金融信贷领域采取了一系列循序渐进的改革措施。在商品生产领域,已经改变了过去商品贫乏的状况,从生产资料到家用电器、日用百货等生活资料,生产能力都有了非常大的提高,整个社会的商品供求结构已经从过去的供小于求转变为供大于求,从卖方市场转变为买方市场。在经营流通领域,打破了过去从工贸公司到供销社、百货商店的一级、二级等多级批发的经营流通模式,超大型购物商场、连锁超市、平价超时、量贩店、专卖店遍地开花,厂家直销、送货上门、买断经营…都反映出目前经营流通领域的服务水平和销售能力已经到了无孔不入的地步。在金融信贷领域,各大商业银行和专业银行,经过十几年的投入改造,目前的计算机应用水平、网络覆盖范围和电子化处理能力都有了非常大的提高,各银行发行的储蓄卡、借记卡、支付卡、信用卡也已涵盖了比较大的用户群,电话银行、网上银行、自动提款机相继投入使用,而且有的银行也已开始网上支付相关的业务和服务[5][16]。 这些都表明我国现阶段已经具备了开展电子商务网上支付技术实际应用的基本条件,而且各行各业对于在网上开展电子商务应用也都表现出了浓厚的兴趣。 国内在电子商务系统安全产品方面也有一些产品,但由于没有适合我国国情需要的统一标准来规范,使得各个厂商各行其是,不益于各个行业领域的广泛推广。对于安全支付产品的开发及测试还不理想,基于SET的支付系统仍是空白;而基于非SET标准的支付系统又存在系统结构不完整,通用性不强等这样或那样的缺陷。因此,开发一套基于SET的网上安全支付系统软件势在必行。 1.2 对电子商务安全问题的探讨 电子商务如何能够在安全可靠的环境下进行是决定电子商务模式生命力的根本因素。这样,设计安全可靠的安全支付系统就成了开展电子商务活动的当务之急。 为了电子商务的安全,需要考虑的主要安全因素有以下几个方面[12][13]: 1.2.1 有效性 电子商务以电子形式取代了纸张,那么如何保证这种电子形式的贸易信息的有效性则是开展电子商务的前提。因此,要对网络故障、操作错误、应用程序错误、硬件故障、系统软件错误以及计算机病毒所产生的潜在威胁加以控制和预防,以保证贸易数据在确定的石刻、确定的地点是有效的。 1.2.2 机密性 电子商务作为贸易的一种手段,其信息直接代表着个人、企业和国家的商业机密。传统的纸面贸易都是通过邮寄封装的信件或通过可靠的通信渠道发送商业报文来达到保守机密的目的。电子商务是建立在一个较为开放的网络环境上的,维护商业机密是电子商务全面推广应用的重要保障。因此,要预防非法的信息存取和信息在传输过程中被非法窃取。 1.2.3 完整性 电子商务简化了贸易过程,减少了人为的干预,同时也带来了维护贸易各方商业信息的完整、统一的问题。由于数据输入时的意外差错或欺诈行为,可能导致贸易各方信息的差异。此外,数据传输过程中信息的丢失、信息重复或信息传送的次序差异也会导致贸易各方信息的不同。贸易各方信息的完整性将影响到贸易各方的交易和经营策略,保持贸易各方信息的完整性是电子商务的基础。因此,要预防对信息的随意生成、修改和删除,同时要防止数据传送过程中信息的丢失和重复并保证信息传送次序的统一。 1.2.4 可靠性/抗抵赖性/鉴别 电子商务可能直接关系到贸易双方的商业交易,如何确定要进行交易的贸易方正是进行交易所期望的,贸易方这一问题则是保证电子商务顺利进行的关键。在传统的纸面贸易中,贸易双方通过在交易合同、契约或贸易单据等书面文件上手写签名或印章来鉴别贸易伙伴,确定合同、契约、单据的可靠性并预防抵赖行为的发生。这也就是人们常说的“白纸黑字”。在无纸化的电子商务方式下,通过手写签名和印章进行贸易双方的鉴别已是不可能的。因此,要在交易信息的传输过程中为参与交易的个人、企业或国家提供可靠的标识。 1.2.5 可审计性 根据机密性和完整性的要求,应对数据审查的结果进行记录。 1.3 论文的主要工作 随着电子商务的应用发展,网上支付已经成为必然。针对网上安全支付技术,世界范围内提出了许许多多的理论模式和解决方案,这些理论与方案在不同的国家和地理范围内也有其独特的发展和应用。本文在深入研究网上支付理论和解决方案的基础上,对适合我国国情的安全支付技术进行了探讨。 论文所设计和实现的网上安全支付原型系统采用基于公钥基础设施的体系结构,遵循和参照国际上先进的安全电子交易协议SET1.0/2.0、抽象语法标记语言ASN.1等标准,以有效性、机密性、完整性、可靠性为设计原则,基于JDK1.2及以上版本开发,所实现的原型系统由电子钱包、支付服务器、支付网关等部分组成,并给出了商家服务器、银行网络的接口和出口。论文分别描述了该系统的运作原理、标准和流程,并提交了相应程序代码。 论文所设计和实现的网上安全支付原型系统设计与同类产品设计相比,具有以下特点:基于PKI安全体系结构,拥有自主版权的可信PKI安全平台;采用PKI DISA数字信息安全助理存储证书,用户使用更加安全、方便;公网消息格式遵循SET1.0/2.0、ASN.1、HTTP1.0和MIME1.0规范,与金融网络通信的消息格式遵循ISO8583规范,保证了系统的通用性;一个支付网关可以与多个银行系统连接,多个支付网关可以并行处理,提高了系统的利用率和可扩展性。突出强化支付监管功能,易于实现业务管理。第2章 系统总体设计 2.1 系统体系结构设计目标和适用范围 2.1.1 设计目标 目前国内对该领域的理论分析和实践上处于刚刚起步的阶段,因此短期内实现对国外各种支付体系和支付规范的完全兼容的多协议栈支付系统仍是非常困难和不现实的,因此目前的首要任务仍是充分分析国外先进的支付体系和支付规范,提取其中的先进技术和设计方法,研究和开发出适合中国国情的具有体系结构和技术规范上的先进性的网上安全支付体系及其规范,并逐步加以扩展,使之与国际通用规范和系统实现接口和规范上的兼容性。这也正是本系统开发的的指导思想和最终目标。 综上所述,本系统设计和开发的目标就是:研究国内外网上安全支付领域及相关产品设计与实践中的先进理念和技术,研究国际通行的网上安全支付规范,并结合中国国情,设计、开发一套基于此基础之上的网上安全支付原型系统。 2.1.2 适用范围 基于目前Internet及相关应用的飞速发展,网上的商务活动日益频繁,因此提出了一系列针对更好的实现和发展网上商务活动的要求,作为电子商务的一项核心技术,网上在线支付问题日益成为各方面关注的焦点和亟待解决的重要课题[30][34]。由于Internet网的复杂性、不确定性致使网上的各种活动难以得到有效的监控,各种网上的犯罪活动和不安全因素致使人们很难完全相信Internet这个看似虚无的媒介。 而作为电子商务的重要部分,网上支付又正是在这样一种环境下,这样一种媒介之上进行的重要金融活动,因此安全性和可靠性是任何一个从事该活动的人都异常关心的问题。针对这一问题提出的解决方案和支付方式还是很多的,如电子货币、信用卡支付、电子支票、微支付、电话支付等。每一种方式都有其特定的适用范围和对象。 本系统作为使用信用卡支付的支付系统,主要适用范围是各种网上的商业活动,如网上购物、在线下载、在线缴费、在线申请、以及各种通过网络的服务和订购,考虑国内的实际的情况又以借记卡为主要的支付方式。本系统作为一种网上的安全支付系统,充分考虑了网络攻击、身份识别、信息保密、信息容错等网上应用必须考虑的安全问题,同时也兼顾了业务上的可行性和通用性,因此具有广泛的适用性。本系统主要参考SET规范,由于该规范经过了广泛的理论和实践的验证,越来越显示出其先进性和通用性,因此作为以此为主要理论依据和设计基础的本系统也同样具有理论和技术上的先进性以及未来与国际通用系统实现完全兼容的易扩展性[26]。
[1][2][3][4][5] 2.2 系统的运行环境和要求 2.2.1 运行环境 作为一种网上的安全支付系统,应充分考虑到因特网的复杂性,各种系统运行与不同的硬件与软件平台之上,信息的传递需通过各种不同的网络及设备,为每一种硬件与软件环境、每一种网络设计各自不同产品是困难的或不切实际的,即使可移植性很强的C语言编写的软件产品达到这一目标也是非常困难的。而伴随Internet一同成长起来的Java则具备了非常好的可移植性和通用性,基本可做到一个产品可运行于多种软硬件环境。本系统正是基于以上原因,采用了Java作为开发语言,并使用它的JNI技术,部分采用ANSI C以达到通用性与执行效率的最佳结合。针对网络的复杂性,本系统采用了SET的外部接口规范中所推荐的HTTP通讯协议,并采用MIME封装,以达到对各种网络的适应性。 综上所述,本系统体现出对运行环境较强的适应性,在具体设计中将遵循这样的一个设计期望和目标。 2.2.2 系统要求 本系统基于JDK1.2及以上版本开发,因此应具有相应的软件运行环境,本系统的服务端开发基于Sun Servlet API 2.1、JSP1 .0开发并运行于IBM WebSphere Application Server V4.0环境中,数据库采用IBM DB2 V7.1,数据库连接采用JDBC。 2.3 系统体系结构 2.3.1 系统说明 本系统以SET规范为主要的理论依据和参考规范,并在此基础上进行适当的符合中国国情的修改,因此可以说本系统基于的网上安全支付规范基本上是SET规范的一个子集,本系统的基本体系结构及其功能与SET规范中相应的体系结构和功能是基本一致的,因此本系统的体系结构分析也就是对基于SET的网上安全支付体系的分析。 2.3.2 角色组成 基于SET的网上支付体系主要由以下几个角色组成: 2.3.2.1持卡人(CardHolder): 在SET体系中,持卡人指的是一般消费者和通过SET向供应商采购货物的企业客户。持卡人使用发卡行发行的支付卡。SET确保在交易过程中,持卡人的帐号信息保持机密状态。 2.3.2.2发卡行(Issuer): 发卡行是客户的金融机构。持卡人从它获得帐号和支付卡。如果支付卡的使用按照支付卡品牌规范和本地法律,并且该交易是经过认证的,则发卡行为支付提供担保 2.3.2.3商家(Merchant): 商家提供货物和服务。用SET标准,商家能和持卡人进行安全的电子交互。可以接受支付卡支付的商家必须有收单行。 2.3.2.4收单行(Acquirer): 在SET体系中,收单行是一种能够向商家提供信用卡支付授权和支付捕获服务的组织。因为在通常情况下,一个商家往往要面对使用不同品牌信用卡支付的顾客,有了收单行提供的服务,商家就不必与多个银行卡组织建立联系。当然,每一笔交易成功以后商家也必须向收单行支付相应百分比的服务费用。 2.3.2.5支付网关(Payment Gateway): 在SET体系中,支付网关是由收单行提供的实现支付授权和支付捕获功能的一套软件。实现SET与原有银行网络的接口的功能。从另一方面讲,支付网关充当的是银行网络的代理的功能。 2.3.2.6品牌(Brand): 金融机构已建立起支付卡品牌,用来保护和宣传品牌,制定使用和接收支付卡的规则,并为金融机构提供网络连接。其余的品牌都属于那些宣传品牌,制定使用和接收支付卡的规则的金融服务公司。这些品牌将发卡行和收单行与持卡人和商家有机的结合在一起。 2.3.2.7CA(Certification Authority): 它提供公匙认证功能,并可能有不同的针对SET中不同角色的分离认证(持卡人 CCA、商家 MCA和支付网关 PCA)。但他们都基于同样的继承关系,因此能彼此信任。 2.3.3 关系描述 SET的各个角色之间的关系已经内涵于角色自身的定义之中了。我们能够把它们之间的关系划分为三种类型[23][24]: 1.合同关联 图 2-1 合同关联 如图2-1,这些关联在在法律上已经存在于提供服务和承担责任的各方之间了,除了SET假定这些关系已经存在以外,这些关系与SET并没有任何直接的联系。合同关联主要包括以下几方面的内容: 持卡人同发卡行有合同契约。 发卡行和银行卡组织有合同契约或其他形式的合法的约定。 收单行同意在银行卡的规则和安全范围内操作。 商家和收单行之间有某种合同约束。 2.管理关联
图 2-2 管理关联 如图2-2,这些关联是在任何交易能够进行之前必须具备的,它们被用于设置SET环境,并保持SET安全性,有些实际上就是SET协议的流程。管理关联主要包括以下几方面的内容: 持卡人同软件提供者之间有信任关系,它一般是发卡行。由于这种信任,持卡人安装这个SET软件。 商家同软件和服务提供者之间有合同约束。不论这个提供者是ISP或其他与收单行有某种联系的其他组织,由于他要在商家系统上安装SET软件和服务,所以商家必须相信他。 不同的CA 有他们所基于的公钥认证体系上的继承关系。 持卡人,商家和支付网关分别与恰当的CA有关联。他们互相证实他们所获得的签名公钥认证的有效性。 3.操作关联 如图2-3,这些关联在支付发生时短时间内建立并生效,它们都被SET协议流程所定义。操作关联主要包括: 持卡人连接到商家的系统执行支付和查询操作。 商家系统连接到支付网关以执行认证、捕获操作和退款操作。 支付网关连接到银行卡组织的网络以传送来自于商家的请求。
图 2-3 操作关联 2.3.4 系统架构 针对构成基于SET的安全支付系统的以上几个角色及他们之间的关系,本原形系统由以下几个部分组成: 1.电子钱包: 2.支付服务器: 3.支付网关: 并为以下几个系统提供接口和出口: 1. 商家服务器 2. 银行网络 同时本系统基于CA认证的统一基础之上,并通过LDAP服务器和CA的注册服务器与CA进行有效的联系,并置于其监管之下。 其中电子钱包安装于持卡人的计算机上,商家服务器和支付服务器则属于商家或商家联盟,支付网关则是支付系统联系银行网络的纽带,体系中各实体的证书从LDAP服务器上下载,而注册服务器则可充当CA认证注册和验证的多种CA(如CCA、MCA、PCA等),他们之间的关系可描述为图2-4所示。 图 2-4 基于SET的交易系统 2.3.5 层次模型 本系统为开放式的体系结构,遵循分层式的体系模型,采用模块化和对象式的混合编程方法,广泛使用代码复用技术和统一模块结构的方法,以确保系统的可扩展型、易维护性、高效性和可靠性。 本系统基本上分为四层,分别为: 应用层:包括电子钱包、支付服务器、支付网关的各个功能模块。 支付协议层:处理支付协议。 PKI及数据封装层:对支付协议层的各种数据进行加解密、封装解包等操作。 通讯接口层:实现各系统之间的信息交换与通讯连接。 它们之间的关系如图2-5所示。 图2-5 接口关系图 2.4 体系业务流程 2.4.1 SET认证流程 2.4.1.1持卡人认证流程 (1)持卡人注册初始化,持卡人电子钱包软件产生一个请求,获取CA(这里是CCA:CARDHOLDER CERTIFICATION AUTHORITY)的证书拷贝。 (2)CA发送应答,CA接收到初始化请求以后,生成一个应答消息,加上这个消息的数字签名,连同CA的签名证书和交换证书一道发送给持卡人。 (3)持卡人请求注册表单,持卡人收到初始化应答进行解密并验证签名以后,持卡人输入信用卡账号,持卡人电子钱包软件产生一个注册表单请求消息;对此消息进行对称加密,并用CA的交换证书加密持卡人信用卡账号和此对称密钥形成数字信封,一起发送到CA。 (4)CA发送注册表单,CA接收到持卡人的注册表单请求消息以后,解密获得持卡人的信用卡账号和请求消息;CA据此选择相应的表单并对表单进行数字签名以后连同CA的签名证书一道发送到持卡人。 图2-6 持卡人认证流程 (5)持卡人请求证书,持卡人收到CA发送的注册表单进行解密验证以后,持卡人电子钱包软件生成一对非对称密钥,并保存到安全的位置;持卡人填写注册表单并提交,持卡人电子钱包软件加上一个随机数,以供CA将来生成证书之用;持卡人电子钱包软件根据持卡人填写的注册信息和生成的随机数产生一个证书请求消息;对注册表单和证书请求消息共同进行数字签名;持卡人电子钱包软件随机产生两个对称密钥SK1和SK2;使用SK2对称加密数字签名、非对称密钥的公钥、SK1、注册表单和证书请求消息,形成密文;再用CA的交换公钥加密信用卡账号和SK2,形成数字信封;将此密文和数字信封一道发送到CA。 (6)CA处理证书请求并生成证书,CA接收到证书请求以后,作相应的解密和验证处理;CA检验持卡人账号和注册内容是否与品牌数据库中持卡人信息相符,然后才生成和发送证书。(首先,CA生成一个随机数R2与持卡人电子钱包软件生成的随机数R1结合,产生一个密值RK,对持卡人账号、账号终止日期和密值RK进行数字签名,此签名就是通常所说的证书商的CA签名,将此签名加入到证书上便形成了一张证书;然后,CA要生成一个证书应答消息,其中包括CA生成的随机数R2和其他一些信息,对此应答消息使用持卡人发送来的对称密钥SK1进行加密,形成密文;最后,将密文、CA的签名证书和持卡人证书一起发送到持卡人)。 (7)持卡人接收证书,持卡人接收到证书应答并解密验证以后,保存证书,便可开始购物。 2.4.1.2商家认证流程 图2-7 商家认证流程 (1)商家初始化注册,商家软件产生一个请求,获取CA(这里是MCA:MERCHANT CERTIFICATION AUTHORITY)的证书拷贝。 (2)CA发送注册表单,CA接收到商家的初始化注册请求消息并解密验证以后,选择相应的注册表单,进行数字签名以后,连同CA的签名证书和CA的交换证书一同发送到商家计算机。
[1][2][3][4][5] (3)商家请求证书,商家接收到注册表单以后,商家软件产生两对非对称密钥,并根据商家填写的注册表单内容生成一个证书请求消息,对此消息进行数字签名;商家软件再随机产生一个对称密钥,用于加密证书请求消息、消息数字签名、商家签名公钥和商家交换公钥,形成密文;再使用CA的交换公钥加密此对称密钥和商家账户信息,形成数字信封;将密文和数字信封一同发送到CA计算机。 (4)CA处理请求并生成证书,CA接收到商家的证书请求消息以后,进行解密并验证;然后,CA通过商家账号信息、离线文档和注册表单的内容,验证商家信息是否正确,最后才生成和发送证书。(首先,CA根据商家注册信息生成两张证书(签名证书和交换证书);然后,CA要生成一个证书应答消息,对此应答消息使用CA的签名密钥进行数字签名,对应答消息、数字签名、商家签名证书、商家交换证书和CA的签名证书进行对称加密,形成密文,再将对称密钥形成数字信封;最后,将密文和数字信封一道发送到商家计算机)。 (5)商家接收证书,商家接收到证书并解密验证以后,保存证书,完成。 由于本系统考虑到国内CA系统的现状和证书的实际使用情况,各种国内内的CA统一对SET协议的支持尚有困难,且由于国内的信用制度尚不完善,完全借助于SET协议的认证过程尚难以完全实现,因此本系统未采用SET的认证流程,而是采用LDAP服务器下载后绑定的方式,以提供对各种获取证书途径的支持。 2.4.2 SET交易流程 SET的交易流程可以细分为3个步骤[23][29] 2.4.2.1购买流程 (1)持卡人电子钱包产生一个购买初始化请求,其中包括持卡人用于支付的信用卡的品牌。 (2)商家接收到持卡人的购买初始化请求以后,返回一个初始化应答,其中包括商家证书和商家收单行所使用的支付网关的证书。 (3)持卡人接收初始化应答并发送支付请求,其中包括PI和双重签名的密文、PI消息摘要、使用支付网关交换公钥加密对称密钥与信用卡账号得到的数字信封、OI消息、双重签名。 (4)商家处理购买请求,通过证书信任链验证持卡人证书,验证双重签名,然后将PI和双重签名的密文、和数字信封,形成支付授权,传递给支付网关(商家不需要等待支付网关的授权应答,就可向持卡人发送购买应答,告诉持卡人,他的订单已经收到,在验证信用卡有效性以后将向持卡人交付订购的商品)。 (5)持卡人接收购买应答,持卡人收到购买应答以后,保存购买应答,如果支付网关功能支持,持卡人可以通过向商家发送订单查询消息(Order Inquiry)决定订单的状态。 图2-8 购买流程 2.4.2.2支付授权流图2-9 支付授权流程 (1)商家授权请求,商家软件产生一个授权请求,包括授权金额、从OI中得到的交易标识(Transaction Identifier)、重新生成的OI的摘要以及其他与交易相关的信息,形成密文和数字信封,加上PI的密文和数字信封,以及持卡人的签名证书、商家的签名和交换证书,一起发送到支付网关。 (2)支付网关处理支付授权请求,支付网关收到支付授权请求以后,进行解密、验证等相关处理,然后使用银行网络的消息格式形成一个授权请求,发送到相应的发卡行。收到发卡行的应答以后,再形成一个授权应答发送给商家,其中包括两部分:发卡行的授权应答和支付捕获记号(Capture Token,可选),对此两条信息分别形成密文和数字信封,加上支付网关的签名证书,一起发送到商家。 (3)商家处理支付授权应答,商家接收到支付授权应答以后,进行解密、验证处理,然后保存支付捕获信息的密文和数字信封,供以后支付捕获流程使用。
2.4.2.3支付捕获流程 图2-10 支付捕获流程 (1)商家支付请求,商家软件产生一个捕获请求消息,包括最终授权金额、从OI中得到的交易号(Transaction ID)以及其他与交易有关的信息,形成密文和数字信封,连同在支付授权应答阶段获得的支付捕获记号(Capture Token,可选)和数字信封,以及商家的交换和签名证书一同发送到支付网关。 (2)支付网关处理支付捕获请求,支付网关解密接收到的信息,比较支付捕获请求和支付捕获记号内容一致性,然后产生一个请求通过银行卡内部网发送到发卡行,向商家账号划账;最后,支付网关还要向商家发送一个支付捕获应答消息。 (3)商家处理支付捕获应答,商家解密并验证接收到的支付捕获应答消息,最后保存捕获应答以便与收单行进行核对。 本系统采用SET的交易流程,并采用它的另一可选操作—信用请求/响应消息对,以完成退款操作。本系统的交易流程符合SET规范的要求,并使用与SET协议基本相同的消息对及消息结构。
[1][2][3][4][5]
|