AWS Payment Cryptography 的 HSM 架构 - 深入解析 PCI DSS 合规的支付加密基础
AWS Payment Cryptography 是面向支付行业的托管 HSM 服务，以 Serverless 方式提供 PCI DSS 合规的加密和令牌化。本文深入解析 PIN 块生成、DUKPT 密钥管理以及与 CloudHSM 的使用区分等支付加密的技术机制。
支付行业需要托管 HSM 的背景
信用卡支付的加密处理离不开称为 PCI PTS HSM 的物理安全模块。传统上，支付运营商在本地部署专用 HSM，承担年数千万日元规模的运维成本。HSM 固件更新、密钥轮换、物理访问控制等运维负担极高。AWS Payment Cryptography 正是为解决这一课题而设计的服务，以 Serverless 形式提供 PCI PTS HSM 认证的加密操作。无需管理物理设备，通过 API 调用即可执行 PIN 块生成/验证、MAC 计算、密钥导入/导出等支付特有的加密操作。
PIN 块生成与验证的密码学机制
在 ATM 或刷卡终端输入的 PIN 不会以明文传输。PIN 被转换为称为 PIN 块的格式，以加密状态在网络中传输。在 ISO 9564 定义的 PIN 块格式中，Payment Cryptography 支持 Format 0 (ISO-0)、Format 1 (ISO-1)、Format 3 (ISO-3)、Format 4 (ISO-4)。Format 4 是最新标准，使用 AES-128 加密并包含随机填充，安全性最高。PIN 验证流程中，终端用 DUKPT 派生密钥加密 PIN 块，Payment Cryptography 用对应的 BDK 派生相同密钥进行解密，与存储的 PIN 偏移值比较来判定正误。
DUKPT 密钥管理支撑终端安全的原因
DUKPT (Derived Unique Key Per Transaction) 是按支付终端每笔交易派生唯一加密密钥的密钥管理方式。终端仅注入从 BDK (Base Derivation Key) 派生的初始密钥 (IPEK)，BDK 本身不存储在终端。每笔交易从 IPEK 进一步生成派生密钥，即使一个密钥泄露也无法逆推 BDK 或其他交易的密钥。Payment Cryptography 在服务端保管 BDK，通过 API 执行密钥派生和加密操作。终端侧的密钥注入使用 TR-34 协议安全地分发 IPEK。
令牌化与卡数据保护的实现模式
PCI DSS v4.0 要求存储卡号 (PAN) 时必须通过加密或令牌化进行保护。使用 Payment Cryptography 的令牌化典型实现中，通过 EncryptData API 加密 PAN，将密文作为令牌存储在 DynamoDB 中。支付处理时通过 DecryptData API 解密，将明文 PAN 发送到支付网络。这种方式下应用层完全不接触明文 PAN，大幅缩小 PCI DSS 的审计范围。
与 CloudHSM 的使用区分 - 通用加密与支付专用的边界
AWS 有 CloudHSM 和 Payment Cryptography 两种 HSM 服务。CloudHSM 是获得 FIPS 140-2 Level 3 认证的通用 HSM，可通过 PKCS#11、JCE、OpenSSL 等标准接口执行任意加密操作。而 Payment Cryptography 是获得 PCI PTS HSM 认证的支付专用 HSM，原生支持 PIN 块操作、DUKPT、TR-31 密钥块等支付行业标准。选择标准明确：支付处理（PIN 验证、卡数据加密、MAC 生成）用 Payment Cryptography，通用加密（TLS 终端、代码签名、数据库加密）用 CloudHSM。
Payment Cryptography 生产导入的设计指南
生产导入首先确定密钥导入策略。从现有本地 HSM 迁移推荐使用 TR-34 协议。TR-34 是基于 RSA 的非对称密钥交换方式，实现密钥明文不暴露的安全迁移。ImportKey API 原生支持 TR-34。可用性方面，服务在区域内自动冗余，但多区域架构需在各区域单独导入密钥。监控方面，通过 CloudTrail 记录所有 API 调用，CloudWatch 指标监控延迟和错误率。 关于支付安全的深入学习，相关书籍 (Amazon)也可供参考。