电子商务中的网络支付体系,必然是集购物流程、支付工具、安全技术、认证体系、信用体系,以及现在的电子银行体系为一体的综合系统。由此可以看出,网络支付安全体系的建立不是一蹴而就的,它受多种因素的影响,且与这些因素相互促进,动态发展,共同走向成熟。因此,应从系统的角度来考虑其安全体系的建立,针对网络支付的相关安全需求,开展电子商务的商家和后台的支撑银行必须相互配合,建立一套相应的安全策略,在实践中完善,以保证电子商务下网络支付的顺利进行。
2.2.1网络支付系统的构成
客户是指在互联网上与某商家或企业有商务交易关系并且存在未清偿的债权、债务关系的一方(一般是债务)。客户用自己已拥有的支付工具(如信用卡、电子钱包等)来发起支付,这是支付体系运作的原因和起点。
商家则是拥有债券的商品交易的另一方,可以根据客户发起的支付指令向中介的金融体系请求获取货币给付。商家一般设置专门的后台服务器来处理这一过程,包括协助身份认证及不同网络支付工具的处理。
客户开户行是指客户在其中拥有资金账户的银行,客户所拥有的网络支付工具主要是由开户银行提供的。客户开户行在提供网络支付工具的时候,同时提供一种银行信用,即保证支付工具是真实并可兑付的。在利用金融卡进行网络支付的体系中,客户开户行又被称为发卡行。
商家开户行是商家在其中开设资金账户的银行,其账户是整个支付过程中资金流向的地方或目的地。商家将收到的客户支付指令提交其开户行后,就由开户行支付授权的请求,以及进行商家开户行与客户开户行之间的清算工作。商家开户行是依据商家提供的合法账单来工作的,因此又称为收单行。
支付网关(Payment Gateway)是Internet公用网络平台和银行内部的金融专用网络平台之间的安全接口,网络支付的电子信息必须通过支付网关进行处理后才能进入安全的银行内部支付结算系统,进而完成支付的授权和获取。支付网关的建设关系着整个网络支付结算的安全及银行自身的安全,关系着电子商务支付结算的安排及金融系统的风险,必须十分谨慎。在电子商务交易过程中,网络平台上同时传输两种电子信息,即交易信息与支付信息,必须保证这两种电子信息在网络传输过程中不被无关的第三者查看。同时,商家不能看到其中客户的支付信息(如客户信用卡号、密码等)而银行不能看到其中的交易信息(如商品种类、商品价格等),以保护客户及商家交易的隐私。这就要求支付网关必须由商家以外的第三方银行或其委托的卡发行机构来建设。另一方面,支付网关不能分析交易信息,对送来的支付信息也只是起保护与传输作用,即这些保密数据对网关“透明”。
金融专用网络是银行内部及银行间进行通信的专用网络,它不对外开放,因此具有很高的安全性。包括中国国家现代化支付系统(CNAPS)、中国人民银行电子联行系统、工商银行电子汇兑系统、金融卡授权系统等。目前我国传统商务中的电子支付应用如POS支付结算、ATM资金存取、电话银行等系统均运行在金融专用网上。银行的金融专用网发展迅速,为逐步开展电子商务提供了必要条件。
CA认证机构是网络商务的准入者和市场的规范者,主要为参与网上电子商务活动的各方(包括客户、商家、银行和支付网关)发放和维护数字证书以及提供数字签名服务的支持等,以确认各方的真实身份,保证网络支付的安全性。当然为了确认参与者的资信状况(如银行账户状况、历史信用记录等)也离不开银行参与。
除以上参与各方外,网络支付系统的构成还包括支付中使用的支付工具以及遵循的支付协议,是参与各方与支付工具、支付协议的结合。常用的网络支付工具有金融卡、电子现金、电子支票等,除此以外,网络银行也被看做一种网络支付工具,其支付协议主要指支付的安全通信与控制协议,如SSL与SET等。
2.2.2网络支付的相关安全技术及应用
众所周知,安全性是成功发展电子商务的决定性因素,网络支付作为电子商务中最为重要的部分,它的安全性至关重要。在构建电子商务环境、开发网络支付系统时,除了要应用防火墙技术和数据加密技术,还有很多信息安全技术和安全协议非常重要,对于保障网络支付的安全性起着重要的作用。
1.防火墙技术
在网络支付业务过程中,商家、银行与客户均需要在网络上进行互动、实时的信息交换,如支付方式的选择与支付表单的提交、确认支付等。为了保证网络支付业务的安全顺利进行,防火墙与运行这些业务的Web服务器之间就要进行必要的关联配置,以便商家或银行既能利用业务Web服务器对外提供网络业务服务,又能借助防火墙保证内部网络的安全。
一个简单防火墙本身的配置可按下列配置步骤完成。
(1)选择一台具有路由能力的PC。
(2)加上两块网络接口卡。
(3)禁止IP转发。
(4)打开一个网卡通向外面的Internet。
(5)打开另一个网卡通向银行或商家的内部网Intranet。
这样,两个不同的网络被这种配置的防火墙分割开来。由于Intranet与Internet被这个防火墙隔离,所以访问Internet就必须经过防火墙。从Internet欲进入内部网络,同样必须先通过这个防火墙。
2.密码技术
具体到网络支付结算,很多环节要用到密钥加密法,例如,在两个商务实体或两个银行之间进行资金的支付结算时,涉及大量的资金流信息的传输与交换。
对称型密钥体制的应用过程示意图,其过程简述如下:
(1)银行甲借助专业对称型密钥加密算法生成私有密钥A,并且复制一个密钥A通过安全信道秘密传递给银行乙。
(2)银行甲在本地用密钥A加密信息明文为信息密文。
(3)银行甲把信息密文通过网络传给银行乙。
(4)银行乙接收信息密文。
(5)银行乙在本地用密钥A把信息密文解密为信息明文。
这样银行乙就知道银行甲的资金转账内容了。
3.数字信封
为了充分发挥对称型密钥加密算法和非对称型密钥加密算法的作用,采用融合上述两种算法的技术——数字信封。
利用收发双方的共享密钥P加密需要传送的信息,然后用接收方公钥对加密信息原文的共享密钥P进行加密后再定点传送,这就好比用一个安全的“信封”把共享密钥P封装起来,所以称为数字信封。因为数字信封是用消息接收方的公钥加密的,只能用消息接收方的私钥解密打开,因而别人无法得到信封中的共享密钥P,这样既保证了消息传递的安全又提高了速度。
数字信封具体到网络支付过程中的应用,可以以客户甲与银行乙之间的一次通信为例,即客户甲通过数字信封向银行乙发送“支付通知”,其过程简述如下:
(1)客户甲在本地利用算法随机产生一个共享密钥P。
(2)客户甲在本地用共享密钥P对“支付通知”明文加密形成“支付通知”密文。
(3)客户甲在本地用银行乙的公钥B对共享密钥P加密,即生成数字信封。
(4)客户甲把“支付通知”密文和数字信封一并通过网络发送给银行乙。
(5)银行乙用自己的私钥A解密(打开)收到的数字信封,取出共享密钥P。
(6)银行乙用取得的共享密钥P对收到的“支付通知”密文解密得到“支付通知”明文。
4.数字签名
数字签名具体到网络支付过程中的应用,可以以客户甲与银行乙之间的一次网络支付单据为例,即客户甲在向银行乙发送“支付通知”上附带客户甲的数字签名,帮助银行乙认证客户甲的发送行为,其过程简述如下:
(1)客户甲利用数字摘要算法(Hash函数)对“支付通知”明文M进行数学变换,生成“支付通知”明文M的数字摘要D。
(2)客户甲用自己的私钥A对数字摘要D进行加密,得到客户甲的数字签名S。
(3)客户甲把数字签名S附加在“支付通知”明文M之后,一起通过网络发送给银行乙。
(4)银行乙收到数字签名S和“支付通知”明文M′。
(5)银行乙用客户甲的公钥B对数字签名S进行解密,得到数字摘要D,并由此确定客户甲的身份,其行为不可抵赖。
(6)银行乙再将得到的“支付通知”明文M′用和客户甲相同的数字摘要算法(Hash函数)进行数学变换,产生“支付通知”明文M′的数字摘要D′。
(7)银行乙将数字摘要D和D′进行比较,若相同,说明“支付通知”明文M和“支付通知”明文M′是一致而真实的,数字签名有效;否则,收到的“支付通知”明文M′不是客户甲发送的真实“支付通知”明文M或被非法篡改过,签名无效。
5.双重数字签名
双重数字签名具体到网络支付过程中的应用,可以以客户甲、网上商家、银行乙三方之间的一次购物支付为例说明。
(1)客户甲到网上商家购物,选中相关商品后,选择基于银行乙支持的网络支付手段进行支付。这时先要填写发给网上商家的“订货单甲”与发给银行乙的“支付通知甲”,并把它们看做两条发给不同接收方的信息。
(2)客户甲对“订货单甲”进行Hash运算,得到“订货单甲”的数字摘要D,然后对“支付通知甲”进行Hash运算,得到“支付通知甲”的数字摘要E。
(3)客户甲把数字摘要D和数字摘要E连接起来形成一条信息,再对这条信息进行Hash运算,得到双重数字摘要M。
(4)客户甲用RSA算法将客户甲的私钥对双重数字摘要M进行加密得到双重数字签名K。
(5)客户甲把双重数字签名K、“支付通知甲”(为保证机密,可以用银行乙的公钥加密)、“订货单甲”的数字摘要D合在一起,通过网络发给银行乙(也可能通过商家中转,这时对“支付通知甲”加密就有必要了)。
(6)银行乙收到相关信息后,对其中的“支付通知甲1”(因为不知道其真实性如何,所以称为“支付通知甲1”,可能要用银行乙的私钥解密)进行Hash运算,生成“支付通知甲1”的数字摘要E1.
(7)银行乙将收到的“订货单甲”的数字摘要D与刚生成的“支付通知甲1”的数字摘要E1连接在一起形成一条消息,再对这条消息进行Hash运算,得到双重数字摘要M1.
(8)银行乙将收到的双重数字签名K用客户甲的公钥解密,得到双重数字摘要M。
(9)银行乙将双重数字摘要M1与双重数字摘要M进行比较,若一致,确认“支付通知甲1”是客户甲发来的,且在网络传输过程中没有被篡改,与“支付通知甲”一样。
上述(1)~(9)步骤是描述客户甲与银行乙之间利用双重数字签名完成“支付通知”传递的过程,客户甲与网上商家之间完成“订货单”传递和上述步骤类似,只不过是将双重数字签名K、“订货单甲”(为保证机密,可以用网上商家的公钥加密)、“支付通知甲”的数字摘要E合在一起,通过网络发给商家。
由上述可知,双重数字签名技术的应用不仅能够证实商家收到的信息没有被篡改,而且还能证实银行乙收到的信息也没有被篡改,并且确信是客户甲发来的,不可否认。商家与银行乙只能知晓客户甲发出的一个完整购物单据信息中只应该看到的那部分,保证商家和银行乙收到的信息是客户甲发出的同一条购物信息中的一部分。
2.2.3安全网络支付的SSL与SET协议机制
迄今为止,国内外已经出现了多种网络支付协议,目前有两种安全网络支付协议被广泛采用,分别为安全套接层SSL协议和安全电子交易SET协议,二者均是成熟和实用的安全协议。
1.基于SSL的网络支付
由于SSL协议实现简单并且独立于应用层协议,同时它还被大部分的浏览器和Web服务器所内置,因此便于在网络支付中应用。国际著名的CyberCash信用卡支付系统就支持这种简单加密模式,IBM等公司也提供基于这种简单加密模式的支付系统。
在交易中,客户(消费者)将购买的信息首先发往商家,商家再将信息转发给银行,银行验证客户信息的合法性后,通知商家付款成功,商家再通知客户购买成功。
可见,基于SSL的购物流程比较简单,它只需先通过一次“握手”过程建立连接就可以在客户和服务器间建立一条安全通信的通道,保证相互间能在以后安全交换数据。Netscape与Microsoft等公司的浏览器都支持SSL,因此对客户端没有什么特殊要求,而且SSL提供的安全服务对终端用户也是透明的。
但是,由于SSL不是专为电子商务设计的,把它应用在网络支付上必然存在一些缺陷。从SSL协议所提供的服务及其交易过程可以看出,SSL协议运行的基础是商家对消费者信息保密的承诺,信息的保密性由商家决定,这就有利于商家而不利于消费者。在电子商务初级阶段,由于运作电子商务的企业大多是信誉较高的大公司,因此这个问题还没有充分暴露出来。但随着电子商务的发展,许多中小型公司也参与进来,这样在网络支付过程中的单一认证问题就越来越突出。虽然在SSL3.0中通过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证,但是SSL协议仍存在一些问题,比如,只能提供交易中客户与服务器间的双方认证,在涉及多方的电子交易中,SSL协议并不能协调各方间的安全传输和信任关系。另外,客户可以声称没有进行购买,商家也可能会否认收到购买信息,SSL不能提供交易过程的证据。所以,SSL并没有保证实现电子支付所要求的保密性、不可否认性,而且多方相互认证也是很困难的。
在这种情况下,Visa和MasterCard两大信用卡组织以及其他一些业界厂商制定了SET协议,为网上信用卡支付提供了全球性的标准。
2.基于SET的网络支付
电子商务的交易流程与实际的交易流程非常接近,这使得电子商务与传统商务可以很容易融合,用户使用也没有什么障碍。从消费者通过浏览器进入在线商店开始,直到完成货物或服务的订购以及支付结算,所有这些都是通过互联网完成的。消费者在网络上用基于SET的系统进行交易一般由购买请求、支付认证和支付获取三部分组成。
(1)发送购买请求。
在发送购买请求前,客户首先通过浏览器从商家的商品目录中寻找所需商品。
①客户初始化请求:客户发送初始化请求给商家。
②商家发送证书:商家收到客户的初始化请求后,为请求报文分配一个唯一的交易标识号,并用商家的私钥进行数字签名,然后将初始化响应报文与商家和支付网关的证书一起传给客户。
③客户接收初始化响应并发送请求:客户收到初始化响应后,遍历信任链,验证商家和支付网关的证书,确认商家和支付网关的身份,再根据商家的公钥确认初始化响应商家的数字签名;客户产生订购信息和支付命令;客户用私钥对订购信息和支付命令进行双重数字签名;客户产生一个随机的对称密钥,并用它对双重数字签名后的支付命令加密,然后再用支付网关交换密钥的公钥对客户账号和对称密钥加密;客户将加密后的订购信息和支付命令发给商家。
④商家处理请求报文:商家遍历信任链以确认客户证书;商家用客户的公钥对订购信息上的双重数字签名解密,以确保订单在传输过程中未被篡改,其上的数字签名是客户的;商家处理订购信息请求,同时将支付命令传给支付网关并请求授权;商家产生一个购买响应报文(其中包括商家的签名证书,指明客户的订单已被接收),并对该报文数字签名后发给客户;如果交易被授权,商家将执行订单上规定的送货等服务。
⑤客户接收购买响应:客户遍历信任链确认商家的签名证书;客户用商家的公钥来证实购买响应上的签名是商家的;客户保存收到的购买响应。
(2)支付认证。
①商家请求授权:商家产生授权请求,并对它进行数字签名;商家用随机产生的对称密钥对授权请求加密,然后再用支付网关交换密钥的公钥对该对称密钥加密;商家将加密的授权请求和来自客户的加密支付命令一起发送给支付网关。
②支付网关处理授权请求:支付网关遍历信任链确认商家的证书;支付网关用其交换密钥的私钥对对称密钥解密,然后用对称密钥对授权请求解密;支付网关用商家的公开密钥验证授权请求上商家的签名。网关遍历信任链确认客户的证书;网关用其交换密钥的私钥对对称密钥解密,再用对称密钥对支付命令解密;支付网关用客户的公钥确认支付命令上客户的数字签名;支付网关确认商家授权请求中的交易号与客户支付命令中的一致。支付网关通过金融网络向客户的金融机构(发卡行)发出授权请求;支付网关产生一个授权响应报文,并用支付网关的私钥签名;支付网关用新产生的随机对称密钥对授权响应加密,然后再用商家交换密钥的公钥对对称密钥加密;支付网关产生一个付款标志,并用支付网关的私钥签名;网关将加密后的授权响应送商家。
③商家处理授权响应:商家遍历信任链确认支付网关的证书;商家用其交换密钥的私钥对对称密钥解密,然后再用对称密钥对授权响应解密;商家用支付网关的公钥确认授权响应上支付网关的数字签名;商家保存加密后的付款标志和授权响应,以作付款处理用;商家完成订购请求后,执行订单。
(3)支付获取。
①商家请求付款:商家产生付款请求;商家将其证书嵌入付款请求中,并用商家的私钥对付款请求签名;商家用对称密钥对请求加密,并用支付网关交换密钥的公钥对该密钥加密;商家将加密后的付款请求和以前保存的来自授权响应的加密付款标志送给支付网关。
②支付网关处理付款请求:网关遍历信任链确认商家证书;支付网关用支付网关交换密钥的私钥对对称密钥解密,然后用该对称密钥对付款请求解密;网关用商家的公开密钥确认付款请求上商家的签名;支付网关用支付网关交换密钥的私钥对对称密钥解密,然后再用对称密钥对付款标志解密;支付网关确认商家的付款请求与付款标志一致;支付网关通过金融网络向客户金融机构发出付款请求;支付网关产生付款响应报文(包括网关签名证书),并用支付网关的私钥加密;支付网关用随机产生的对称密钥对付款响应加密,再用商家交换密钥的公钥对该对称密钥加密;支付网关将加密后的付款响应送商家。
③商家接收付款响应:商家遍历信任链确认支付网关证书;商家用其交换密钥的私钥对对称密钥解密,然后再用该对称密钥对付款响应解密;商家用支付网关的公钥确认付款响应上支付网关的签名;商家保存付款响应,以便日后与收单行对账。
从上述过程可见,以SET协议为基础的支付结算的每一步都有严格的规范,并大量采用对称和非对称加密算法、数字证书、数字摘要、数字签名、数字信封等安全技术,因此,以SET协议支持的网络支付应该非常安全,但又非常复杂。