set协议的补充知识

SET协议

1.SET协议概述

1995年，包括MasterCard、IBM和Netscape在内的联盟开始着手进行安全电子支付协议（SEPP）的开发，VISA和微软组成的联盟开始开发安全交易技术（STT）。由于两大信用卡组织MasterCard和VISA分别支持独立的网络支付解决方案，影响了网络支付的发展。1996年这些公司宣布它们将联合开发一种统一的标准，叫安全电子交易（SET）。1997年5月，SET协议由VISA和MasterCard两大信用卡公司联合推出，在Internet支付产业中许多重要的组织，如IBM、HP、Microsoft，Netscape、GTE，V erisign等都声明支持SET。SET 协议已获得IETF标准认可，已成为事实上的工业标准。SET主要由3个文件组成，分别是SET业务描述、SET程序员指南和SET协议描述。

SET主要是为了解决用户、商家和银行之间通过信用卡支付的交易而设计的，以保证支付信息的机密、支付过程的完整、商户及持卡人的合法身份、以及可操作性。SET非常详细而准确地反映了交易各方之间存在的各种关系。它定义了加密信息的格式和付款支付交易过程中各方传输信息的规则。SET提供了持卡人、商家和银行之间的认证，确保了网上交易数据的机密性、数据的完整性及交易的不可抵赖性。

2. SET协议的参与者

在SET协议系统中，交易的参与者主要有：

（1）持卡人（Cardholder）：在电子商务环境中，持卡人通过计算机和网络访问电子商家，购买商品。为了在电子商务环境中安全地进行支付操作，持卡人需要安装一套基于SET 标准的软件（通常嵌入在浏览器中），并使用由发卡行发行的支付卡，而且需要从认证中心获取自己的数字签名证书；

（2）商家（Merchant）：在电子商务环境中，商家通过自己的网站向客户提供商品和服务。同时商家必须与相关的收单行达成协议，保证可以接受信用卡的支付。而且商家也需要从认证中心获取相应的数字证书（包括签名证书和交换密钥证书）：

（3）发卡行（Issuer）：发卡行为每一个持卡人建立一个账户，并发放支付卡。一个发卡行必须保证对经过授权的交易进行付款；

（4）收单行（Acquirer）：收单行为每一个网上商家建立一个账户，且处理付款授权和付款结算等。收单行不属于安全电子商务的直接组成部分，但它是授权交易与付款结算操作的主要参与者；

（5）支付网关（PaymentGateway）：支付网关是指收单行或指定的第三方运行的一套设备。它负责处理支付卡的授权和支付。同时，它要能够同收单行的交易处理主机通信，还需要从认证中心获取相应的数字证书（包括签名证书和交换密钥证书）；

（6）品牌（Brand）：通常金融机构需要建立不同的支付卡品牌，每种支付卡品牌都有不同的规则，支付卡品牌将确定发卡行、收单行与持卡人和商家之间的关系；

（7）认证中心（CertifieateAuthority）：它负责颁发和撤销持卡人、商家和支付网关的数字证书；同时，它还要向商家和支付网关颁发交换密钥证书，以便在支付过程中交换会话

密钥。

在实际的系统中，发卡行和收单行可以由同一家银行担当，支付网关也可由该银行来运行，这些需要根据具体的情况来决定。

3.SET协议的安全机制

SET协议同时是PKI框架下的一个典型实现。安全核心技术主要有公开密钥加密、数字签名、数字信封、消息摘要、数字证书等，主要应用于B2C模式中保障支付信息的安全性。任何一个信任CA的通信方，都可以通过验证对方数字证书上的CA数字签名来建立起与对方的信任关系，并且获得对方的公钥。为了保证CA所签发证书的通用性，通常证书格式遵守ITU X.509标准。

根据SET标准，对证书通过信任级联关系用分层结构进行管理。SET定义了一套完备的证书信任链，每个证书连接一个实体的数字签名证书。沿着信任树可以到一个众所周知的信任机构，用户可以确认证书的有效性。对于所有使用SET的实体来说，只有唯一的根CA。图1-描述了这种信任层次。在SET中用户对根节点的证书是无条件信任的，如果从证书所对应的节点出发沿着信任树逐级验证证书的数字签名，若能够到达一个已知的信任方所对应的节点或根节点，就能确认该证书是有效的。换而言之，信任关系是从根节点到树叶传播的。根密钥（RootKey）由CA自己签名发布，而根密钥证书由软件开发商插入他们的软件中。软件通过向CA发出一个初始化请求（包括证书的Hash值），可以确定一个根密钥的有效性。根密钥也需定期更换。为了保证根证书的真实性，根证书和下一次的替换密钥的公钥的散列值一起颁发。在根证书被新的证书替代时，可通过验证证书中公钥的散列值与最近的旧证书一起颁发的散列值是否相同来对新证书的真实性进行验证。

图1 SET协议中证书的层次模型

持卡人证书、商户证书、支付网关证书分别由持卡人认证中心（CCA）、商户认证中心（MCA）、支付网关认证中心（PCA）进行颁发，而CCA证书、MCA证书和PCA证书则由品牌认证中心（BCA）或区域性认证中心（GCA）进行颁发。BCA的证书由根认证中心（RCA）进行颁发。

（l）持卡人证书（Cardholder CertifiCates）：持卡人证书相当于支付卡的电子表示，它

可以由付款银行数字签名后发放。由于证书的签名私钥仅为付款银行所知，所以证书中的内容不可能被任何第三方更改。持卡人证书只有在付款银行的同意下发给持卡人。该证书同购买请求和加密后的付款指令一起发给商家，商家在验证此证书有效后，就可以认为持卡人为合法的使用者。持卡人的证书是一个数字签名证书，用于验证持卡人的数字签名，而不能用于会话密钥的交换。任何持卡人只有在申请到数字证书之后，才能够进行电子交易；

（2）商家证书（Merchant Certificates）：商家证书表示商家与收单行有联系，收单行同意商家接受付款卡支付。商家证书由收单行数字签名后颁发。商家要加入SET的交易至少要拥有一对证书：一个为签名证书，用来让其他用户验证商家对交易信息的数字签名；另一个为交换密钥证书，用来在交易过程中交换用于加密交易信息的会话密钥。事实上，一个商家通常拥有多对证书，以支持不同品牌的付款卡；

（3）支付网关证书（Payment Gateway Certificates）：支付网关证书用于商家和持卡人在进行支付处理时对支付网关进行确认以及交换会话密钥，因此一个支付网关也应该拥有两个证书：签名证书和交换密钥证书。持卡人在支付时从支付网关的交换密钥证书中得到保护他的支付卡账号及密码的公开密钥。通常支付网关证书由付款卡品牌CA发给收单行；

（4）收单行证书（Acquirer Certificates）：收单行必须拥有一个证书以便运行一个证书颁发机构，它接受和处理商家通过公共网络或私有网络传来的证书请求和授权信息。收单行证书由付款卡品牌CA发给收单行；

（5）发卡行证书（Issuer CertifiCates）：发卡行必须拥有一个证书以便运行一个证书颁发机构，它接受和处理持卡人通过公共网络或私有网络传来的证书请求和授权信息。发卡行证书由付款卡品牌CA发给发卡行。

SET协议使用密码技术来保障交易的安全，主要包括散列函数、对称加密算法和非对称加密算法等。SET中默认使用的散列函数是SHA，对称密码算法则通常采用DES，公钥密码算法一般采用RSA。

在用RSA加密时，如果直接对明文加密，那么对密文进行分析，从而得到明文的一些比特是可能的，而且这样的技术确实存在。因此，SET在数字信封中用RSA加密会话密钥或是持卡人账号的时候，首先用OAEP算法对明文编码。OAEP算法的作用是使消息的各比特之间相互联系在一起，从而使得根据密文来求解明文的任意比特的难度是相同的。

4. SET协议的数据封装

SET协议经常使用的数据封装格式包括数字信封封装和双数字签名封装以及相应的数据封装格式。

（1）持卡人账号的盲化及散列消息封装

散列函数在SET中除了与签名算法结合使用以及进行消息的完整性验证之外，还用来保护持卡人账号的安全。在持卡人证书中不直接包含账号信息，而是把它盲化以后放入证书中。在盲化账号时，使用散列函数和持卡人与CCA共享的密码值。将共享的密码值（记为k）作为密钥，以账号、有效期等相关信息作为信息（记为t），计算带密钥的散列值HMAC （t，k）作为盲化的账号放入证书。因此只有CCA、持卡人和发卡行才能对账号进行认证。（2）数字签名（Digital Signature）封装

SET协议数字签名数据的封装格式使用PKCS#10中SignedData数据格式，如图2所示。

图2 SignedData数据格式

（3）数字信封（Digital Envelope）封装

在SET中，数字信封的封装的详细格式使用了PKCS#10中的EnvelopedData，如图3所示。其中加密数据的封装格式使用了PKCS#10中的EncryptedData，如图4所示。

图3 EnvolopedData数据格式

图4 EncryptedData数据格式

（4）双数字签名（Dua1 Signature）封装

在SET的交易流程中，持卡人在支付的时候需要对订单信息（OI）和支付信息（PI）进行双数字签名。双数字签名的作用是一方面使得商家能够验证持卡人确实对OI和PI进行了签名，但只能看到OI，而不知道PI的具体内容；而另一方面使得支付网关能够验证持卡人确实对OI和PI进行了签名，但只能看到PI，而不知道OI的具体内容。事实上双数字签名只是对签名的内容和数据的封装作了改动。双重数字签名的实现过程如下图5所示。

1）持卡人分别计算OI和Pl的消息摘要OI digest和PI digest；

2）计算OI digest | PI digest的消息摘要Digest，|表示比特串的连接；

3）持卡人用自己的签名私钥对Digest签名。

图5 双数字签名

持卡人将PI digest、OI和双数字签名经数字信封加密后发送给商家，将OI digest、PI 和双数字签名经数字信封加密后经由商家转发给支付网关。商家解开信封，生成订单的摘要后和账号的摘要连接起来，用持卡人证书的签名公钥即可验证签名。

4.11.2.5 SET协议的交易流程

SET安全电子交易的整个过程大体可分为以下几个阶段：持卡人（C）注册、商家（M）注册、购买请求、付款授权和付款结算。

（1）持卡人注册（Cardholder Registration）

持卡人C在实施电子交易之前必须先向其金融机构（发卡行）注册登记，以便得到一个签名证书。在这个过程中，C为了保证信息的机密性，需要使用CCA的交换密钥的公钥。它是从CCA的交换密钥证书（在初始响应中由CCA发送）中得到的。图6描述了持卡人通过SET协议申请证书的信息流程：

图6 持卡人申请证书的流程

注册的具体步骤如下：

1）C向CCA发送初始请求CardCInitReq；

2）CCA接到初始请求，生成初始响应CardCInitReS，并对初始响应进行数字签名；CCA 把CardCInitReS连同证书一起发给C；

3）接到初始响应，并验证CCA的证书；接着验证CCA对响应的数字签名；

4）C输入账号，生成注册表请求RegFormReq；C随机生成对称密钥K l，用K1对注册表请求消息加密，K l与账号一起用CCA的交换密钥的公钥加密；C发送加密后的RegFormReq给CCA；

5）CCA用交换密钥的私钥解密K l和账号，用K l解密加密的RegFormReq；

6）CCA选择合适的注册表，生成注册表响应RegFormRes，并对其进行数字签名；CCA 发送加密的RegFormReS及CCA的证书给C；

7）C接收RegFormReS并验证CCA的证书；接着验证CCA对注册表的数字签名；C 产生一对公开/秘密密钥SignatureKeyPair和一个秘密的用于注册账号的随机数R1；C填写注册表并生成证书请求CertReq；

8）C生成由CertReq、C的公开密钥和新生成的对称密钥K2组成的消息，并签名；C 将此消息用密钥K3加密，K3、R1与账号一起用CCA的交换密钥的公钥加密；C发送这个消息（包括加密的账号和R1等）给CCA；

9）CCA用交换密钥的私钥解密K3、随机数R1和账号，用K3解密加密后的证书请求；CCA验证C的数字签名，用账户信息和注册表信息对C进行必要的验证（SET中没有具体规定）；根据验证结果，CCA生成随机数R2，将R2、R1、C的账号、有效期等信息的散列值包含在证书中，并签名，生成证书；

10）CCA生成证书应答CertRes（包含有加密的R2）并签名；CCA将CertRes用K2加密后发送给C；

11）C验证CCA的证书并用K2解密消息CertRes；C验证CCA对证书的数字签名后保留证书以及CCA产生的秘密随机数R2。

在持卡人注册过程中，C的证书不直接包含C的账号，而是包含相关信息的散列值。因此仅有证书提供的信息是不可能推知出账号信息的，这样就保护了持卡人的敏感信息；此外，C没有交换密钥证书，会话密钥总是由C产生并通过CCA的交换密钥的公钥加密传递。

（2）商家注册（Merehant Registration）

商家M在进行电子交易之前，必须先向其金融机构（收单行）注册登记，以便得到签名证书和交换密钥证书。而支付网关的证书获取过程同商家的一样。图7描述了商家（或支付网关）通过SET协议申请证书的流程。

CertRes

图7商家（或支付网关）申请证书的流程

注册的具体步骤如下：

1）M发送初始请求Me一AqCInitReq给MCA；

2）MCA接收到消息Me一AqCinitReq，选择合适的注册表，生成初始响应Me一AqCInitRes，并对其进行数字签名；MCA发送Me一AqCInitRes及MCA的证书给M；

3）M验证MCA对消息的数字签名，并产生两对公开/秘密密钥：Key一eXChangePair 和signatureKeyPair；M填写注册表并生成证书请求CertReq；M生成请求和两个公开密钥构成的消息并签名；M将消息用随机生成的密钥K l加密，Kl及M的账户信息用MCA的交换密钥的公钥加密；M把消息发送给MCA；

4）MCA收到消息，用交换密钥的私钥解密K l和M的账户信息，并用K l解密消息；M 以验证M的数字签名，使用M的有关信息证实CertReq；根据验证MCA生成M的证书并对其签名；M以生成证书响应CertRes并签名；MCA发送证书和CertRes给M；

5）M验证CertReS的签名，接着验证M以颁发的证书的数字签名，并保留证书。

（3）购买请求（purehase Request）

购物请求具体步骤如下：

l）C通过一定的方式挑选商品。选完后，C发送初始请求给M；

2）M接收初始请求，并生成初始响应，对其进行数字签名；M把初始响应、M和PG 的证书发送给C；

3）C接收到初始响应，并验证所有的证书；C验证M对初始响应的数字签名；C生成订单信息OI和付款指令信息PI，并对OI和PI进行双数字签名；C用随机生成的对称密钥Kl对PI加密，Kl和C的账户信息用PG的交换密钥的公钥加密；C发送OI及加密的PI给M；

4）M验证C的证书及C的双数字签名；M处理购买请求，并生成购买响应（包括M 的证书）并对其签名，发送给C；

5）若交易己经授权，则M履行合同；

6）C接收购买响应后，验证M的证书，进一步验证M对购买响应的数字签名；C保留购买响应。

在购买请求中，双数字签名的作用是使商家可以验证OI和PI是由持卡人进行签名的，但商家却不能够看到PI的具体内容；而对于支付网关而言，它也能够验证OI和PI是由持卡人进行签名的，但它不能够看见OI的具体内容。使用双数字签名的好处是不仅能够对消息源、消息完整性进行认证，而且使信息得到了最大程度的保护。

（4）付款授权（payment Authorization）

在购买请求的过程中M还要在发送购买响应之前完成付款授权，其具体步骤如下：l）M生成授权请求，并对其进行签名；M将授权请求用随机生成的对称密钥K2加密，K2则用PG的交换密钥的公钥加密；M将加密后的信息和M的证书一起发送给PG；

2）既验证M的证书，用自己的交换密钥私钥解密K2，用K2解密授权请求；PG验证M对授权请求的签名；接着，验证C的证书，用自己的交换密钥私钥解密K1，用K1解密付款指令PI；PG验证C的双数字签名，验证M的授权请求与C的付款指令的一致性；PG 将授权请求通过金融网络发送给C的金融机构；

3）PG生成授权响应并对其进行数字签名，用K3对授权响应加密，而K3用M的交换密钥公钥加密；PG生成结算标记并签名，并用K4加密，K4及C的账户信息用PG的交换密钥公钥加密；PG将加密的响应及自己的证书发送给M；

4）M验证PG的证书，用自己的交换密钥私钥解密K3，用K3解密响应消息；M验证PG对授权响应的数字签名，M保留结算标记供以后使用，并完成购买请求。

（5）付款结算（Payment Capture）

M在履行合同之后要求结算付款。在付款授权和付款结算之间经常有较长的时间间隔。具体的付款结算步骤如下：

l）M生成结算请求，并把自己的证书加入结算请求中，进行数字签名；

M将结算请求用K5加密，K5用PG的交换密钥公钥加密，发送加密的结算请求及在授权过程中保留的加密了的结算标记给PG；

2）PG首先验证M的证书，用自己的交换密钥私钥解密K5，用K5解密结算请求；PG 验证M对结算请求的数字签名，用自己的交换密钥私钥解密K4，用K4解密结算标记，确认结算请求与结算标记的一致性；

3）PG生成结算响应消息（包括PG的证书），并签名；PG将结算响应用K6加密，K6用M的交换密钥公钥加密，最后，发送给M；

4）M验证PG的证书，用自己的交换密钥私钥解密K6，用K6解密结算响应；M验证PG 对结算响应的签名，保留结算响应以便用来从收单行提款。