发布日期：2026-09-16 浏览次数：
金融服务业面临着独特的支付量子化（PQC）迁移难题：承载支付指令的消息格式并非为后量子化签名规模而设计。ISO 8583 作为目前仍是线下交易交换核心标准的协议，其固定长度字段难以容纳 2.4 至 4.6 KB 的 ML-DSA 签名；而 SWIFT MT 消息的长度上限为 2048 字节，如此紧凑使得紧凑型签名方案成为一种真正的架构限制，而非可选项。此外，支付硬件安全模块（Payment HSM）系统还需要满足 PCI 特定验证、银行间 API、客户身份验证以及多年保存的交易存档等要求，因此，金融服务业的迁移规划必须涵盖比几乎任何其他行业都更加多样化的基础设施类别。本指南将梳理这些类别及其具体需求。
大多数支付质量控制指南将“更新TLS和证书”视为全部工作。金融服务行业除了面临这个问题外，还存在一系列其他行业特有的支付问题：例如，消息格式对大小有严格限制、硬件安全模块（HSM）的认证程序独立于通用FIPS验证程序，以及银行间消息网络迁移时间表还取决于每个交易对手方的时间表。
ISO 8583 的固定长度消息字段并非为后量子签名大小而设计，这促使仍在使用 ISO 8583 的机构加快向更具可扩展性的 ISO 20022 格式迁移。
SWIFT MT 消息的上限为 2048 字节，这一限制使得紧凑的签名方案比 ML-DSA 的较大签名方案更适合代理银行业务。
支付 HSM 需要 PCI 特定验证，这与通用的 FIPS 140-3 认证不同，而且并非所有支付 HSM 都能仅通过固件实现后量子时代支持；有些需要更换硬件。
客户身份验证、交易存档和第三方支付处理商依赖项各自有自己的迁移时间表，与支付轨道和 HSM 问题不同。
金融机构的迁移只有与其代理银行和支付处理机构的迁移一样彻底，因为交易一方的 PQC 保护并不能保护整个交易过程。
这是大多数后量子计算 (PQC) 规划完全忽略的限制，因为它并未出现在通用指南中。ISO 8583 是目前大多数刷卡交易和 ATM 交易交换所依赖的消息标准，它使用固定长度和有限长度的可变字段，这些字段是根据传统的签名大小设计的。后量子签名无法适应这种结构，除非对消息格式本身进行重大修改，而不仅仅是更改配置。对于仍然使用 ISO 8583 进行核心交换的机构而言，迁移到更具扩展性的 ISO 20022 格式应被视为后量子计算就绪的先决条件，而不是一个独立且不相关的现代化项目。
通过 SWIFT MT 报文进行的代理银行业务流量存在一个硬性限制：报文大小上限为 2048 字节。这一上限使得签名大小成为依赖 SWIFT 的机构选择算法的首要标准，而这在其他大多数行业中并非如此。一旦这些紧凑型签名方案最终确定并得到验证，它们便会优先选择更紧凑的签名方案，而非像 ML-DSA-87 这样的大型方案。这是底层协议而非机构偏好驱动算法选择的最典型案例之一。
支付型硬件安全模块 (HSM) 负责处理 PIN 码的生成和验证、ATM 和 POS 机之间的 PIN 码块转换、交易处理期间的密码验证以及支付凭证的颁发。它们的验证流程是针对特定支付领域的，与通用的 FIPS 140-3 认证流程截然不同。这种区别对支付质量控制 (PQC) 的规划至关重要：同一支付型 HSM 供应商的通用加密模块可能在一个时间节点内完成 FIPS 140-3 的后量子验证，而同一硬件的特定支付验证流程则完全按照另一个时间表进行。
并非所有已部署的支付型硬件安全模块 (HSM) 都能通过固件更新实现后量子计算 (PQC) 功能。某些型号需要更换硬件，这意味着整个系统面临的问题不是“我们的 HSM 供应商何时支持 PQC”，而是“我们系统中哪些特定型号可以升级，哪些型号需要立即进行更新换代并纳入预算”。由于这是金融服务 PQC 项目中周期较长的环节之一，因此应尽早与 HSM 供应商沟通，了解各型号的升级路径、认证时间表以及单台设备的更换成本。
现代银行间连接越来越多地通过 API 而非传统的报文格式进行，这些 API 也继承了揽阁信息之前提到的涵盖 TLS 和证书迁移问题。金融服务领域的独特之处在于交易路径中通常存在众多独立的第三方依赖项：支付处理机构、卡组织、代理银行和金融科技集成合作伙伴都需要作为独立的迁移依赖项进行跟踪，因为完全迁移的机构与仅支持传统协议的交易对手进行交易时，该笔交易只能获得传统协议级别的保护。
面向客户的身份验证、移动银行、刷卡加密、数字钱包配置等，其迁移路径独立于后端支付基础设施，并且通常取决于设备和发卡机构的路线图，而这些路线图不受机构的直接控制。交易档案呈现出一种“先收集后解密”的风险，类似于我们在PQC内容中其他部分讨论的医疗保健和法律数据保留案例：为满足监管期限（可能长达数年甚至数十年）而保留的财务记录意味着，今天使用传统算法加密或签名的数据存在着真正的未来风险窗口，这与实时交易基础设施的问题截然不同，并且是对其的补充。
如果您的核心交换系统仍然基于 ISO 8583 标准，请将 ISO 8583 依赖性视为现代化改造的先决条件，而非并行项目。由于硬件更换周期是金融服务 PQC 流程中最长的环节之一，因此请立即与支付 HSM 供应商接洽，制定针对特定型号的升级方案。将代理银行和支付处理商的迁移状态作为您自身计划中的一项明确依赖项进行跟踪，而非想当然，并根据实际的监管保留期限来确定交易存档重新保护的优先级，而不是对所有存储的记录一视同仁。
虽然目前揽阁信息提供的payShield 10K HSM还不支持PQC，但其作为全球市占率达到80%+的地位，必将伴随金融行业的发展，率先满足行业需求。如果想了解更多关于payShield 10K HSM的信息，请联系我们。
金融服务业在支付质量控制（PQC）迁移方面并没有比其他行业拥有更长的过渡期；相反，它需要在相同的时间范围内涵盖更广泛的基础设施类别，其中一些类别，例如 ISO 8583 的消息大小限制、支付专用硬件安全模块（HSM）验证以及 SWIFT 的字节限制，在其他行业根本不存在。将每个类别视为独立的跟踪工作流程，并考虑其各自的供应商依赖关系和交付周期，而不是将其视为一个单一的全机构范围的 PQC 项目，才是确保金融机构按计划完成迁移的关键。
为什么 ISO 8583 消息不能直接携带后量子签名？
ISO 8583 使用固定长度和有限长度的可变字段，其大小与经典签名尺寸相符。后量子签名比经典签名大数倍，如果不大幅修改消息格式本身，就无法容纳。因此，建议仍在使用 ISO 8583 的机构加快迁移到更具扩展性的 ISO 20022 格式。
为什么SWIFT的消息大小限制会影响算法选择？
SWIFT MT 消息的上限为 2,048 字节。这一上限使得原始签名大小成为代理银行业务流量的一项约束条件，因此，对于这种特定的用例，一旦这些紧凑型后量子签名方案最终确定并得到验证，则更倾向于使用比 ML-DSA-87 等更大的方案更紧凑的方案。
所有支付型 HSM 都可以通过固件更新获得后量子时代支持吗？
不。部分支付型 HSM 可以通过固件升级；而其他型号则需要更换硬件。请直接与您的 HSM 供应商确认具体的升级路径、认证时间表以及您系统中每种型号的成本，不要想当然地认为所有型号都可以通过固件升级。
如果交易对手方尚未迁移，我方机构的 PQC 迁移能否保护交易？
不，并非完全如此。交易的安全性取决于交换中较弱的一方。您应该将代理银行、支付处理机构和卡组织网络的迁移状态作为一项明确的依赖项，并将其纳入您自己的程序中，而不是想当然地认为仅靠您自身的迁移就能确保每次交易的安全。
支付型 HSM 的验证方式与通用型 HSM 的验证方式相同吗？
不同。支付型硬件安全模块 (HSM) 通常除了通用的 FIPS 140-3 认证之外，还需要进行 PCI 特定验证，并且验证流程与通用认证的时间表不同。在将任何支付型 HSM 视为符合量子标准后的要求之前，请务必确认其所有验证流程。
揽阁信息 · 值得您信赖的信息安全顾问！
沪公网安备31011202021337号 网站地图
友情链接： Thales官网 芯片产品网站 服务热线
