AWS Payment Cryptography 的 HSM 架构 - 深入解析符合 PCI DSS 的支付加密基础
AWS Payment Cryptography 是专门面向支付行业的托管 HSM 服务，以无服务器方式提供符合 PCI DSS 的加密 / 令牌化。本文深入讲解 PIN 块生成、DUKPT 密钥管理、与 CloudHSM 的选用等支付加密的技术机制。
支付行业需要托管 HSM 的背景
信用卡支付的加密处理离不开被称为 PCI PTS HSM 的物理安全模块。过去，支付服务商在本地部署专用 HSM，从设备采购和维护合同、安装环境的物理安全保障到审计的处理，都由自己承担。这些是与交易量无关而产生的固定费用，负担不小。HSM 的固件更新、密钥轮换、物理访问控制等运维负荷极高。AWS Payment Cryptography 是为解决这一问题而设计的服务，提供满足 PCI DSS Level 1 和 PCI PIN Security 要求的托管 HSM 基础。用户只需调用 API，就可以执行卡号（PAN）的加密、PIN 块的生成 / 验证、MAC（消息认证码）的计算等支付特有的加密操作。由于不再需要从 HSM 采购到报废的生命周期管理，支付系统迁移到云的最大障碍得以消除。费用（截至 2026 年 8 月 / 弗吉尼亚北部和东京）为针对持有的活跃密钥数量和 API 请求数量的按用量计费。活跃密钥每个每月 1.00 美元，根据持有数量的阶梯降至 0.10 / 0.01 / 0.001 美元。API 请求按每月数量的递减阶梯计费。前 2,000 万次请求为每 10,000 次请求 2.00 美元，之后按 0.75 / 0.25 / 0.10 美元逐级降低（截至 2026 年 8 月 / 不因 API 类型而存在价格差异）。两个区域的密钥单价 / 请求单价相同。
PIN 块生成 / 验证的密码学机制
在 ATM 或刷卡终端上输入的 PIN 不会以明文形式传输。PIN 会被转换为称为 PIN 块的格式，以加密状态在网络中传输。PIN 块格式由 ISO 9564 定义。在这些格式中，Payment Cryptography 支持 Format 0（ISO-0）、Format 1（ISO-1）、Format 3（ISO-3）、Format 4（ISO-4）。Format 0 是通过 XOR 运算将 PIN 与 PAN 结合的方式，普及程度最高。另一方面，Format 4 是以 AES 加密为前提的最新格式，随着 3DES 的废止，迁移正在推进。使用 Payment Cryptography 的 TranslatePinData API，可以在服务器端安全地执行不同格式之间的转换。PIN 的验证使用 VerifyPinData API，解密 / 比对在 HSM 内部完成，因此不存在明文 PIN 暴露在内存中的风险。这些都作为同步 API 提供，因此可以直接嵌入授权处理的流程中。AWS 未公布延迟的目标值，因此通过在自身环境中实测来确认响应时间是否满足要求是稳妥的做法。
DUKPT 密钥管理支撑终端安全的原因
DUKPT（Derived Unique Key Per Transaction）是为每个支付终端按交易派生唯一加密密钥的密钥管理方式。终端中仅注入从 BDK（Base Derivation Key）派生的初始密钥（IPEK），BDK 本身不保存在终端中。每笔交易都会从 IPEK 进一步生成派生密钥，因此即使有一个密钥泄露，也不会影响过去 / 未来的交易。Payment Cryptography 在 HSM 内部完成 DUKPT 的密钥派生。BDK 通过 CreateKey API 生成。注入终端的 IPEK 则通过 ExportKey API 生成 / 导出。导出时指定导出属性 ExportDukptInitialKey 和 KSN（Key Serial Number）。DeriveKey 不是 API 名称，而是密钥用途属性（KeyModesOfUse）的值，必须事先在 BDK 一侧设置启用 DeriveKey 的属性。导出的 IPEK 不会在服务端持久化，也不会成为之后 API 操作的目标，因此设计的前提是在获取时完成向终端的注入。除了基于 3DES 的 DUKPT，还支持基于 AES-256 的 DUKPT（ANSI X9.24-3），可以在迁移期间并行运行。值得注意的是“约 100 万”这个数字的定位。这不是可以从 BDK 派生的终端密钥的数量，而是源自 KSN 交易计数器的上限。TDES DUKPT 的 KSN 为 10 字节，在官方文档记载的结构（截至 2026 年 8 月）中分为 Key Set ID 24 bit / 终端 ID 19 bit / 交易计数器 21 bit。由此，1 个 IPEK 可处理的交易数被限制在约 100 万次。AES DUKPT 的 KSN 为 12 字节，由 BDK ID 32 bit / 派生标识符 32 bit / 计数器 32 bit 构成，计数器长度大幅扩大。可容纳的终端数量取决于如何设计 KSN 的标识符部分，因此密钥的分发策略从终端数量和每台终端的交易量两个方面进行考虑。Azure Payment HSM 是以单租户方式出租 Thales payShield 10K 的形态，DUKPT 的密钥派生本身可以作为 payShield 的主机命令使用。但是，命令序列的实现和 HSM 的运维（固件更新 / 冗余配置 / 容量设计）由用户一方负责。与在托管 API 中完成处理的 Payment Cryptography 相比，区别不在于能否进行密钥派生，而在于自己承担到什么程度的划分。
令牌化与卡数据保护的实现模式
PCI DSS v4.0 要求在存储卡号（PAN）时通过加密或令牌化进行保护。在使用 Payment Cryptography 的令牌化的典型实现中，通过 EncryptData API 加密 PAN，并将密文作为令牌存储在 DynamoDB 中。在支付处理时，通过 DecryptData API 解密，并发送到支付网络。这种方式下，PAN 的明文会暂时存在于应用服务器的内存中，因此推荐利用 Lambda 的执行环境、将内存的存续时间降到最低的设计。加密算法可以选择 AES-256-CBC、AES-256-ECB、3DES-CBC 等，根据支付网络一方的要求分别使用。另外，EncryptData 支持的是使用对称密钥（TDES / AES）、非对称密钥（RSA）、基于 DUKPT 或 EMV 的派生密钥进行的加密。格式保留加密（FPE / FF1 / FF3）不在其中。明文长度也必须按 TDES 以 8 字节为单位、AES 以 16 字节为单位对齐，因此无法将 16 位的 PAN 输出为同样 16 位的数字串。如果希望将保持位数的替代值存储到现有的数据库结构中，必须另外实现保存令牌与密文对应关系的机制，或者组合使用专用的令牌化产品。在无法变更现有数据库位数限制的环境中，这里会成为迁移设计的分叉点。缩小 PCI DSS 合规范围的效果显著，可以大幅减少受审计的系统组件。
与 CloudHSM 的选用 - 通用加密与支付专用的边界
AWS 中存在 CloudHSM 和 Payment Cryptography 两种 HSM 服务。CloudHSM 是通用 HSM，可以通过 PKCS#11、JCE、OpenSSL 等标准接口执行任意加密操作。认证因 HSM 的代际而不同，当前的 hsm2m.medium 已取得 FIPS 140-3 Level 3 认证（证书 #4703），可以配置为 FIPS 模式的集群。旧一代 hsm1.medium 的 FIPS 140-2 Level 3 认证（证书 #4218）已于 2026 年 1 月 4 日转入 CMVP 的 historical list。官方文档中也推荐迁移到 hsm2m.medium。另一方面，Payment Cryptography 是取得了 PCI PTS HSM 认证的支付专用 HSM。它提供 PIN 块操作、DUKPT 密钥派生、MAC 计算等支付特有的 API。选择标准是明确的。如果主要目的是卡加密或 PIN 验证，就选择 Payment Cryptography；如果目的是 TLS 终止或代码签名等通用加密，则选择 CloudHSM。成本结构也存在差异。（截至 2026 年 8 月 / 弗吉尼亚北部 / 东京）CloudHSM 的计费单位不是集群，而是按每台 HSM 的时间计费。hsm2m.medium 在弗吉尼亚北部为每小时 1.60 美元，在东京为每小时 1.81 美元。按每月 730 小时换算，1 台配置约为 1,168 美元 / 约 1,321 美元，为可用性而推荐的 2 台配置约为 2,336 美元 / 约 2,642 美元。在集群运行期间，这些费用与加密的执行量无关，都会产生。与之相对，Payment Cryptography 是针对活跃密钥数和 API 请求数的按用量计费，每 10,000 次请求的单价分为从 0.10 美元到 2.00 美元的阶梯。每月 100 万次请求时，全部用量都落在第一个阶梯内，约为 200 美元，数量越大，每 10,000 次请求的单价越低。估算按官方价目表的数量阶梯进行。对于支付处理量少的服务商来说，没有仅因运行就会累积的固定费用，这一点是一大优势。同时使用两种服务、在支付加密与通用加密之间分离职责的配置也是实用的。
在生产环境中部署 Payment Cryptography 时的设计指南
在生产环境中部署时，首先确定密钥的导入策略。从现有的本地 HSM 迁移时，推荐使用 TR-34 协议。TR-34 是基于 RSA 的非对称密钥交换方式，实现密钥明文不会暴露的安全迁移。ImportKey API 原生支持 TR-34。在可用性方面，服务会在区域内自动冗余，但在多区域配置中，则在各区域分别导入密钥，并在应用层控制故障转移。在审计方面，所有 API 调用都会记录到 CloudTrail，便于满足 PCI DSS 要求 10。分阶段推进迁移是现实的做法。在测试环境中确认 PIN 块转换和 MAC 验证的准确性，经过并行运行后切换到生产环境，这样的流程是稳妥的。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。