很多备考电子商务设计师的考生都有这样的困惑：同样是保障网络交易安全的协议，为什么教材里既讲SSL又讲SET，两者到底有什么区别？为什么题目里一出现"双重签名"，很多人就分不清它到底签的是什么？这篇文章要把SET安全电子交易协议的来龙去脉、底层密码学机制、参与方体系以及它与SSL的根本区别彻底讲透，让你在考场上不再丢分。
SET的全称是Secure Electronic Transaction，中文译作安全电子交易协议。它诞生于二十世纪九十年代中后期，那正是互联网电子商务从萌芽走向爆发的阶段。当时的网络购物面临一个尖锐的矛盾：消费者愿意在网上浏览商品、比较价格，却不敢轻易把自己的银行卡号、密码等信息通过网络传输出去。因为裸奔的信用卡信息一旦被截获，后果不堪设想。为了建立一个各方都能信任的线上支付环境，1996年由国际信用卡组织Visa和MasterCard牵头，联合IBM、Microsoft、Netscape、VeriSign等多家公司共同制定了SET协议。它的定位非常清晰，就是专门服务于银行卡在线支付场景的安全协议，而不是一个通用的通信加密协议。
需要强调的是，SET并不是凭空发明了一套全新的密码学算法，而是把当时已经成熟的公开密钥基础设施、数字证书、数字签名、数字信封、消息摘要等一系列密码学技术，按照电子商务支付流程的实际需要重新组合编排，形成了一套完整的、面向特定业务场景的安全协议体系。理解这一点非常重要，因为软考命题人特别喜欢考察SET与这些底层技术之间的关系。
从教材和标准文档的角度看，SET可以定义为：一个基于消息流、为在线银行卡支付提供保密性、完整性、身份认证和不可否认性保障的开放技术规范。它的核心设计目标可以归纳为五点。第一，保证信息的机密性，确保持卡人的账户和支付信息在网络上传输时不被非法窃取。第二，保证数据的完整性，确保传输过程中的数据不被篡改。第三，验证持卡人是信用卡账户的合法使用者，也就是对持卡人进行身份认证。第四，验证商家能够受理该品牌的信用卡，也就是对商家进行身份认证。第五，确保软件遵循相同的协议和消息格式，实现不同厂商系统之间的互操作性。
这五大目标在历年真题里是反复出现的考点。尤其是"身份认证"这一项，很多题目会把它拆成持卡人认证和商家认证两个方向来考，问你SET是否需要同时对买卖双方进行认证。答案是肯定的，这正是SET与SSL最大的理念差异之一。
SET协议定义了一个完整的参与方体系，理解这个体系是理解整个协议运作的前提。参与方主要包括五类。第一类是持卡人，也就是使用银行卡进行支付的消费者，他需要持有发卡银行签发的数字证书。第二类是商家，也就是在网上销售商品或服务的卖家，他同样需要持有证书。第三类是发卡银行，它向持卡人发放银行卡，并对持卡人的身份负责。第四类是收单银行，也叫收单机构，它负责为商家开设账户、处理银行卡的支付授权和结算。第五类是支付网关，它是SET协议中的一个关键角色，位于互联网与银行内部金融网络之间，负责把互联网上的支付请求转换成银行系统能够处理的格式，起到边界隔离和安全转换的作用。
此外，SET体系中还存在一个重要的支撑角色，就是认证中心，即CA。CA负责为上述参与方签发和管理数字证书，是整个信任体系的基础。考生最容易混淆的是收单银行和支付网关的关系：收单银行是资金的最终受理方，而支付网关是收单银行伸向互联网的"接口"。许多真题会围绕支付网关的作用出题，问你支付网关到底连接的是哪两边。
其中SET中最具标志性、也是软考考得最多的机制，就是双重签名。要理解它，必须先理解它要解决的真实业务问题。在一次在线购物中，持卡人会向商家发送两类信息：一类是订单信息，包括买了什么、多少钱；另一类是支付信息，主要是银行卡号等敏感信息。这两类信息在业务上需要被不同的人看到。订单信息商家需要看到，因为商家要据此发货；但银行卡号商家并不需要看到，商家只需要确认这笔钱能够支付即可。而支付信息只有支付网关和银行需要看到，银行并不关心你具体买了什么商品。
矛盾就在这里：如果持卡人把订单信息和支付信息一起打包加密发给商家，商家就能看到银行卡号，存在泄露风险；如果持卡人把两类信息都发给银行，银行能看到购物内容，又侵犯了消费者隐私。双重签名正是为了解决这个"信息按需可见"的问题而设计的。
双重签名的实现过程是这样的。持卡人首先对订单信息做一次消息摘要运算，得到一个摘要值，记为订单摘要；再对支付信息做一次消息摘要运算，得到支付摘要。然后把这两个摘要值拼接起来，再做一次消息摘要运算，得到一个总摘要，最后用持卡人自己的私钥对这个总摘要进行签名，得到的签名结果就是双重签名。通过这种方式，订单信息和支付信息被绑定在了一起，任何一方单独篡改订单信息或支付信息，都会导致双重签名验证失败。
更关键的是信息的分发方式。持卡人把订单信息和支付摘要一起发给商家，把支付信息和订单摘要一起通过商家转发给支付网关。商家拿到订单信息，可以验证双重签名中与订单相关的部分，从而确认订单的真实性和完整性，但商家手里只有支付摘要，无法还原出银行卡号。支付网关拿到支付信息，同样可以验证双重签名中与支付相关的部分，确认支付指令的真实性，但网关只有订单摘要，看不到具体的购物内容。这样，订单信息只有商家可见，支付信息只有网关可见，而双重签名又把两者牢牢绑定，防止任何一方在事后抵赖或篡改。
这个机制的精妙之处在于，它同时实现了三个目标：一是支付信息对商家的保密，二是订单信息对银行的保密，三是订单与支付之间的防篡改绑定。软考常考的点就是"双重签名到底对什么进行签名"，正确答案是：双重签名对订单摘要和支付摘要拼接后的总摘要进行签名，既保证支付信息不向商家泄露，又保证订单信息与支付信息的对应关系不可抵赖。
SET协议在数据传输的加密环节，采用的是数字信封技术。数字信封的设计动机是解决非对称加密效率低的问题。RSA这类非对称加密算法虽然能很好地解决密钥分发问题，但加解密速度慢，不适合加密大量数据；而DES这类对称加密算法速度快，但密钥的分发和安全传递是个难题。数字信封把两者的优点结合起来。
具体做法是：发送方首先生成一个随机的对称密钥，用这个对称密钥对实际要传输的报文进行加密，得到密文；然后再用接收方的公钥对这个对称密钥进行加密，得到一个被"封装"起来的密钥密文。这个用接收方公钥加密对称密钥的过程，就相当于把对称密钥装进了一个只有接收方才能打开的信封里。发送方把报文密文和密钥密文一起发送给接收方。接收方收到后，先用自己的私钥解开信封，得到对称密钥，再用这个对称密钥解密报文密文，还原出明文。
在整个过程中，实际的数据加密用的是快速的对称算法，而密钥的安全传递依靠的是非对称算法，既保证了效率，又保证了安全。软考真题里考数字信封最常见的问法是：发送方用谁的公钥加密对称密钥，用谁的密钥加密报文。标准答案是：用接收方的公钥加密对称密钥，用随机生成的对称密钥加密报文。这个考点在电子商务设计师、系统分析师、信息安全工程师等多个科目里都反复出现过，务必记牢。
SET协议定义了一整套完整的支付流程，从持卡人发起购买到资金最终结算，可以概括为三个主要阶段。第一阶段是购买请求阶段。持卡人选定商品后，向商家发送购买请求消息，这个消息里包含了订单信息和支付信息，并且按照前面讲的双重签名和数字信封机制进行了处理。商家收到后，验证持卡人的证书和双重签名，确认订单真实有效，然后生成一个交易标识，进入下一阶段。
第二阶段是付款授权阶段。商家把持卡人的支付信息连同自己的授权请求一起，通过支付网关发送给收单银行。支付网关验证商家证书，收单银行验证持卡人账户的有效性和余额或信用额度，确认可以支付后，向商家返回授权结果。这里有一个重要的细节：授权阶段只是"冻结"了资金或确认了支付能力，钱并没有真正从持卡人账户划走。
商家在完成发货后，向支付网关发起结算请求，请求银行把之前授权的资金真正划入商家账户。支付网关把请求转发给收单银行，银行完成资金划转后，向商家返回结算结果。至此，一次完整的SET交易才真正结束。
这三个阶段是软考网络规划设计师和电子商务设计师的常见考点。真题里曾考过"SET安全电子交易的整个过程不包括哪个阶段"，选项里会混入一个看起来合理但实际上不属于SET流程的阶段，比如"持卡人和商家匹配"这种。正确答案的思路是：SET的流程是围绕支付授权和结算展开的，注册、购买请求、付款授权、付款结算这些是真实存在的阶段，而"持卡人和商家匹配"这种表述并不是SET流程中的正式阶段。
从技术构成的角度看，SET是一套密码学技术的组合应用，考生需要把这些技术各自的用途理清楚。对称加密用
本篇完！