9.3.1SET协议分析
1.SET协议安全性分析
为了满足在Internet和其他网络上信用卡安全支付的要求，SET协议主要是通过使用密码技术和数字证书方式来保证信息的机密性和安全性，它实现了电子交易的机密性、数据完整性、身份的合法性和不可否认性。
（1）机密性。SET支付环境中信息的机密性是通过使用混合加密算法（即公钥加密算法和对称加密算法相结合）来加密支付信息而获得的。一般的做法是，用公钥加密算法来加密包含一个短密钥的真实信息，该短密钥是通过公钥—私钥密钥对秘密发布的。SET中采用的公钥加密算法是RSA的公钥密码体制，私钥加密算法采用的是DES数据加密标准，消息首先以56位DES密钥加密，然后装入使用1024位RSA公钥加密的数字信封在通信双方传输。56位DES密钥是使用消息接收者的公钥加密后附在加密消息中的。消息接收者很容易用自己的私钥解密来提取出加密的DES密钥，然后使用DES密钥完成消息块的解密过程。这种混合加密技术在SET中被形象地称为数字信封（Digital Envelope），RSA加密相当于用信封密封。
（2）数据完整性。SET协议使用数字签名来保证数据的完整性。SET使用安全Hash算法的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），每对密钥都有相应的数字证书CertS（A）和CertE（A）。签名密钥由用户自己保管，加密密钥对要由CA进行托管。
（4）不可否认性。SET协议中数字证书的发布过程也包含了商家和客户在交易中存在的信息。因此，如果客户用SET发出了一个商品的订单，在收到货物后它不能否认发出过这个订单，同样，商家以后也不能否认收到过这个订单。
2.SET协议性能分析
从前面对SET协议的介绍和研究可以看出，SET使用了各种密码技术，构建了完善的认证体系，定义了完备的电子交易流程。它较好地解决了电子交易各方之间的、复杂的信任关系和安全连接，确保了电子交易所要求的保密性、数据完整性、身份认证性和不可否认性等安全需求。
SET是专为网上卡支付而建立的协议，为电子支付提供了足够的安全性，它具有许多优点：
（1）SET对商家提供了保护自己的手段，使商家免受欺诈的困扰，并使商家的运营成本降低。
（2）对消费者而言，SET保证了商家的合法性，并且用户的信用卡号不会被窃取，SET替消费者保守了更多的秘密使其在线购物更加轻松放心。
（3）SET帮助银行和发卡机构将业务扩展到Internet这个广阔的空间中，使得信用卡网上支付具有更低的欺诈概率，因此比其他支付方式具有更大的竞争力。
（4）SET对于参与交易的各方定义了互操作接口，一个系统可以由不同厂商的产品构筑。
与此同时，SET协议庞大而又复杂，在一个典型的SET交易过程中，需验证数字证书9次，验证数字签名6次，传送证书7次，进行5次签名，4次对称加密和4次非对称加密。SET涉及的实体较多，客户、商家和银行都需要改造系统才能实现互操作，使用相当麻烦。由于SET要求在银行网络、商家服务器、顾客PC上安装相应软件，并向各方发放证书，其使用费用非常昂贵。另外SET交易模式只能用于B2C（Business to Consumer，企业与消费者之间的电子商务）模式，不能用于B2B（Business to Business，企业间的电子商务）模式，而且它在B2C模式中也十分受限，只能应用于一些受约束的卡支付业务。
因此，虽然SET在电子支付中得到了广泛的应用，受到电子商务推动者的高度重视，但它也有下面一些局限：
（1）SET报文消息太复杂。SET定义了支付过程的报文消息及数据，由于其规范的目标是全球使用，考虑的因素主要是美国的支付方式，而对其他国家来讲报文消息显得过于复杂，造成SET应用软件设计复杂，价格高，影响了SET的普及。
（2）SET涉及的实体较多。要实现SET支付，客户、商家、支付网关必须同时支持SET，因而各方建设和协调的困难造成互操作性差。
（3）SET没有解决交易中证据的生成和保留。SET协议仅解决了支付信息的认证。交易后，顾客（商家）处理争议时，缺乏有效说明来划分责任，无法满足电子商务协议的公平性原则。
（4）SET协议中没有对交易过程作状态描述，这可能使顾客或商家对交易的状态难以把握。
9.3.2SET协议的证书管理
1.证书管理结构
SET的证书管理结构包括9个部分，是根据进行CA验证和SET证书管理的需要来定义的层次结构。
（1）RCA（Root Certificate Authority，根CA）。
采用非常严格的物理方式来控制，保持其非在线状态，RCA极少被访问来发行新的品牌CA和一个新的根证书RCA。
（2）BCA（Brand CA，品牌CA）。
可以允许一定程度的自治，BCA操作采用严格的物理方式控制，BCA向其层次下的实体发放证书。
（3）GCA（Geo-Political CA，地域政策CA）。GCA允许该品牌在一个地理区域或一个政策范围内，执行证书管理的职责，GCA负责为可能泄密的证书产生、保持、分发证书撤销列表CRL。
（4）CCA（Card holder CA，持卡人CA）。CCA用于为持卡人分发持卡人证书，可通过Web或E-mail方式接受证书请求，CCA与发卡行保持联系，以便验证持卡人账户。
（5）MCA（Merchant CA，商家CA）。MCA负责给商家分发证书，此前，收单行验证和批准其特约商家的证书请求。
（6）PCA（Payment Gateway CA，支付网关CA）。PCA由一个支付卡品牌、收单行或另一个团体来操作。
（7）Card holder（持卡人）：从CCA申请和接收证书。
（8）Merchant（商家）：从MCA申请和接收证书。
（9）Payment Gateway（支付网关）：从PCA申请和接收证书。
2.证书管理功能
CA为其证书管理层次下的实体提供三个基本服务，即证书发行、更新和撤销。
（1）证书发行（Certificate Issuance）。SET定义有三种方式：Web方式（交互式）、E-mail方式和离线（非交互式）方式。
因为交互式具有灵活方便等优点，故首选Web方式，如持卡人通过Web申请CCA，需经历三个阶段：
①持卡人申请证书的请求/应答过程。通过消息变量Card lnit Reg和Card list Res来唤醒SET应用，并分发根的签名证书，此过程中包含采用Web所需的MIME信息。
②持卡人申请登记表的请求/应答过程，通过消息变量Reg Form Reg和Reg Form Res来传递登记表。
③证书请求和生成过程。通过Cert Reg和Cert Res来颁发证书。
通过三对消息的交换。申请者可将私人信息和账号传递给CA，而CA通过确认身份，（与发卡行协作）后颁发证书。
（2）证书更新（Certificate Renewal）。
出于安全考虑，密钥都有一定的使用期，因此所有的证书都需要定期更新，在每份证书中都说明了失效期，具体的更新周期，由CA制定的策略来决定。根证书被更新后，只是失去了发证功能，但仍存在于信任链中，直到它颁发的所有证书都失效后，RCA才失效。证书更新过程与证书颁发过程相同。
（3）证书撤销（Certificate Revocation）。
是整个证书管理机制中最有效的安全保障手段，它能够及时避免证书面临危险时对SET交易的影响，有多种原因需要对证书进行撤销，如怀疑私钥泄露、证书标识信息被改变以及中止使用等，它在一定程度上体现和延续了现今的信用卡管理体系，使证书达到或超过信用卡的安全程度，充分保障了网上的正常交易。
CRL：CRL（Certificate Revocation List，证书废除列表）是由X。509协议定义的一种用于公布和分发含有被废除证书的列表的机制。每个CA（除MCA和CCA外）都维护着一个自己的CRL，用于公布被废除的由它所生成和签订的证书名单。BCL（Brand CRL Identifier）是指针对某个信用卡品牌的所有目前使用的CRL，是由SET协议定义的，并由BCA（Brand Certificate Authority）来维护。每当一份证书被废除，CA就会发布新的CRL，而相应的BCL也会被更新。SET协议运用CRL和BCL，可以有效地避免交易过程中欺诈行为所带来的危害，它赋予了证书管理更为有力和更具效率的可操作性。在证书废除的复杂机制中，支付网关担当着至关重要的角色。这是因为SET交易中支付网关是传递支付信息的枢纽，它将由持卡人传来的支付自动递交给支付银行的主机，并把交易结果反馈回商家。SET协议针对参与交易的不同对象，制定了具体的证书废除过程。
①持卡人证书的废除。SET1.0版本没有持卡人证书的废除功能。证书的废除功能是通过信用卡黑名单来实现。
②商家证书的废除。SET1.0版本也没有商家证书的废除功能。当一个商家终止与指定的支付网关的联系时，该支付网关就有能力拒绝所有来自此商家的支付请求。
③支付网关证书的废除。
一旦支付网关的证书遭到恶意攻击，可能处于危险时，就必须及时废除，并重新申请证书。
④CA证书的废除。
对于CA来说，受到有效攻击的可能性极低，但无论如何，一旦有成功的攻击出现，CA的旧证书就必须被废除。
由于SET交易的关键是密钥的加、解密过程，而证书又是密钥的载体，因此，从某种意义上说，证书管理也就近乎于密钥管理。通过证书管理的缜密策略和行之有效的手段，SET协议将在开放的网络上进行信用交易的幻想变了现实。证书管理涵盖了SET交易的全过程，成了SET协议的灵魂。
3.证书链确认
（1）验证证书链。
上面描述了SET证书的层次关系，其中每一层都由其上层产生，证书就是通过这样的信任层次来验证的，每个证书对应于发行该证书的实体的签名证书，通过直到RCA的信任层次来验证证书，证书有效性的验证路径称为“签名链”。
证书链的确认要求保证：路径中每个证书到根证书是有效的，并且每个证书要正确对应发行该证书的CA，SET证书链验证方法是按照“Section12.4.3of Amendment1to X。509”的处理要求进行的，SET对证书链的验证是对X。509标准的扩充。
因此，由证书管理的层次关系而映射形成的证书信任链决定了验证证书合法性的途径，每份证书都与其颁发者的签名证书相联系，在交易双方的通信过程中，认证系统会将对方的证书沿着信任链逐级追溯到RCA，而所有SET软件都知道RCA的公开签名密钥，从而确认该证书的合法性。
（2）证书中的日期。
证书到期日期的验证是签名链验证过程的一个组成部分，对于一个最终实体证书的验证，要求所有信任链都是有效的，并且链中所有证书没有一个是超期的。为了对证书链中所有证书进行日期验证，有以下处理要求：
①所有SET软件验证证书日期，都作为签名链验证处理的一部分。
②SET软件提供一个机制来防止使用超期证书。
③证书的使用期限应当限制在该证书的有效时间范围之内，并且在发行CA签名证书私用密钥使用的有效时间之内。
（3）指纹。
指纹是对证书、CRL、BCL计算的Hash值，一个最终实体在发出的消息中包含指纹，作为一种识别自己所保存的证书、CRL等内容的简洁方法。
消息接收者发现消息中包含指纹，可以检查指纹，并在下行消息中（一般是响应消息中）插入发送者没有但是交易中需要的任何证书、CRL或BCL。
9.3.3SET处理流程
SET协议的工作流程，可从一个完整的购物处理流程来看：
1.持卡人注册（Cardholder Registration）
持卡人在向商家购物之前必须在CA注册，为了向CA发送SET消息，持卡人必须拥有CA的公钥，这由CA的密钥交换证书提供。
（1）持卡人软件请求CA的密钥交换公钥证书。
CA接受初始化请求：
（2）产生响应消息及响应消息的消息摘要并用其签名私钥加密来生成数字签名。
（3）将响应消息连同密钥交换证书和签名证书发送给持卡人。
持卡人的软件收到初始化响应消息：
（4）校验两个证书（遍历信任链）。
（5）验证CA签名（用CA的签名公钥解密其数字签名并将结果与新产生的响应消息的Hash值比较）。
（6）持卡人输入账号。
（7）持卡人的软件产生注册表请求信息。
（8）产生Deskeyl（随机对称密钥）来加密请求信息。
（9）用CA的密钥交换公钥加密Deskeyl和持卡人的账号得到数字信封。
（10）把（加密的注册表请求消息 数字信封）发给CA。
CA收到后：
（11）用其私有交换密钥解密持卡人账号及Deskeyl，然后用Deskeyl解密注册表请求。
（12）确定适当的注册表，产生注册表的消息摘要，并用其私有签名密钥生成其数字签名。
（13）将数字签名后的注册表和CA的签名公钥证书发送给持卡人。
持卡人的软件收到注册表后：
（14）验证CA签名公钥证书。
（15）验证CA的签名，即用CA的签名公钥来解密CA的签名并将结果与新生成的注册表的Hash值比较。
（16）产生一对公开/私有签名密钥。
（17）持卡人填写注册表。
（18）持卡人的软件产生证书请求，包括填入注册表的信息。
（19）持卡人的软件将证书请求、持卡人的签名公钥及新产生Deskey2一起组成“信息”，然后生成证书请求的消息摘要并用持卡人的签名私钥加密来创建数字签名。
（20）持卡人的软件产生Deskey3加密“信息”；这个密钥连同持卡人账户信息一起用CA的密钥交换公钥加密生成数字信封。
（21）持卡人软件把（加密的证书请求信息 数字信封）传送给CA。
CA收到后：
（22）用其私有交换密钥解密Deakey3，用Deskey3解密证书请求。
（23）验证持卡人签名，即用持卡人签名公钥解密持卡人签名并将结果与新产生的证书请求的Hash值进行比较。
（24）用持卡人账户信息和注册表格上的信息校验其与证书请求信息是否一致。
（25）一旦通过校验，CA创建持卡人证书并用其私有签名密钥签署证书。
（26）CA用来自持卡人请求信息中的Deskey2加密证书，并产生证书响应消息然后生成响应消息摘要，并用其私有签名密钥加密来创建数字签名。
（27）CA把证书响应消息连同CA的签名公钥证书传送给持卡人。
持卡人软件收到后：
（28）使用步骤（19）保存的Deskey2解密证书响应消息。
（29）通过信任链校验证书。
（30）验证CA签名，即用CA的签名公钥来解密CA签名并把结果和最新产生的证书响应的Hash值相比较。
（31）将其证书及来自证书响应的信息储存起来以备将来的应用。
2.商家注册（Merchant Registration）
（1）商家软件请求CA的密钥交换证书和注册表。
CA收到请求后：
（2）识别商家金融机构，选择合适的注册表并数字签名。
（3）将数字签名后注册表连同密钥交换证书和签名证书发给商家。
商家软件收到后：
（4）验证CA的两个证书。
（5）验证CA的数字签名。
（6）产生各一对密钥交换密钥对和签名密钥对。
（7）商家在注册表中填写商家名称、地址及商家ID（收单行中的唯一标识）。
（8）商家软件产生证书请求。
（9）商家软件将证书请求和两个公钥组成“消息”，并数字签名“消息”。
（10）产生Deskey4（随机对称密钥），用Deskey4加密签名后消息，用CA的密钥交换公钥加密Deskey4和商家的ID形成数字信封，再将所有信息向CA发出。
CA收到后：
（11）用密钥交换私钥解开数字信封得Deskey4和商家的ID，用Deskey5解密（10）中的加密消息得到注册表请求。
（12）根据商家的数字签名验证注册表请求，如果签名有效，消息处理继续，否则，返回商家提示消息响应。
（13）使用商家账户信息验证注册表请求。
注意：SET协议中没有定义CA和收单行如何交换信息验证注册表内的信息。
（14）如果注册表信息有效，CA产生一个证书响应，并数字签名。
（15）将（证书响应 商家的两个公钥 CA的签名公钥）发给商家。
商家收到后：
（16）验证证书。
（17）验证CA的数字签名。
（18）保存证书至安全地方。
3.购买请求（Purchase Request）
（1）持卡人到商家的网站浏览、挑选、订购后请求支付网关的密钥交换证书。
（2）商家收到请求后，为该消息制定Numl（唯一识别号）并用商家签名私钥数字签名，然后将（签名后Numl1 商家签名证书 支付网关的密钥交换证书）发给持卡人。
持卡人收到后：
（3）验证商家和支付网关证书，并保存证书。
（4）产生订购信息OI和支付指令PI，将Numl插入OI和PI中。
（5）生成OI和PI的双重签名，即对（OI的消息摘要 PI的消息摘要）计算Hash值，再对Hash值用持卡人的签名私钥加密。
（6）产生Deskey6（随机对称密钥）。
（7）用Deskey6加密PI的双重签名等得到加密的支付信息；用Deskey6加密持卡人账号；用支付网关的密钥交换公钥加密Deskey6形成支付信封。
（8）将OI的双重签名、支付信封、加密的支付信息、PI的消息摘要、持卡人密钥交换证书一起发送给商家。
商家收到后：
（9）验证持卡人证书。
（10）验证双重签名，即用持卡人的密钥交换公钥解密OI的双重签名，计算OI的消息摘要，再对OI的消息摘要和PI的消息摘要计算Hash值，再与解密后的比较。
（11）商家将PI送支付网关。
（12）生成购物响应消息并数字签名。
（13）将购物响应和商家密钥交换证书发送给持卡人。
持卡人收到购物响应后：
（14）验证商家证书。
（15）验证购物响应中的商家签名。
（16）持卡人保存购物响应。
4.支付授权（Payment Authorization）
（1）商家软件产生并数字签署一个授权，其中包含授权的金额、Numl。
（2）产生Deskey7加密授权请求并用支付网关的密钥交换公钥生成网关信封。
（3）商家将（加密后的授权请求 （PI 双重签名））和（网关信封 持卡人签名证书 （商家的密钥交换证书和签名证书）传给支付网关（注意：SET协议中还包括一个销售交易，允许商家在一个消息中同时进行交易授权和支付请求）。
支付网关收到授权请求后：
（4）解密网关信封得Deskey7；用Deskey7解密请求信息。
（5）验证商家证书。
（6）验证商家签名。
（7）支付网关解密PI的数字信封得到Deskey6和账户信息；用Deskey6解密得到PI。
（8）验证持卡人证书。
（9）验证PI双重签名，即用持卡人签名公钥解密双重签名，计算PI的消息摘要，与包含在PI中OI摘要一起计算Hash值，与解密后的双重签名对比。
（10）验证Numl和PI中的识别号。
（11）将授权请求通过银行网络发向发卡行。
（12）生成并数字签名授权响应消息。
（13）产生Deskey8加密授权响应；用商家的密钥交换公钥加密Deskey8得到商家信封。
（14）产生Deskey9加密请款标记，用支付网关的密钥交换公钥加密Deskey9生成网关信封。
（15）将（（加密后授权响应和商家信封） （加密后请款标记和网关信封） 支付网关签名证书）一起发送商家。
商家收到后：
（16）验证支付网关证书。
（17）用商家的密钥交换私钥解开数字信封得到Deskey8，用Deskey8解密授权响应。
（18）验证支付网关对授权响应的数字签名。
（19）保存授权响应、加密后的扣款令牌和请款标志，用于以后扣款处理。至此，商家完成持卡人的购物处理。
5.支付请款（Payment Capture）
（1）商家产生并数字签名一个请款请求（Capture Request）。
（2）产生Deskey10加密扣款请求，用支付网关密钥交换公钥加密Deskey10生成支付信封。
（3）将（（加密后扣款请求和支付信封） （加密后扣款令牌和网关信封））发向支付网关。
支付网关收到扣款请求后：
（4）用支付网关密钥交换私钥解密支付信封得到Deskey10；用Deskey10解密扣款请求。
（5）验证扣款请求的商家签名。
（6）用支付网关密钥交换私钥解密Deskey9，再用Deskey9解密请款标记。
（7）比较扣款请求和请款标记。
（8）将扣款请求通过银行网络发送到发卡行。
（9）生成并数字签名扣款响应消息。
（10）产生Deskey11加密扣款响应；用商家的密钥交换公钥加密Deskey11生成商家信封。
（11）将（（加密扣款响应和商家信封） 网关的签名证书）一起传给商家。
商家收到支付网关传来的扣款响应后：
（12）用商家私钥解密Deskey11，用Deksy11解密扣款响应。
（13）验证网关证书。
（14）验证支付网关的签名。
（15）商家保存扣款响应，用于与收单行得到的付款进行对账。
9.3.4SET协议与SSL协议的比较
SET是应用于互联网上以信用卡为基础的安全电子交易协议，而SSL仅是一个数据传输安全协议。SET是针对信用卡在互联网上如何安全付款而制定出的交易应用协议，而SSL则只是为确保通信双方资料安全传输而制定的协议。由于SSL原本就是因为Web而产生，所以目前也以在HTTP上的应用最为广泛。SSL保证了交易双方资料的传输安全，但未涉及各种交易的过程及消息内容。不同的消息设计可能会造成完全不同的安全等级。SET除了有标准外，尚有VISA/MasterCard等组织就制度和操作做出规范，将此标准变得具体而且可行。
事实上，SET和SSL除了都采用RSA公钥技术外，两者在其他技术方面没有任何相似之处。RSA在SET和SSL中也被用来实现不同的安全目标，两者的主要区别在于：
（1）SET是一个多方的报文协议，它定义了银行、商家、持卡人之间必要的报文规范；SSL只是简单地在交易双方之间建立安全连接。
（2）SSL是面向连接地，而SET允许各方之间的报文交换不是实时的。
（3）SET报文能够在银行内部网或者其他网络上传输，而基于SSL之上的卡支付系统只能与Web浏览器捆绑在一起。
SSL提供的保密连接存在较大的漏洞。SSL除了传输过程以外不能提供任何安全保证，不能使客户确信商家接收信用卡支付是得到授权的。互联网上经常会出现一些陌生的店铺，正因为此，网上商家发生欺诈行为的可能性要比街头店铺大得多。进一步说，即使是一家诚实的网上商家，如果在收到客户的信用卡号后没有采用好的方法保护其安全性，那么信用卡号也很容易被“黑客”通过商家服务器窃取。
SSL协议的不足首先在于，客户的信息先到商家，让商家看到信用卡上的卡号信息。这样，客户信息的安全性就得不到保证。
SET与SSL相比具有下列几个方面的优点：
（1）SET为商家提供了保护自己的手段，使商家免受欺诈的困扰，降低了商家的运营成本。
（2）对消费者而言，SET保证了商家的合法性，并且客户的信用卡号不会被窃取，SET替消费者保守了更多的秘密，使其在线购物更加轻松。
（3）对收单银行和发卡银行以及各种信用卡组织来说，SET可以帮助它们将业务扩展到Internet这个广阔的空间，从而使得信用卡网上支付具有更低的欺骗概率，这使得它比其他支付方式具有更强的竞争力。
（4）SET对于参与交易的各方定义了互操作的接口，一个系统可以由不同厂商的产品构筑。
SET的另外一个优点在于，它可以用在系统的一部分。例如，有的商家考虑在与银行连接中使用SET，而与客户连接时仍然使用SSL。这种方案既回避了在顾客机器上安装电子钱包软件，同时又获得了SET提供的很多优点。
SET较之SSL具有更强的安全性，这主要是为了解决持卡人、商家和银行三者之间通过电子支付的交易而设计的，以保证支付信息的机密性、支付过程的完整性、商家及持卡人的合法身份以及可操作性，用以支持B2C的电子商务模式，即消费者持卡在网上购物与交易的模式。SET中的核心技术主要有公开密钥加密、消息摘要、数字签名、数字信封、数字证书等，能在电子交易环节上提供更大的信任度、更完整的交易信息、更高的安全性和更小的欺诈可能性。
实际上，SSL一开始并不是为支持电子商务而设计的，而是后来为了克服其局限性而在原来的基础上发展了PKI。然而，就当初的设计目的而言，SSL的功能完成得非常圆满。目前，很多银行和电子商务解决方案提供商还在考虑使用SSL构建更多的安全支付系统，但是如果没有经裁剪客户方软件的话，基于SSL的系统不可能实现SET这种专用银行卡支付协议所能达到的安全性。
SET在交易参与方的身份验证和交易的不可否认性等方面提供了SSL协议无法实现的特性，因此SET较之SSL具有更强的安全性和可靠性。
“思考题”
1.什么是SET？基于SET的交易中包含哪些参与方？
2.SET认证技术主要涉及哪些内容？
3.数字信封是如何构成的？
4.在SET协议中，双重签名的作用是什么？
5.数字签名的作用是什么？
6.简述SET协议证书管理功能。
7.什么是SSL？简述SSL握手协议的过程。
8.SSL所提供的安全服务有哪些？
9.与SSL协议相比，SET协议有哪些主要优点？
