1. 支付SDK安全架构概览与核心概念
支付SDK在处理交易敏感信息（卡号、密码、令牌）时必须构建纵深防御体系。现代支付SDK安全架构以对称加密保护传输数据，用非对称加密交换会话密钥，以数字签名保证消息来源可信，通过哈希或MAC实现完整性保护。四者组合形成“机密性 + 真实性 + 完整性”的安全三角。
1.1 核心概念速览
| 概念 | 作用 | 典型算法 | 密钥管理 |
|---|---|---|---|
| 对称加密 | 保证数据机密性 | AES-256-GCM, ChaCha20-Poly1305 | 双方共享同一个密钥 |
| 非对称加密 | 安全传输对称密钥、数字信封 | RSA-2048, ECDH P-256 | 公钥分发，私钥保密 |
| 数字签名 | 验证消息来源和不可抵赖 | ECDSA, RSA-PSS | 私钥签名，公钥验签 |
| 完整性保护 | 检测数据篡改 | HMAC-SHA256, SHA-256 | 共享密钥（HMAC）或无密钥（哈希） |
1.2 安全架构分层流程
一次典型的支付请求在SDK内部经过以下处理阶段，每个阶段使用不同的安全机制：
- 序列化：将请求对象转为JSON/Protocol Buffers。
- 完整性摘要：对整个请求载荷计算HMAC，附加在尾部作为完整性校验值。
- 对称加密：使用会话密钥（AES-256-GCM）加密载荷+HMAC，同时附加初始向量IV。
- 密钥封装：用服务端公钥（RSA/ECDH）加密会话密钥，形成“数字信封”。
- 数字签名：对密文+信封+时间戳等元数据生成签名（ECDSA）。
- 封装发送：将签名、信封、IV、密文打包发送至网关。
设计要点：AES-256-GCM同时提供加密和认证（AEAD），减少额外HMAC步骤；许多现代SDK直接使用AEAD，但为兼容旧系统仍保留独立HMAC。
常见错误：将签名算法与加密算法混为一谈。签名使用私钥，加密使用公钥；若反向使用会导致严重安全漏洞（如用私钥加密相当于签名，易被伪造）。
1.3 关键实现示例
以下命令生成RSA-2048密钥对（支付SDK服务端常用）并展示OpenSSL输出格式：
# 生成私钥（PKCS#8格式）
openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
# 提取公钥
openssl pkey -in private_key.pem -pubout -out public_key.pemHMAC计算示例（用于完整性校验）：
import hmac
import hashlib
message = b'{"amount":100,"currency":"USD"}'
key = b'shared_hmac_key_32bytes'
digest = hmac.new(key, message, hashlib.sha256).hexdigest()
print(digest) # 示例输出: b3a7... (64 hex chars)
性能注意：非对称加密（RSA）比对称加密慢1～3个数量级。支付SDK应仅对小的会话密钥做非对称操作，避免直接加密业务载荷。HTTPS/TLS本身就使用类似“非对称握手+对称会话”策略。
1.4 调试与部署检查清单
- 密钥轮换：生产环境定期更换对称密钥和签名私钥，最长不超过30天。
- 加密套件裁剪：仅允许AEAD模式（GCM/CCM）和强HMAC（SHA-256及以上），禁用CBC/ECB。
- 签名验证失败：SDK必须完全停止请求并记录告警，不能降级使用。
- 日志脱敏：调试日志不得输出密钥、IV、签名原始值，只输出“verify_ok/fail”。