电商安全协议及支付安全

1、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记录协议定义了数据传

2、送的格式，它位于一些可靠的传输层协议之上（如TCP），用于各种更高层协议的封装。SSL握手协议位于SSL记录协议之上，并被SSL记录协议所封装。它描述建立安全连接的过程，在客户和服务器传送应用层数据之前，该协议允许服务器与客户机之间协商加密算法和会话密钥，完成通信双方的身份验证等功能。应用层协议（HTTP、Telnet、FTP、IMAP等）SSL握手协议SSL更改密码规程协议SSL报警协议SSL记录协议TCP协议IP协议图5-1 SSL协议的分层结构5.1.2 SSL记录协议SSL记录协议（Record Protocol）定义了传输的格式，包括记录头和记录数据格式的规定。发送方记录层的工作过程

3、如图5-2所示： 分 片添加 MAC压 缩加 密添加SSL 记录头计算MAC图5-2 记录层的工作过程1. 记录层从上层接收到任意大小的应用层数据块，把数据快分成不超过214字节的分片。2. 记录层用当前的会话状态中给出的压缩算法静分片压缩成一个压缩快，压缩操作是可选的。3. 每个会话都有相应“加密规格”指定了对称加密算法和MAC算法。记录层用指定的MAC算法对压缩块计算MAC，用指定的对称加密算法加密压缩块和MAC，形成密文块。4. 对密文块添加SSL记录头，然后送到传输层，传输层受到这个SSL记录层数据单元后，记上TCP报头，得到TCP数据包。MAC数据 实际数据 附加数据图5-3 SSL

4、记录协议中数据项的格式5.1.3 SSL握手协议客户机服务器server_hellocertificateserver_key_exchange*certificate_request*hello_donecertificate_verifyclient_key_exchangeCertificate*change_cipher_specfinishedcertificate_verify*finishedchange_cipher_specclient_hellono_certificate*Step1：确定一些相关参数，包括协议版本、会话ID、加密规格、压缩算法和初始随机数Step2：服务

5、器端发送自身证书（或临时公钥）及证书请求，最后发送hello阶段结束信号。Step3：客户端验证服务器端证书、发送自身证书、交换对称密钥。Step4：双方确定加密规格，结束握手协议。图5-4 SSL建立新会话时的握手过程1）建立新会话时的握手过程握手协议用于数据传输之前。它可以进行服务器与客户之间的身份鉴别，同时通过服务器和客户协商，决定采用的协议版本、加密算法，并确定加密数据所需的对称密钥，随后采用公钥加密技术产生共享机密信息（例如对称密钥）。每次连接，握手协议都要建立一个会话。会话中包含了一套可在多次会话中使用的加密安全参数，从而减轻了每次建立会话的负担。然而，必须指出的是，SSL中的每次

6、连接时，在握手协议中产生的对称密钥都是独特的，这种每次更换密钥的方法显然在更大程度上确保了系统的不易攻破性。根据是否验证对方的证书，SSL的握手过程可以分为以下三种验证模式：客户和服务器都被验证；只验证客户机，不验证服务器，这是Internet上使用最广泛的形式；客户和服务器都不验证，也称为完全匿名模式。SSL握手协议建立一个新的会话的过程如图5-4所示，具体如下：阶段1：确定一些相关参数，包括协议版本、会话ID、加密规格、压缩算法和初始随机数（1） 客户端发送client_hello消息给服务器，向服务器传送客户端支持的SSL协议的版本号、加密算法的种类、MAC算法的种类、会话标识、密码属性

7、（如hash块的大小），以及其他服务器和客户端之间通信所需要的各种信息。（2） 服务器以server_hello向客户应答，服务器端传选定的SSL协议的版本号、加密算法的种类、MAC算法的种类、密码属性及其他相关信息。阶段2：服务器端发送自身证书（或临时公钥）及证书请求，最后发送hello阶段结束信号。（3） 如果需要验证服务器，服务器将发送certificate消息。服务器首先建立一个随机数，然后对这个随机数进行数字签名，将这个含有签名的随机数和服务器的证书，放在certificate消息中发送给客户端。若不需要验证服务器证书，服务器发送包含其临时公钥的server_key_exchange

8、消息。（4） 若服务器需要验证客户，则发送certificate_request消息（5） 服务器发送hello_done消息，表示双方握手过程中的hello阶段结束。阶段3：客户端验证服务器端证书、发送自身证书、交换对称密钥。（6） 客户利用服务器传过来的信息验证服务器的合法性，发送certificate_verify消息，确定验证通过。服务器的合法性包括：证书是否过期，发行服务器证书的CA是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通信将断开；如果合法性验证通过，则将继续进行下一步。（7）

9、客户端先随机产生一个用于后面通信的预主密码（pre-master-key），然后用服务器的公钥（从服务器的证书中获得）对其加密，再将加密后的预主密码通过client_key_exchange消息传给服务器。（8） 如果服务器要求客户的身份认证（在握手过程中为可选），客户端会首先建立一个随机数，然后对这个随机数进行数字签名，将这个含有签名的随机数和客户自己的证书放在certificate消息中，发送给服务器端。如果客户端没有证书，则会回应no_certificate告警。阶段4：双方确定加密规格，结束握手协议。（9） 客户端向服务器端发出chenge_cipher_spec信息，指明后面的数据通

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

11、出change_cipher_spec信息，指明后面的数据通信将使用预主密码为对称密钥，同时发送finished消息，通知客户端服务器端的握手过程结束。（12） SSL的握手部分结束，SSL安全通道的数据通信开始，客户和服务器开始使用相同的对称密钥进行数据通信，同时进行通信完整性的检验。2）恢复一个已存在会话时的握手过程由上可以看出，SSL协议的握手过程是非常好使的，为了减少握手过程的交互次数，以及对网络带宽的占用，可将双方经过完整握手过程建立起来的会话状态记录下来。在以后连接时，采用会话重用技术恢复会话过程，免去会话参数的协商。SSL握手协议恢复一个已存在的会话的过程如图5-5所示。客户端发

12、送client_hello消息给服务器，其中的session id是要恢复的会话的标识，服务器在会话缓存中检查是否有这个会话标识：若有，服务器将在相应的会话状态下建立一个新的连接，服务器发送含有session id的server_hello；若没有，服务器会生成一个新的session id，建立一个新的会话过程。当通过恢复一个会话建立一个连接时，这个新的连接将继承这个会话状态下的压缩算法、加密规格和预主密码。但该连接会产生新的随机数和通信密码。客户机服务器change_cipher_specfinishedfinishedchange_cipher_specserver_helloclient

13、_helloStep2：更改加密规格，结束握手协议Step1：从会话缓存中恢复一个已经存在的对话图5-5 SSL恢复一个已存在会话时的握手过程5.1.4 SSL协议的缺陷根据以上内容可知，SSL协议所采用的加密算法和认证算法使它具有一定的安全性，能够在一定程度上抵抗某些攻击。 除此之外SSL协议具备很强的灵活性，在浏览器中大都建有SSL功能。但是SSL协议也有很多缺陷，具体如下：（1）密钥管理问题设计一个安全秘密的密钥交换协议是很复杂的，因此，SSL握手协议中客户机和服务器在互相发送自己能够支持的加密算法时，是以明文传送的，存在被攻击修改的可能。（2）加密强度问题服务器证书分为高端和低端两种，

14、高端证书加密强度比低端证书高。SSL通信中具体达到的加密强度与客户操作系统、浏览器版本、网络服务器的所采用的证书等因素相关。如许多客户的系统不支持128位强度的加密链接，即便服务器证书可以支持128位，客户端也自动降低加密强度，除非他采用了支持SCG技术的服务器证书（强制型），方可实现128位加密强度。因此，客户机的性能将会影响到SSL的安全性。（3）数字签名问题SSL协议对握手之后的通信内容没有数字签名功能，即没有抗否认服务。若要增加数字签名功能，则需要在协议中打“补丁”。这样做，在用于加密密钥的同时又用于数字签名，这在安全上存在漏洞。后来PKI体系完善了这种措施，即双密钥机制，将加密密钥和

15、数字签名密钥二者分开，成为双证书机制。这是PKI完整的安全服务体系。（4）必须建立在可靠连接基础上SSL协议的底层协议仅限于TCP协议。由于SSL要求有TCP通道，所以对于使用UDP协议的DNS类型的应用场合是不适合的。（5）多方通信表现欠佳由于SSL的连接本质上是一对一的，所以在通信方只有两个的情况下它会工作的很好。在多对多的环境中，它的表现欠佳。 5. 2 SET协议5.2.2 双重签名双重签名是SET协议中的一个重要技术。生成双重签名的流程如图5-7所示。假设持卡人为C，商家为M，银行支付网关为B，则双重签名的生成过程如下：OIPIH(OI)H(PI)OPSig ( H(OP)H(OP)

16、HashHashRSAKcp图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)，得到signH(OP)，称为双重签名。通过一系列交互和加解密过程，M将获得的数据包括OI、H(P1)和signH(OP)，B将获得的数据包括PI、H(OI)和signH(OP) 。下面以M为例，介绍验证双重签名的过程。C验证双重签名的过程与此相似，

17、不再赘述。M验证双重签名的过程如图5-8所示，具体如下：OIH (OI)OPH(OP)HashRSAKcuH(PI)Sig ( H(OP)H(OP)HashM接收到的数据比较图5-8 双重签名验证过程（1） 用收到的OI，生成H (OI)（2） 将H (OI)与接收到的摘要H (PI)连接生成OP（3） 得到OP的摘要H (OP)（4） 用C公钥Kcu解开SignH(OP)，得到H(OP)（5） 比较H (OP)与H(OP)是否相同。如果相同，则表示数据完整且未被篡改。在交易中持卡人发往银行的支付指令是通过商家转发的，双重签名避免了交易的过程中商家窃取持卡人的信用卡信息，也避免了行跟踪持卡人的

18、行为，侵犯消费者隐私；同时还不影响商家和银行对持卡人所发信息的合理的验证，以及银行和商家之间的沟通，保证当商家同意持卡人的购买请求后再让银行给商家付费。5.2.3 SET交易流程SET协议由一系列请求/响应（Req/Res）信息对组成。SET协议信息结构共有6大部分：认证过程、交易初始化过程、购买指令执行过程、授权检验过程、扣款请求执行过程及持卡人查询过程。SET信息结构中除了认证过程以外的其他过程构成了一个完成的购买交易流程，如图5-9所示。下面将介绍持卡人、商家和支付网关协同完成交易的具体步骤。持卡人商家交易初始化响应PInit Res购买请求PReq购买响应PRes授权请求Auth Re

19、q授权响应Auth Res扣款请求Cap Req扣款响应Cap Res查询请求Inq Req*交易初始化请求PInit Req查询响应Inq RPs*支付网关图5-9 SET协议交易流程1)交易初始化初始化请求的步骤为：（1） 持卡人选择SET支付方式时，商户软件唤醒持卡人的电子钱包。（2） 持卡人向商家发送初始请求。初始请求指定了交易环境，包括交易卡类型、持卡人所使用的语言、交易所在地识别码等（3） 对出示请求进行签名（4） 将签名的初始化请求和持卡人证书发送给商户初始化响应步骤为：（5） 商家收到初始请求后产生交易ID。（6） 商家对包括交易ID在内的响应信息进行运算，生成消息摘要，对此消

20、息摘要进行数字签名（7） 将交易识别码、数字签名、商家证书和支付网关证书等发送给持卡人。 持卡人收到初始化响应后：（8） 验证商户证书和网关证书。（9） 验证商户的签名。（10） 保存初始化响应2）购买持卡人发出请求购买指令的过程为：（1） 产生定单信息OI和支付信息PI，PI中包含OI的摘要。 （2） 生成OI和PI的双重签名。 （3） 用随机产生的对称密钥K1加密PI 和双重签名，生成加密的支付信息；再用支付网关的公钥加密K1和持卡人的卡号信息，生成支付信封。（4） 将OI、双重签名、支付信封 、加密的支付信息、PI的摘要和持卡人证书一起发送给商户。商户响应购买请求指令的过称为：（5） 验

21、证持卡人证书。（6） 验证双重签名。（7） 将PI送给支付网关。（8） 生成购物响应并进行签名。（9） 将购物响应、商户签名和商户证书传给持卡人。（10） 商户向支付网关请求授权，若授权成功，商户通知持卡人。持卡人收到商户的购物响应后：（11） 验证商户证书。（12） 验证购物响应中的商户签名。 （13） 保存购物响应。3）授权检验商户请求支付网关授权的过程为：（1） 生成授权请求，包含交易ID和金额，并对请求进行签名（2） 用随机产生的对称密钥K2对授权请求进行加密，并用支付网关公钥将K2加密，生成授权请求数字信封。（3） 商户将加密的授权请求 、持卡人传来的经过加密的支付信息和支付信封、持

22、卡人证书、商户证书传给网关。支付网关响应授权请求的过程为：（4） 验证商户证书。（5） 用私钥解密授权请求数字信封得到K2，再用K2解密授权请求。（6） 验证商户签名。（7） 验证持卡人证书。（8） 用私钥解密支付信封得到K1，再用K1解密支付信息。（9） 验证持卡人的双重签名。（10） 检查商户的授权请求中的交易ID与PI中的交易ID是否一致。（11） 将授权请求通过金融专网发送到发卡行，在银行内部网中查询持卡人的银行卡是否有支付能力，如果得到肯定回应，则继续进行下一步。（12） 生成授权响应信息并且签名。（13） 用随机产生的对称密钥K3加密授权响应，用商户的加密公钥加密K3生成授权响应信

23、封。（14） 产生扣款令牌（Capture Token）并签名。（15） 用随机产生的对称密钥K4加密扣款令牌，用网关的加密公钥加密K4生成扣款令牌信封。（16） 将加密的授权响应和授权响应信封、加密扣款令牌和扣款令牌信封，以及支付网关证书一起传给商户。商户收到授权响应后：（17） 验证支付网关证书。（18） 用私钥解密授权响应信封得到K3，用K3解密授权响应。（19） 验证支付网关对授权响应的签名。（20） 保存加密扣款令牌和扣款令牌信封，以便以后请求扣款时使用。（21） 商户完成购物请求处理，确定交易成功，产生交易完成信息。4）扣款商户请求扣款的过程为：（1） 商户产生扣款请求，并对扣款请

24、求签名。（2） 用随机产生的对称密钥K5加密扣款请求，用支付网关公钥加密K5，得到扣款请求信封。（3） 将加密的扣款请求和扣款请求信封、加密的扣款令牌和扣款令牌信封、商户证书一起发送给网关。网关响应扣款请求的过程为：（4） 验证商户证书。（5） 用网关私钥解密加密的扣款请求信封得到K5，再用K5解密扣款请求。（6） 验证扣款请求的商户签名。（7） 用网关私钥解密扣款令牌信封得到K4，再用K4解密扣款令牌。（8） 比较扣款请求和扣款令牌。（9） 将扣款请求通过金融专网发送到发卡行，有银行内部网完成扣款操作。（10） 生成扣款响应信息并且签名。（11） 用随机产生的对称密钥K6加密扣款响应，再用商

25、户公钥加密K6生成扣款响应信封。（12） 将加密的扣款响应和扣款响应信封、网关证书一起传给商户。商户收到网关的扣款响应后：（13） 验证网关证书。（14） 用商户加密私钥解密扣款响应信封得到K6，用K6解密扣款响应。（15） 验证网关签名，确定扣款已完成。5）持卡人查询过程查询信息对允许持卡人核对交易状态，查询可以在购物之后的任何时间进行。持卡人只能查询有关自己的购物交易情况；对一笔交易，可查询多次。持卡人查询不是必须的，具体执行过程为：（1） 持卡人生成查询请求并签名，连同持卡人证书一起发送到商户。查询请求消息中包括交易ID。（2） 商户收到查询请求后，先验证消息是否来自持卡人，然后生成查询

26、响应信息并签名，同商户证书一起送回。查询响应消息包括交易状态、结果码、是否已付款等。收到查询响应后，持卡人就知道了某交易是否已由商户认可，以及处理情况。5.2.4 SET协议的优势和劣势1）SET的优势（1）认证机制方面，SET的安全需求较高，所有参与SET交易的成员都必须先申请数字证书来识别身份。（2）对客户而言，SET保证了商家的合法性，并且用户的信用卡号不会被窃取。SET替客户保守了更多的秘密使其在线购物更加轻松。（3）SET协议规定，交易过程中的每条消息都要经过严格检验，从而能更严密地保证交易安全。（4）实际应用中，SET可以被用在系统的一部分或者全部。大多数SET软件提供商在其产品中

27、都提供了灵活构筑系统的手段。2）SET协议的缺陷（1）SET交易过程不能保证客户付款后一定得到商品，以及得到的商品是否是自己订购的。由于协议中采用的是款到后付货，一旦出现客户对商家提供的商品不满意，或是商品质量有问题时，不能保证客户的利益。（2）SET没有解决交易中证据的生成和保留问题。SET技术规范没有提及在事务处理完成后，如何安全地保存或销毁支付数据。商家虽然无法获得客户的账户信息，但是他保留有经过加密的客户信息，这种漏洞可能会使这些数据以后受到潜在的攻击，仍存在着安全隐患，容易引起客户不放心。（3）SET协议非常复杂，成本很高，处理速度慢，没有对时间进行控制，可能会出现由于时间的延误而导

28、致的纠纷。SET交易过程中，需要多次传递证书、验证证书、进行签名、验证签名，多次进行对称加密、生成数字信封、拆封数字信封、解密对称密文，整个交易过程要花费较长时间。（4）SET要求在银行网络、商户服务器、顾客的PC机上安装相应的软件，这给顾客、商家和银行增加了许多附加的费用，成为SET被广泛接受的障碍。SET要求必须向各方发放证书，也会增加更多成本。SET协议机制过于复杂，成本过高，以至于到现在还没有得到市场的认可。目前，我国各大商业银行的网银均采用了SSL协议保证支付安全。中国银行在1996年开通网银业务时，曾经采用IBM公司开发的基于SET协议的电子商务解决方案，但目前已经回归主流，采用了

29、SSL协议。5.3.2银行卡安全支付模式银行卡网上安全支付大多在基于SSL协议的环境下完成，在这个过程中，参与交易与支付的网商和银行需持有由CA认证中心颁发的数字证书，持卡人的数字证书不是必须的。支付过程遵守SSL协议的安全通信与控制机制，通过SSL协议实现信用卡信息和支付金额信息等安全在线传输，最终通过互联网完成交易支付和资金的划拨。支付流程如图5-11所示。认证认证认证银行专用网互联网订货、收款信息用户CA认证中心网商收单银行支付网关信用卡、授权支付信息发卡银行图5-11 基于SSL协议的银行卡支付流程（1） 持卡用户浏览网商的网页，选购商品和服务，填写订单。（2） 买方确认订单信息和资金

30、金额，将订单提交给商家服务器，并选择信用卡支付。（3） 网商服务器向买方回复确认收到订单，同时网商服务器将用户的订单信息和支付信息经支付网关发送到发卡银行。（4） 客户端浏览器与发卡银行网络服务器进行安全连接，客户端自动验证发卡银行网络服务器的数字证书。（5） 验证结束后，SSL握手协议完成，持卡客户端与银行服务器端之间的安全连接已经建立，可以进行加密通信。（6） 在发卡银行的支付界面，会显示从网商服务器发来的订单信息及支付金额信息，买方在相应的栏目填入信用卡的相关信息，并确认支付。（7） 客户端收到支付成功信息，经买方确认后，SSL安全连接结束。（8） 发卡银行发送付款成功信息给网商，并进行

31、转账结算。（9） 网商收到付款信息后，发送收款信息给买方，承诺发货，买方监督订单执行情况，交易结束。5.3.3第三方支付模式第三方支付中的所谓“第三方”是指在电子商务交易中除了交易主体和银行之外的第三种角色，它们通过第三方支付平台与银行和交易主体交互，完成资金划拨。第三方机构与各个主要银行之间签订有关协议，可以与银行进行某种形式的数据交换和相关信息确认。目前国外最流行的支付第三方支付产品为PayPal。中国国内的第三方支付产品主要有支付宝、财付通、银联电子支付等，其中支付宝和财付通的市场份额分别为47%和24%。客户商户银行第三方支付平台支付网关图5-15 第三方支付模式示意图以B2C交易为例

32、，第三方支付的流程如图5-15所示，具体如下：（1） 客户浏览检索商户网页达成交易意向，在商户网站下订单。（2） 客户选择第三方支付平台，直接链接到其安全支付服务器上（3） 在支付页面上选择自己适用的支付方式，点击后进入银行支付页面进行支付操作，将货款支付到第三方支付平台的账号。（4） 第三方支付平台将网上消费者的支付信息，按照各银行支付网关的技术要求，传递到各相关银行。（5） 由相关银行（银联）检查网上消费者的支付能力，实行冻结、扣帐或划帐，并将结果信息传至第三方支付平台和网上消费者本身。（6） 第三方支付平台将支付结果通知商户。（7） 支付成功的，由商户向网上消费者发货或提供服务。（8） 商家确认收到货，通知第三方支付平台向商家划拨货款。（9） 第三方支付平台与各个银行交互，将资金划拨到商户的第三方支付