SET协议

1. 前言

参考《电子商务的安全体系结构及安全技术研究》、《电子商务基础》、《应用系统安全基础》

2. 概述

2.1 SET

SET协议(Secure Electronic Transaction)，被称之为安全电子交易协议，是由Master Card和Visa联合 Netscape,Microsoft等公司，于1997年6月1日推出的一种新的电子支付模型。SET协议采用公钥密码体制和X.509数字证书标准，主要应用于保障网上购物信息的安全性。

由于SET提供了消费者、商家和银行之间的认证，确保了交易数据的安全性、完整可靠性和交易的不可否认性，特别是保证不将消费者银行卡号暴露给商家等优点，因此成为目前公认的信用卡/借记卡的网上交易的国际安全标准

SET技术规范：

1. 商业描述(The Business Description)：提供处理的总述。
2. 程序员指导(The Programmer’s Guide)：介绍数据区、消息以及处理流程，分为系统设计考虑、证书管理、支付系统。
3. 正式的协议定义(The Formal Protocol Definition)：提供SET消息和数据区最严格的定义，协议定义采用ASN1语法进行。

SET协议的主要目标：

1. 信息在Internet上安全传输，保证网上传输的数据不被黑客窃取；
2. 定单信息和个人账号信息的隔离，在将包括持卡人账号信息的定单送到商家时，商家只能看到定货信息，而看不到持卡人的账户信息；
3. 持卡人和商家相互认证，以确定通信双方的身份。一般由第三方机构负责为在线通信方双方提供信用担保。
4. 要求软件遵循相同协议和消息格式，使不同厂家开发的软件具有兼容和互操作功能，并且可以运行在不同的硬件和操作系统平台上。

SET协议位于应用层，可为电子商务提供以下功能：

1. 通过使用信息加密，实现付款数据私有化和订货信息于付款信息传送的保密化
2. 验证持卡人的信用卡帐目，采用数字签名保证完整性，使用数字证书证实交易者的身份，验证工作与收款机构共同进行
3. 保留付款信息集成，由数字签名完成
4. 特别用途证书

SET支付系统主要由持卡人、商家、发卡机构、银行、支付网关和认证中心6个部分组成。对应地，基于SET协议的网上购物系统至少包括电子钱包软件、商家软件、支付网关软件和签发证书软件。

1. 持卡人：在电子商务环境中，消费者和团体购买者通过计算机与商家交流，持卡人通过由发卡机构颁发的付款卡（例如信用卡、借记卡）进行结算。在持卡人和商家的会话中，ET可以保证持卡人的个人账号信息不被泄漏。
2. 发卡机构：它是一个金融机构，为每一个建立了账户的顾客颁发付款卡，发卡机构根据不同品牌卡的规定和政策，保证对每一笔认证交易的付款。
3. 商家：提供商品或服务，使用SET就可以保证持卡人个人信息的安全。接受卡支付的商家必须和银行有关系。
4. 银行：在线交易的商家在银行开立账号，并且处理支付卡的认证和支付。
5. 支付网关：是由银行操作的将nternet上的传输数据转换为金融机构内部数据的设备，或由指派的第三方处理商家支付信息和顾客的支付指令。
6. 数字证书认证中心CA：主要作用是负责SET交易数字证书的发放、更新、废除、建立证书黑名单等各种证书管理

2.2. SET 与SSL

3. 安全性

为了满足在Internet和其他网络上信用卡安全支付的要求，SET协议主要是通过使用密码技术和数字证书方式来保证信息的机密性和安全性，它实现了电子交易的机密性、数据完整性、身份的合法性、不可否认性和互操作性。

1. 机密性：SET支付环境中信息的机密性是通过使用混合加密算法（即公钥加密算法和对称加密算法相结合)来加密支付信息而获得的。
   一般做法是，用公钥加密算法来加密包含一个短密钥的真实信息，该短密钥是通过公钥一私钥密钥对秘密发布的。SET中采用的公钥加密算法采用RSA的公钥密码体制，私钥加密算法采用DES数据加密标准，消息首先以56位DES密钥加密，然后装入使用1024位RSA公钥加密的数字信封在通信双方传输。56位DES密钥是使用消息接收者的公钥加密后附在加密的消息中的。消息接收者很容易用自己的私钥解密来提取出加密的DES密钥，然后使用DES密钥完成消息块的解密过程。这种混合加密技术在SET中被形象地称为数字信封(Digital
   Envelope),RSA加密相当于用信封密封。
2. 数据完整性：SET协议使用数字签名来保证数据的完整性。 SET使用安全Hash算法(Secure Hash
   Algorithrn,SHA-1)的RSA数字签名，SHA-1对于任意长度的消息都生成一个160位的消息摘要。如果消息中有一位发生变化，那么消息摘要中会大约有10位数据发生变化，两个不同消息的摘要完全相同的概率是10%一48%。Hash函数的单向性也使得从消息滴要得出消息原文在计算上是不可行的，消息摘要的这些特征事实上可以消除修改消息一消息摘要对而不被发现的可能性。
   SET协议中还使用双重签名来保证信息的完整性。双重签名的目的是连接两个不同接收方的两条信息，如发送给商家的订购信息$OI$和发送给银行的支付信息$PI$。其中，商家不可以知道客户的信息卡信息，银行不需要知道客户的订购信息细节。用户用一个签名操作来数字签名两个信息，实现一个双重签名。一个双重签名是通过计算两个消息摘要产生的，并将两个摘要连接在一起形成一个总摘要，用户的私有签名密钥加密摘要。
3. 身份验证：SET使用基于X.509的PKI,通过数字证书和RSA来达到对持卡人账户、商家、支付网关以及银行的认证。
   SET是一个基于可信的第三方认证中心的方案，CA在SET中扮演了很重要的角色，证书是核心。SET标准提供了通过认证中心对证书加以认证的简单方法来确保进行电子交易的各方能够互相信任。在SET协议中，有持卡人证书、特约商店证书、支付网关证书、收单银行证书和发单银行证书。在SET中，每个用户(A)至少要有两对密钥：一对签名密钥$SpV(A)$、$Spb(A)$和一对加密密钥$Epv(A)$、$Epb(A)$，每对密钥都有相应的数字证书$CetS(A)$和$CertE(A)$。签名密钥由用户自己保管，加密密钥对要由CA进行托管。
4. 不可否认性：SET协议中数字证书的发布过程也包含了商家和客户在交易中存在的信息。因此，如果客户用SET发出了一个商品的订单，在收到货物后，他不能否认发出这个订单，同样，商家以后也不能否认收到过这个订单。
5. 互操作性： 通过使用特定的协议和消息格式，SET系统可提供在不同的软硬件平台操作的同等能力。

4. 交易流程

4.1 大致流程

SET交易过程中要对商家，客户，支付网关等交易各方进行身份认证，因此它的交易过程相对复杂。

1. 持卡人使用浏览器在商家的wb主页上查看在线商品目录浏览商品。
2. 持卡人选择要购买的商品。
3. 持卡人填写定单，包括：项目列表、价格、总价、运费、搬运费、税费。定单可通过电子化方式从商家传过来，或由持卡人的电子购物软件建立。有些在线商场可以让持卡人与商家协商物品的价格（例如出示自己是老客户的证明，或给出了竞争对手的价格信息)
4. 持卡人选择付款方式，此时SET开始介入。
5. 持卡人发送给商家一个完整的定单及要求付款的指令。在SET中，定单和付款指令由持卡人进行数字签名。同时利用双重签名技术保证商家看不到持卡人的账号信息。
6. 商家接受定单后，向持卡人的金融机构请求支付认可。通过Gateway到银行，再到发卡机构确认，批准交易。然后返回确认信息给商家。
7. 商家发送定单确认信息给顾客。顾客端软件可记录交易日志，以备将来查询。
8. 商家给顾客装运货物，或完成订购的服务。到此为止，一个购买过程己经结束。商家可以立即请求银行将钱从购物者的账号转移到商家账号，也可以等到某一时间，请求成批划账处理。
9. 商家从持卡人的金融机构请求支付。在认证操作和支付操作中间一般会有一个时间间隔，例如，在每天的下班前请求银行结一天的账。

SET协议在处理过程中，通信协议、请求信息的格式、数据类型的定义等，SET都有明确的规定。在操作的每一步，持卡人、商家、网关都通过CA来验证通信主体的身份，以确保通信的对方不是冒名顶替。

SET交易过程十分复杂性，在完成一次SET协议交易过程中，需验证电子证书9次，验正数字签名6次，传递证书7次，进行签名5次，4次对称加密和非对称加密。通常完成一个SET协议交易过程大约要花费1.5-2分钟甚至更长时间。由于各地网络设施良莠不齐，因此，完成一个SET协议的交易过程可能需要耗费更长的时间。

4.2 一些细节

4.2.1 持卡人注册

1. 持卡人在向商家购物之前必须在CA注册，为了向CA发送SET消息，持卡人必须拥有CA的公钥，这由CA的密钥交换证书提供（持卡人软件请求CA的密钥交换公钥证书）。

2. CA接受初始化请求

   • 产生响应消息及响应消息的消息摘要并用其签名私钥加密来生成数字签名；
   • 将响应消息连同密钥交换证书和签名证书发送给持卡人。

3. 持卡人的软件收到初始化响应消息；

   • 校验两个证书（遍历信任链）
   • 验证CA签名（用CA的签名公钥解密其数字签名并将结果与新产生的响应消息的Hash值比较)
   • 持卡人输入账号
   • 持卡人的软件产生注册表请求信总
   • 产生Deskeyl(随机对称密钥)来加密请求信息
   • 用CA的密钥交换公钥加密Deskeyl和持卡人的账号得到数字信封
   • 把（加密的注册表请求消息+数字信封）发给CA。

4. CA收到后

   • 用其私有交换密钥解密持卡人账号及Deskeyl,然后用Deskeyl解密注册表请求
   • 确定适当的注册表，产生注册表的消息摘要，并用其私有签名密钥生成其数字签名
   • 将数字签名后的注册表和CA的签名公钥证书发送给持卡人。

5. 持卡人的软件收到注册表后

   • 验证CA签名公钥证书
   • 验证CA的签名，即用CA的签名公制来解密CA的签名并将结果与新生成的注册表的Hash值比较
   • 产生一对公开/私有签名密钥
   • 持卡人填写注册表
   • 持卡人的软件产生证书请求，包括填入注册表的信息
   • 持卡人的软件将证书请求、持卡人的签名公钥及新产生Deskey2一起组成“信息”，然后生成证书请求的消息摘要并用持卡人的签名私钥加密来创建数字签名
   • 持卡人的软件产生Deskey3加密“信息”；这个密钥连同持卡人账户信息一起用 CA的密钥交换公钥加密生成数字信封
   • 持卡人软件把（加密的证书请求信息+数字信封）传送给CA。

6. CA收到后

   • 用其私有交换密钏解密Deakey3,用Deskey3解密证书请求
   • 验证持卡人签名，即用持卡人签名公钥解密持卡人签名并将结果与新产生的证书请求的Hash值进行比较
   • 用持卡人账户信息和注册表格上的信息校验其与证书请求信息是否一致
   • 一旦通过校验，CA创建持卡人证书并用其私有签名密钥签署证书
   • CA用来自持卡人请求信息中的Deskey2加密证书，并产生证书响应消息，然后生成响应消息摘要，并用其私有签名密钥加密来创建数字签名
   • CA把证书响应消息连同CA的签名公钥证书传送给持卡人。

7. 持卡人软件收到后

   • 使用保存的Deskey2解密证书响应消息
   • 通过信任链校验证书
   • 验证CA签名，即用CA的签名公钥来解密CA签名并把结果和最新产生的证书响应的Hash值相比较
   • 将其证书及来自证书响应的信息储存起来以备将来的应用。

4.2.2 商家注册

1. 商家软件请求CA的密钥交换证书和注册表。

2. CA收到请求后：

   • 识别商家金融机构，选择合适的注册表并数字签名
   • 将数字签名后注册表连同密钥交换证书和签名证书发给商家。

3. 商家软件收到后

   • 验证CA的两个证书
   • 验证CA的数字签名
   • 产生各一对密钥交换密钥对和签名密钥对
   • 商家在注册表中填写商家名称、地址及商家D(收单行中的唯一标识)
   • 商家软件产生证书请求
   • 商家软件将证书请求和两个公钥组成“消息”，并数字签名“消息”
   • 产生Deskey4(随机对称密钥)，用Deskey4加密签名后消息，用CA的密钥交换公钥加密Deskey4和商家的D形成数字信封，再将所有信息向CA发出。

4. CA收到后

   • 用密钥交换私钥解开数字信封的Deskey4和商家的D,用Deskey.5解密(10)中的加密消息得到注册表清求；
   • 根据商家的数字签名验证注册表请求，如果签名有效，消息处理继续，否则，返回商家提示消息响应
   • 使用商家账户信息验证注册表请求
   • 注意：SET协议中没有定义CA和收单行如何交换信息验证注册表内的信息
   • 如果注册表信息有效，CA产生一个证书响应，并数字签名
   • 将（证书响应十商家的两个公钥十CA的签名公钥)发给商家。

5. 商家收到后

   • 验证证书
   • 验证CA的数字签名
   • 保存证书至安全地方

4.2.3 购买请求

1. 持卡人到商家的网站浏览、挑选、订购后请求支付网关的密钥父换证书；

2. 商家收到请求后，为该消息制定Numl(唯一识别号)并用商家签名私钥数字签名，然后将（签名后Numl1+商家签名证书+支付网关的密钥交换证书）发给持卡人。

3. 持卡人收到后

   • 验证商家和支付网关证书，并保存证书
   • 产生订购信息OI和支付指令PI,将Numl插入OI和PI中
   • 生成OI和PI的双重签名，即对(OI的消息滴要+PI的消息滴要)计算Hash值，再对Hash值用持卡人的签名私钥加密
   • 产生Deskey(6(随机对称密钥)
   • 用Deskey6加密PI的双重签名等得到加密的支付信息；用Deskey6加密持卡人账号；用支付网关的密钥交换公钥加密Deskey6形成支付信封
   • 将OI的双重签名、支付信封、加密的支付信息、PI的消息滴要、持卡人密制父换证书一起发送给商家。

4. 商家收到后

   • 验证持卡人证书
   • 验证双重签名，即用持卡人的密钥交换公钥解密OI的双重签名，计算OI的消息滴要，再对OI的消息摘要和PI的消息摘要计算Hash值，再与解密后的比较
   • 商家将PI送支付网关
   • 生成购物响应消息并数字签名
   • 将购物响应和商家密钥交换证书发送给持卡人。

5. 持卡人收到购物响应后

   • 验证商家证书
   • 验证购物响应中的商家签名
   • 持卡人保存购物响应。

4.2.4 支付授权

1. 商家软件产生并数字签署一个授权，其中包含授权的金额、Numl；

2. 产生Deskey7加密授权请求并用支付网关的密钥交换公钥生成网关信封

3. 商家将（加密后的授权请求+(PI+双重签名）)和（网关信时+特卡人签名证书+（商家的密钥交换证书和签名证书）)传给支付网关。（注意：SET协议中还包括一个销售交易，允许商家在一个消息中同时进行交易授权和支付清求)。

4. 支付网关收到授权请求后

   • 解密网关信封的Deskey7;用Deskey7解密请求信总
   • 验证商家证书
   • 验证商家签名
   • 支付网关解密PI的数字信封得到Deskey6和账户信息；用Deskey6解密得到PI:·验证持卡人证书
   • 验证PI双重签名，即用持卡人签名公钥解密双重签名，计算PI的消息摘要，与包含在PI中OI摘要一起计算Hash值，与解密后的双重签名对比
   • 验证Nml和PI中的识别号
   • 将授权请求通过银行网络发向发卡行
   • 生成并数字签名授权响应消息
   • 产生Deskey8加密授权响应；用商家的密钥交换公钥加密Deskey8得到商家信封
   • 产生Deskeys9加密请款标记，用支付网关的密钥交换公钥加密Deskeys9生成网关信封
   • 将(（加密后授权响应和商家信封）+（加密后请款标记和网关信封）+支付网关签名证书)一起发送商家。

5. 商家收到后

   • 验证支付网关证书
   • 用商家的密钥交换私钥解开数字信封得到Deskey8,用Deskey8解密授权响应
   • 验证支付网关对授权响应的数字签名
   • 保存授权响应、加密后的扣款令牌和请款标志，用于以后扣款处理。至此，商家完成持卡人的购物处理。

4.2.5 支付请款

1. 商家产生并数字签名一个请款请求(Capture Request)

2. 产生Deskeyl(0加密扣款诸求，用支付网关密钥交换公钥加密Deskeyl(0生成支付信封

3. 将(（加密后扣款请求和支付信封）+（加密后扣款令牌和网关信封）)发向支付网关。

4. 支付网关收到扣款请求后

   • 用支付网关密钥交换私钥解密支付信封得到Deskeyl0;用Deskeyl0解密扣款请求
   • 验证扣款请求的商家签名
   • 用支付网关密钥交换私钥解密Deskeys9，再用Deskeys9解密请款标记
   • 比较扣款请求和请款标记
   • 将扣款请求通过银行网络发送到发卡行
   • 生成并数字签名扣款响应消息
   • 产生Deskeyll加密扣款响应；用商家的密制父换公钥加密Deskeyll生成商家信封
   • 将(（加密扣款响应和商家信封）十网关的签名证书)一起传给商家。

5. 商家收到支付网关传来的扣款响应后

   • 用商家私钥解密Deskeyll,用Deksyll解密扣款响应
   • 验证网关证书
   • 验证支付网关的签名；商家保存扣款响应，用于与收单行得到的付款进行对账。