0. 双重签名

在SET协议中，双重签名用于同时保护：

订单信息（OI, Order Information） → 提供给商户

支付信息（PI, Payment Information） → 提供给银行

流程如下：

分别哈希：

计算OI的哈希：H(OI)

计算PI的哈希：H(PI)

连接并二次哈希：

拼接哈希值：H(PI) || H(OI)

对拼接结果哈希：H(H(PI) || H(OI))

私钥签名：

用持卡人私钥加密上一步结果，生成双重签名：

DS = EKRC [ H(H(PI) || H(OI)) ]

1. SET协议完整交易流程

参与方

持卡人（Cardholder）：发起支付。

商户（Merchant）：处理订单。

支付网关（Payment Gateway）：连接银行网络。

发卡行（Issuer Bank）：授权交易。

阶段划分

初始化阶段：InitReq/InitRes

支付请求阶段：PReq/PRes

授权阶段：AuthReq/AuthRes

资金捕获阶段：CapReq/CapRes

2. 详细消息格式与交互

(1) 初始化阶段：InitReq/InitRes

目的：交换证书和协议参数。（持卡人需获得商家和支付网关的证书） 消息流：

字段说明：

InitReq

CardholderCert: 持卡人数字证书（含公钥）。

SupportedAlgs: 支持的加密算法列表（如RSA、3DES）。

信用卡版本等

InitRes

MerchantCert: 商户证书。

PaymentGatewayCert: 支付网关证书。

TransactionID: 交易唯一标识符。

(2) 支付请求阶段：PReq/PRes

目的：提交订单和支付信息。

PReq 由两部分组成:

– 订单信息 (OI) : links to order description

– 支付信息(PI): amount, card data, IDs 消息流：

字段说明：

PReq

PI (Payment Instructions)：

加密字段（支付网关公钥加密），包含：

卡号（PAN）

交易金额

随机对称密钥（用于后续通信）。

OI (Order Information)：

明文订单详情（商品、商户ID等）。

Dual Signature：

对Hash( Hash(PI) || Hash(OI)) 的签名，确保数据一致性。

PRes

OrderStatus: 订单初步确认状态（如“待授权”）。

(3) 授权阶段：AuthReq/AuthRes

目的：向银行请求交易授权。 消息流：

字段说明：

AuthReq

继承自 PReq 含有 PI （来自 PReq） 含有 H(Order)

新增 MerchantData（如终端ID）。

银行处理：解密 AuthReq ；校验商家签名； 解密来自于持卡人的 PI ；校验双重签名 ；从PI中抽取卡数据

AuthRes

AuthCode: 银行授权码（如00表示成功）。

CaptureToken: 后续资金捕获的令牌（替代卡号）。

(4) 资金捕获阶段：CapReq/CapRes

目的：商户请求结算资金。 消息流：

字段说明：

CapReq

CaptureToken: 来自 AuthRes 的令牌。

Amount: 实际结算金额（可能部分退款）。

CapRes

SettlementStatus: 资金结算结果（如“已完成”）。

3. 安全机制总结

机制实现方式阶段数据保密PI加密（支付网关公钥）PReq/AuthReq完整性双重签名（PI+OI）PReq/AuthReq抗抵赖数字签名（持卡人、商户、网关）全流程令牌化CaptureToken替代卡号AuthRes/CapReq

Q1: 为什么需要双重签名？

防止商户看到支付信息（PI）或银行看到订单信息（OI）。

Q2: CaptureToken的作用？

替代卡号参与后续结算，减少敏感数据泄露风险。