电子商务安全协议及支付安全

电子商务关于网银的简介

5.1.1 SSL协议工作原理

SSL协议处于互联网多层协议集的传输层上，运行在TCP/IP协议之上而在其他高层协议（如HTTP、Telnet、FTP和IMAP等）之下，如图5-1所示。在建立一次SSL连接之前，首先建立TCP/IP连接。SSL协议可以让应用层协议透明地加以应用。运行时，支持SSL协议的服务器可以同一个支持SSL协议的客户机彼此认证自己，还允许这两个机器之间建立安全的加密连接，同时保证信息在传输过程中的完整性。

SSL协议可以分为4个子协议：SSL握手协议、SSL更改密码规程协议、SSL报警协议和SSL记录协议，其中最重要的两个协议是握手协议和记录协议。SSL记录协议定义了数据传送的格式，它位于一些可靠的传输层协议之上（如TCP），用于各种更高层协议的封装。SSL握手协议位于SSL记录协议之上，并被SSL记录协议所封装。它描述建立安全连接的过程，在客户和服务器传送应用层数据之前，该协议允许服务器与客户机之间协商加密算法和会话密钥，完成通信双方的身份验证等功能。

图5-1 SSL协议的分层结构

5.1.2 SSL记录协议

SSL记录协议（Record Protocol）定义了传输的格式，包括记录头和记录数据格式的规定。发送方记录层的工作过程如图5-2所示：

图5-2 记录层的工作过程

1.记录层从上层接收到任意大小的应用层数据块，把数据快分成不超过214字节的分片。 2.记录层用当前的会话状态中给出的压缩算法静分片压缩成一个压缩快，压缩操作是可选的。

3.每个会话都有相应“加密规格”指定了对称加密算法和MAC算法。记录层用指定的

电子商务关于网银的简介

MAC算法对压缩块计算MAC，用指定的对称加密算法加密压缩块和MAC，形成密文块。

4.对密文块添加SSL记录头，然后送到传输层，传输层受到这个SSL记录层数据单元后，记上TCP报头，得到TCP数据包。

图5-3 SSL记录协议中数据项的格式

5.1.3 SSL握手协议

图5-4 SSL建立新会话时的握手过程

1）建立新会话时的握手过程 握手协议用于数据传输之前。它可以进行服务器与客户之间的身份鉴别，同时通过服务器和客户协商，决定采用的协议版本、加密算法，并确定加密数据所需的对称密钥，随后采用公钥加密技术产生共享机密信息（例如对称密钥）。每次连接，握手协议都要建立一个会话。会话中包含了一套可在多次会话中使用的加密安全参数，从而减轻了每次建立会话的负担。然而，必须指出的是，SSL中的每次连接时，在握手协议中产生的对称密钥都是独特的，这种每次更换密钥的方法显然在更大程度上确保了系统的不易攻破性。

根据是否验证对方的证书，SSL的握手过程可以分为以下三种验证模式：客户和服务器都被验证；只验证客户机，不验证服务器，这是Internet上使用最广泛的形式；客户和服务器都不验证，也称为完全匿名模式。SSL握手协议建立一个新的会话的过程如图5-4所示，具体如下：

阶段1：确定一些相关参数，包括协议版本、会话ID、加密规格、压缩算法和初始随机数

（1）客户端发送client_hello消息给服务器，向服务器传送客户端支持的SSL协议的版

电子商务关于网银的简介

本号、加密算法的种类、MAC算法的种类、会话标识、密码属性（如hash块的大小），以及其他服务器和客户端之间通信所需要的各种信息。

（2）服务器以server_hello向客户应答，服务器端传选定的SSL协议的版本号、加密算法的种类、MAC算法的种类、密码属性及其他相关信息。

阶段2：服务器端发送自身证书（或临时公钥）及证书请求，最后发送hello阶段结束信号。

（3）如果需要验证服务器，服务器将发送certificate消息。服务器首先建立一个随机数，然后对这个随机数进行数字签名，将这个含有签名的随机数和服务器的证书，放在certificate消息中发送给客户端。若不需要验证服务器证书，服务器发送包含其临时公钥的server_key_exchange消息。

（4）若服务器需要验证客户，则发送certificate_request消息

（5）服务器发送hello_done消息，表示双方握手过程中的hello阶段结束。 阶段3：客户端验证服务器端证书、发送自身证书、交换对称密钥。

（6）客户利用服务器传过来的信息验证服务器的合法性，发送certificate_verify消息，确定验证通过。服务器的合法性包括：证书是否过期，发行服务器证书的CA是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通信将断开；如果合法性验证通过，则将继续进行下一步。

（7）客户端先随机产生一个用于后面通信的预主密码（pre-master-key），然后用服务器的公钥（从服务器的证书中获得）对其加密，再将加密后的预主密码通过client_key_exchange消息传给服务器。

（8）如果服务器要求客户的身份认证（在握手过程中为可选），客户端会首先建立一个随机数，然后对这个随机数进行数字签名，将这个含有签名的随机数和客户自己的证书放在certificate消息中，发送给服务器端。如果客户端没有证书，则会回应no_certificate告警。

阶段4：双方确定加密规格，结束握手协议。

（9）客户端向服务器端发出chenge_cipher_spec信息，指明后面的数据通信将“预主密码”为对称密钥，同时向服务器发送finished消息，表示完成了与服务器的握手。

（10）服务器检验客户证书和签名随机数的合法性，发送certificate_verify消息。具体的合法性验证包括：客户的证书使用日期是否有效，为客户提供证书的CA是否可靠，发行CA的公钥能否正确解开客户证书的发行CA的数字签名，检查客户的证书是否在证书撤销列表（CRL）中。检验如果没有通过，则通信立刻中断；如果验证通过，则服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生通信使用的主密码（master-key）（客户端也将通过同样的方法产生相同的主密码）。

（11）服务器向客户端发出change_cipher_spec信息，指明后面的数据通信将使用预主密码为对称密钥，同时发送finished消息，通知客户端服务器端的握手过程结束。

（12）SSL的握手部分结束，SSL安全通道的数据通信开始，客户和服务器开始使用相同的对称密钥进行数据通信，同时进行通信完整性的检验。

2）恢复一个已存在会话时的握手过程

由上可以看出，SSL协议的握手过程是非常好使的，为了减少握手过程的交互次数，以及对网络带宽的占用，可将双方经过完整握手过程建立起来的会话状态记录下来。在以后连接时，采用会话重用技术恢复会话过程，免去会话参数的协商。SSL握手协议恢复一个已存在的会话的过程如图5-5所示。

客户端发送client_hello消息给服务器，其中的session id是要恢复的会话的标识，服务器在会话缓存中检查是否有这个会话标识：若有，服务器将在相应的会话状态下建立一个新

电子商务关于网银的简介

的连接，服务器发送含有session id的server_hello；若没有，服务器会生成一个新的session id，建立一个新的会话过程。当通过恢复一个会话建立一个连接时，这个新的连接将继承这个会话状态下的压缩算法、加密规格和预主密码。但该连接会产生新的随机数和通信密码。

图5-5 SSL恢复一个已存在会话时的握手过程

5.1.4 SSL协议的缺陷 根据以上内容可知，SSL协议所采用的加密算法和认证算法使它具有一定的安全性，能够在一定程度上抵抗某些攻击。 除此之外SSL协议具备很强的灵活性，在浏览器中大都建有SSL功能。但是SSL协议也有很多缺陷，具体如下：

（1）密钥管理问题

设计一个安全秘密的密钥交换协议是很复杂的，因此，SSL握手协议中客户机和服务器在互相发送自己能够支持的加密算法时，是以明文传送的，存在被攻击修改的可能。

（2）加密强度问题

服务器证书分为高端和低端两种，高端证书加密强度比低端证书高。SSL通信中具体达到的加密强度与客户操作系统、浏览器版本、网络服务器的所采用的证书等因素相关。如许多客户的系统不支持128位强度的加密链接，即便服务器证书可以支持128位，客户端也自动降低加密强度，除非他采用了支持SCG技术的服务器证书（强制型），方可实现128位加密强度。因此，客户机的性能将会影响到SSL的安全性。

（3）数字签名问题

SSL协议对握手之后的通信内容没有数字签名功能，即没有抗否认服务。若要增加数字签名功能，则需要在协议中打“补丁”。这样做，在用于加密密钥的同时又用于数字签名，这在安全上存在漏洞。后来PKI体系完善了这种措施，即双密钥机制，将加密密钥和数字签名密钥二者分开，成为双证书机制。这是PKI完整的安全服务体系。

（4）必须建立在可靠连接基础上

SSL协议的底层协议仅限于TCP协议。由于SSL要求有TCP通道，所以对于使用UDP协议的DNS类型的应用场合是不适合的。

（5）多方通信表现欠佳

由于SSL的连接本质上是一对一的，所以在通信方只有两个的情况下它会工作的很好。在多对多的环境中，它的表现欠佳。

5.2.2 双重签名

双重签名是SET协议中的一个重要技术。生成双重签名的流程如图5-7所示。假设持卡人为C，商家为M，银行支付网关为B，则双重签名的生成过程如下：

电子商务关于网银的简介

图5-7 双重签名生成过程

（1） 产生发订购信息OI（Order Information）和支付指令PI（Payment Information）。 （2） 产生OI、PI的摘要H(OI)，H(PI)。 （3） 连接H(OI)和H(PI)得到OP， （4） 生成OP的摘要H(OP)，

（5） 用C的RSA私钥Kcp签名H(OP)，得到sign[H(OP)]，称为双重签名。

通过一系列交互和加解密过程，M将获得的数据包括OI、H(P1)和sign[H(OP)]，B将获得的数据包括PI、H(OI)和sign[H(OP)] 。下面以M为例，介绍验证双重签名的过程。C验证双重签名的过程与此相似，不再赘述。M验证双重签名的过程如图5-8所示，具体如下：

图5-8 双重签名验证过程

（1） 用收到的OI，生成H' (OI)

（2） 将H' (OI)与接收到的摘要H (PI)连接生成OP （3） 得到OP'的摘要H (OP')

（4） 用C公钥Kcu解开Sign[H(OP)]，得到H(OP)

（5） 比较H (OP')与H(OP)是否相同。如果相同，则表示数据完整且未被篡改。 在交易中持卡人发往银行的支付指令是通过商家转发的，双重签名避免了交易的过程中商家窃取持卡人的信用卡信息，也避免了行跟踪持卡人的行为，侵犯消费者隐私；同时还不影响商家和银行对持卡人所发信息的合理的验证，以及银行和商家之间的沟通，保证当商家同意持卡人的购买请求后再让银行给商家付费。

5.2.3 SET交易流程

SET协议由一系列请求/响应（Req/Res）信息对组成。SET协议信息结构共有6大部分：认证过程、交易初始化过程、购买指令执行过程、授权检验过程、扣款请求执行过程及持卡人查询过程。

SET信息结构中除了认证过程以外的其他过程构成了一个完成的购买交易流程，如图5-9所示。下面将介绍持卡人、商家和支付网关协同完成交易的具体步骤。

电子商务关于网银的简介

图5-9 SET协议交易流程

1)交易初始化 初始化请求的步骤为：

（1）持卡人选择SET支付方式时，商户软件唤醒持卡人的电子钱包。

（2）持卡人向商家发送初始请求。初始请求指定了交易环境，包括交易卡类型、持卡人所使用的语言、交易所在地识别码等

（3）对出示请求进行签名

（4）将签名的初始化请求和持卡人证书发送给商户 初始化响应步骤为：

（5）商家收到初始请求后产生交易ID。

（6）商家对包括交易ID在内的响应信息进行运算，生成消息摘要，对此消息摘要进行数字签名

（7）将交易识别码、数字签名、商家证书和支付网关证书等发送给持卡人。 持卡人收到初始化响应后： （8）验证商户证书和网关证书。 （9）验证商户的签名。 （10）保存初始化响应 2）购买

持卡人发出请求购买指令的过程为：

（1）产生定单信息OI和支付信息PI，PI中包含OI的摘要。 （2）生成OI和PI的双重签名。

（3）用随机产生的对称密钥K1加密PI 和双重签名，生成加密的支付信息；再用支付网关的公钥加密K1和持卡人的卡号信息，生成支付信封。

（4）将OI、双重签名、支付信封 、加密的支付信息、PI的摘要和持卡人证书一起发送给商户。

商户响应购买请求指令的过称为： （5）验证持卡人证书。

电子商务关于网银的简介

（6）验证双重签名。 （7）将PI送给支付网关。 （8）生成购物响应并进行签名。

（9）将购物响应、商户签名和商户证书传给持卡人。

（10）商户向支付网关请求授权，若授权成功，商户通知持卡人。 持卡人收到商户的购物响应后： （11）验证商户证书。

（12）验证购物响应中的商户签名。 （13）保存购物响应。 3）授权检验

商户请求支付网关授权的过程为：

（1）生成授权请求，包含交易ID和金额，并对请求进行签名

（2）用随机产生的对称密钥K2对授权请求进行加密，并用支付网关公钥将K2加密，生成授权请求数字信封。

（3）商户将加密的授权请求 、持卡人传来的经过加密的支付信息和支付信封、持卡人证书、商户证书传给网关。

支付网关响应授权请求的过程为： （4）验证商户证书。

（5）用私钥解密授权请求数字信封得到K2，再用K2解密授权请求。 （6）验证商户签名。 （7）验证持卡人证书。

（8）用私钥解密支付信封得到K1，再用K1解密支付信息。 （9）验证持卡人的双重签名。

（10）检查商户的授权请求中的交易ID与PI中的交易ID是否一致。

（11）将授权请求通过金融专网发送到发卡行，在银行内部网中查询持卡人的银行卡是否有支付能力，如果得到肯定回应，则继续进行下一步。

（12）生成授权响应信息并且签名。

（13）用随机产生的对称密钥K3加密授权响应，用商户的加密公钥加密K3生成授权响应信封。

（14）产生扣款令牌（Capture Token）并签名。

（15）用随机产生的对称密钥K4加密扣款令牌，用网关的加密公钥加密K4生成扣款令牌信封。

（16）将加密的授权响应和授权响应信封、加密扣款令牌和扣款令牌信封，以及支付网关证书一起传给商户。

商户收到授权响应后： （17）验证支付网关证书。

（18）用私钥解密授权响应信封得到K3，用K3解密授权响应。 （19）验证支付网关对授权响应的签名。

（20）保存加密扣款令牌和扣款令牌信封，以便以后请求扣款时使用。 （21）商户完成购物请求处理，确定交易成功，产生交易完成信息。 4）扣款

电子商务关于网银的简介

商户请求扣款的过程为：

（1）商户产生扣款请求，并对扣款请求签名。

（2）用随机产生的对称密钥K5加密扣款请求，用支付网关公钥加密K5，得到扣款请求信封。

（3）将加密的扣款请求和扣款请求信封、加密的扣款令牌和扣款令牌信封、商户证书一起发送给网关。

网关响应扣款请求的过程为： （4）验证商户证书。

（5）用网关私钥解密加密的扣款请求信封得到K5，再用K5解密扣款请求。 （6）验证扣款请求的商户签名。

（7）用网关私钥解密扣款令牌信封得到K4，再用K4解密扣款令牌。 （8）比较扣款请求和扣款令牌。

（9）将扣款请求通过金融专网发送到发卡行，有银行内部网完成扣款操作。 （10）生成扣款响应信息并且签名。

（11）用随机产生的对称密钥K6加密扣款响应，再用商户公钥加密K6生成扣款响应信封。

（12）将加密的扣款响应和扣款响应信封、网关证书一起传给商户。 商户收到网关的扣款响应后： （13）验证网关证书。

（14）用商户加密私钥解密扣款响应信封得到K6，用K6解密扣款响应。 （15）验证网关签名，确定扣款已完成。 5）持卡人查询过程

查询信息对允许持卡人核对交易状态，查询可以在购物之后的任何时间进行。持卡人只能查询有关自己的购物交易情况；对一笔交易，可查询多次。持卡人查询不是必须的，具体执行过程为：

（1）持卡人生成查询请求并签名，连同持卡人证书一起发送到商户。查询请求消息中包括交易ID。

（2）商户收到查询请求后，先验证消息是否来自持卡人，然后生成查询响应信息并签名，同商户证书一起送回。查询响应消息包括交易状态、结果码、是否已付款等。收到查询响应后，持卡人就知道了某交易是否已由商户认可，以及处理情况。

5.2.4 SET协议的优势和劣势 1）SET的优势

（1）认证机制方面，SET的安全需求较高，所有参与SET交易的成员都必须先申请数字证书来识别身份。

（2）对客户而言，SET保证了商家的合法性，并且用户的信用卡号不会被窃取。SET替客户保守了更多的秘密使其在线购物更加轻松。

（3）SET协议规定，交易过程中的每条消息都要经过严格检验，从而能更严密地保证交易安全。

（4）实际应用中，SET可以被用在系统的一部分或者全部。大多数SET软件提供商在其产品中都提供了灵活构筑系统的手段。

2）SET协议的缺陷

（1）SET交易过程不能保证客户付款后一定得到商品，以及得到的商品是否是自己订

电子商务关于网银的简介

购的。由于协议中采用的是款到后付货，一旦出现客户对商家提供的商品不满意，或是商品质量有问题时，不能保证客户的利益。

（2）SET没有解决交易中证据的生成和保留问题。SET技术规范没有提及在事务处理完成后，如何安全地保存或销毁支付数据。商家虽然无法获得客户的账户信息，但是他保留有经过加密的客户信息，这种漏洞可能会使这些数据以后受到潜在的攻击，仍存在着安全隐患，容易引起客户不放心。

（3）SET协议非常复杂，成本很高，处理速度慢，没有对时间进行控制，可能会出现由于时间的延误而导致的纠纷。SET交易过程中，需要多次传递证书、验证证书、进行签名、验证签名，多次进行对称加密、生成数字信封、拆封数字信封、解密对称密文，整个交易过程要花费较长时间。

（4）SET要求在银行网络、商户服务器、顾客的PC机上安装相应的软件，这给顾客、商家和银行增加了许多附加的费用，成为SET被广泛接受的障碍。SET要求必须向各方发放证书，也会增加更多成本。

SET协议机制过于复杂，成本过高，以至于到现在还没有得到市场的认可。目前，我国各大商业银行的网银均采用了SSL协议保证支付安全。中国银行在1996年开通网银业务时，曾经采用IBM公司开发的基于SET协议的电子商务解决方案，但目前已经回归主流，采用了SSL协议。

5.3.2银行卡安全支付模式

银行卡网上安全支付大多在基于SSL协议的环境下完成，在这个过程中，参与交易与支付的网商和银行需持有由CA认证中心颁发的数字证书，持卡人的数字证书不是必须的。支付过程遵守SSL协议的安全通信与控制机制，通过SSL协议实现信用卡信息和支付金额信息等安全在线传输，最终通过互联网完成交易支付和资金的划拨。支付流程如图5-11所示。

图5-11 基于SSL协议的银行卡支付流程

（1）持卡用户浏览网商的网页，选购商品和服务，填写订单。

（2）买方确认订单信息和资金金额，将订单提交给商家服务器，并选择信用卡支付。 （3）网商服务器向买方回复确认收到订单，同时网商服务器将用户的订单信息和支付信息经支付网关发送到发卡银行。

（4）客户端浏览器与发卡银行网络服务器进行安全连接，客户端自动验证发卡银行网络服务器的数字证书。

（5）验证结束后，SSL握手协议完成，持卡客户端与银行服务器端之间的安全连接已经建立，可以进行加密通信。

（6）在发卡银行的支付界面，会显示从网商服务器发来的订单信息及支付金额信息，买方在相应的栏目填入信用卡的相关信息，并确认支付。

（7）客户端收到支付成功信息，经买方确认后，SSL安全连接结束。

电子商务关于网银的简介

（8）发卡银行发送付款成功信息给网商，并进行转账结算。

（9）网商收到付款信息后，发送收款信息给买方，承诺发货，买方监督订单执行情况，交易结束。

5.3.3第三方支付模式 第三方支付中的所谓“第三方”是指在电子商务交易中除了交易主体和银行之外的第三种角色，它们通过第三方支付平台与银行和交易主体交互，完成资金划拨。第三方机构与各个主要银行之间签订有关协议，可以与银行进行某种形式的数据交换和相关信息确认。

目前国外最流行的支付第三方支付产品为PayPal。中国国内的第三方支付产品主要有支付宝、财付通、银联电子支付等，其中支付宝和财付通的市场份额分别为47%和24%。

图5-15 第三方支付模式示意图

以B2C交易为例，第三方支付的流程如图5-15所示，具体如下： （1）客户浏览检索商户网页达成交易意向，在商户网站下订单。 （2）客户选择第三方支付平台，直接链接到其安全支付服务器上 （3）在支付页面上选择自己适用的支付方式，点击后进入银行支付页面进行支付操作，将货款支付到第三方支付平台的账号。

（4）第三方支付平台将网上消费者的支付信息，按照各银行支付网关的技术要求，传递到各相关银行。

（5）由相关银行（银联）检查网上消费者的支付能力，实行冻结、扣帐或划帐，并将结果信息传至第三方支付平台和网上消费者本身。

（6）第三方支付平台将支付结果通知商户。

（7）支付成功的，由商户向网上消费者发货或提供服务。 （8）商家确认收到货，通知第三方支付平台向商家划拨货款。

（9）第三方支付平台与各个银行交互，将资金划拨到商户的第三方支付账号。 5.3.4 电子现金支付模式

电子现金的支付涉及到网商、用户与电子现金的发行银行三个主体，由银行负责身份认证和交易双方之间的资金转移，银行和卖方之间应有协议和授权关系。具体的使用过程如图5-16

所示。

电子商务关于网银的简介

图5-16 电子现金的支付过程

（1）用户、网商和电子现金发行银行分别安装电子现金应用软件，网商和银行还分别从CA中心申请数字证书，并获得公钥和私钥。

（2）用户在电子现金发行银行开设电子现金账号，存入一定量的资金。当用户需要电子现金时，首先在线验证银行身份，然后利用电子现金客户端软件，激活电子现金制作过程，兑换一定数量的电子现金。

（3）客户利用客户端软件从银行将兑换的电子现金下载到本地，存放在硬盘或电子钱包或IC卡上。

（4）网商与电子现金发行银行之间在电子现金使用、审核、兑换等方面有协议和授权关系。

（5）用户验证网上商家的真实身份，并确认能够接收客户的电子现金。在提交订单的同时，选择电子现金支付方式。

（6）用户把订单和电子现金通过网络发送给网商。在传输过程中，客户采用网商的公钥对电子现金进行加密，网商收到后利用自己的私钥解密出电子现金数据。电子现金的传输过程无需银行介入。

（7）网商收到电子现金后，将其发送到发行银行进行审核和资金清算，电子现金经过银行核实后，将相同金额的资金转入商家账户。

（8）网商确认收到货款，然后按客户订单组织发货。 5.3.5 电子支票支付模式

图5-17 电子支票的支付过程

电子支票的支付包括支票的购买、支付和清算三个过程，如图5-17所示。 （1）电子支票购买

买方首先在提供电子支票服务的银行进行注册，被授权可以使用银行提供的支票生成工具开具支票。电子支票应有银行的数字签名。

（2）电子支票支付

①由买卖双方协商，决定采用电子支票支付方式，并通过CA确定交易双方的身份； ②买方用自己的私有密钥在电子支票上进行数字签名，使用卖方的公钥加密电子支票，使卖方成为唯一的合法接收者，并通过网络将支票传送给卖方；

③卖方用自己的私有密钥解密电子支票，用买方的公钥确认买方的数字签名，再用银行的公钥进一步确认电子支票；

④如果支票上的银行签名真实有效，卖方发货给买方或提供相应的服务。 （3）电子支票清算

卖方用自己的私钥对电子支票签名背书，定期将电子支票存到银行，银行对支票进行买方、卖方以及自己签名的验证，如果验证通过，进行清算并允许支票转账结算，否则拒绝交易。

本文来源：https://www.bwwdw.com/article/4gbe.html