1. 项目背景与核心价值
SET协议（Secure Electronic Transaction）作为电子商务安全支付领域的里程碑式技术规范，其原始文献至今仍被众多支付安全研究者视为必读经典。这份由Visa和MasterCard两大卡组织于1996年联合推出的技术标准，首次系统性地解决了信用卡在线支付场景下的身份认证、数据加密和交易不可抵赖性三大核心安全问题。
我在支付行业从业十二年，亲眼见证过SET协议从炙手可热到逐渐被3D Secure替代的技术演进过程。但有趣的是，如今许多新兴的区块链支付协议和数字身份方案，其底层设计思路仍能看到SET协议的影子。这也是为什么我坚持认为，任何想深入理解现代支付安全体系的技术人员，都应该仔细研读这份原始文献。
2. 协议架构深度解析
2.1 双签名机制的精妙设计
SET最革命性的创新在于其双签名（Dual Signature）技术。这个设计完美解决了消费者既要向商户隐藏信用卡信息，又要向银行证明自己确实授权了特定订单金额的矛盾需求。具体实现上：
- 消费者端生成两组哈希：
- 订单信息哈希（OI Hash）
- 支付指令哈希（PI Hash）
- 将两个哈希值拼接后再做哈希，用消费者私钥签名这个最终哈希值
- 将OI明文+PI密文+双签名发送给商户
- 商户验证OI哈希与双签名的匹配性
- 银行端通过解密PI验证支付指令真实性
关键提示：这种"哈希的哈希"签名结构，后来被比特币的隔离见证（SegWit）方案借鉴用于解决交易延展性问题。
2.2 证书体系的超前部署
SET协议早于现代PKI体系成熟之前，就构建了完整的四级证书链：
- 根CA证书（由Visa/MasterCard共同管理）
- 品牌CA证书（分卡组织维护）
- 发卡行/收单行CA证书
- 持卡人/商户证书
每个交易参与方都需要通过严格的KYC流程才能获得对应层级的证书。特别值得注意的是，持卡人证书并非存储在本地，而是由发卡行托管——这个设计显著降低了证书泄露风险，但也导致了大规模部署的困难。
3. 技术实现关键点
3.1 消息流设计规范
SET定义了完整的7类交易消息流，以典型的购买流程为例：
- 初始化请求（PInitReq）
- 初始化响应（PInitRes）
- 购买请求（PReq）
- 购买响应（PRes）
- 授权请求（AuthReq）
- 授权响应（AuthRes）
- 捕获请求（CapReq）
每个消息都采用ASN.1编码规范，包含：
- 消息头（Message Header）
- 消息体（Message Body）
- 签名块（Signature Block）
3.2 加密算法组合策略
考虑到90年代的计算能力限制，SET采用了分层加密策略：
- 证书签名：RSA with SHA-1
- 会话密钥交换：RSA 1024bit
- 数据加密：DES 56bit（后来升级为3DES）
- 哈希算法：SHA-1
这种混合加密方案在保证安全性的同时，使当时的PC也能在合理时间内完成加密运算。不过以现代眼光看，其中的SHA-1和DES都已被证明存在安全隐患。
4. 现代支付系统中的SET遗产
4.1 对3D Secure协议的影响
虽然3D Secure（Visa验证/万事达SecureCode）取代了SET的市场地位，但其核心思想仍延续了SET的三个关键特性：
- 持卡人身份二次验证
- 交易数据加密传输
- 责任划分明确化
主要改进在于：
- 将复杂的本地证书体系改为服务器端认证
- 简化消息交互步骤
- 支持移动设备验证
4.2 区块链支付协议的借鉴
近年来一些区块链支付协议（如IBM的Hyperledger Fabric支付方案）明显借鉴了SET的设计理念：
- 交易信息的"需知原则"（Need-to-Know）
- 多方参与的分布式验证
- 交易不可篡改特性
不过区块链方案用共识算法替代了中心化的CA体系，这是本质性的架构差异。
5. 文献研读实践指南
5.1 推荐阅读顺序
根据我的研读经验，建议按以下顺序阅读SET原始文献：
- 第3章"业务需求"（理解设计初衷）
- 第5章"加密框架"（掌握基础密码学方案）
- 第7章"证书管理"
- 附录B"消息格式示例"
- 第9章"处理规则"（交易逻辑细节）
5.2 实验环境搭建
要真正理解SET协议，建议搭建以下实验环境：
- 安装OpenSSL 1.0.2（支持传统DES算法）
- 使用Python的pyasn1模块解析消息结构
- Wireshark配置SET协议解码器
- 虚拟机运行Windows 98（原始SET客户端兼容环境）
避坑提示：现代操作系统默认禁用的DES算法，需在OpenSSL配置中特别启用。
6. 协议局限性与现代启示
6.1 未能普及的技术原因
SET协议最终未能大规模应用，主要受限于：
- 客户端部署成本高（需要单独安装数字钱包）
- 证书管理复杂度（每年需要更新持卡人证书）
- 交易处理延迟（完整流程需10-15秒）
- 商户改造投入大（需要专用支付接口）
6.2 对当代开发者的启示
SET协议留下的宝贵经验包括：
- 安全性与便利性的平衡艺术
- 多方参与系统的责任边界设计
- 加密方案的向前兼容考量
- 用户教育在安全体系中的重要性
我在参与设计某跨国支付网关时，就曾借鉴SET的"失败经验"，特别注意避免过度依赖客户端证书，这个决策最终被证明是正确的。