发布日期：2026-09-02 浏览次数：
代码签名存在一个显著的长期风险，而大多数后量子计算 (PQC) 规划都低估了这一点：已签名的安装程序、固件镜像或更新包会在签名后流通数年甚至数十年，因此，今天应用的传统签名会在整个产品生命周期内暴露在风险之中，而不仅仅是在量子计算机出现之前。要规避这种风险，需要做好以下五件事：选择合适的算法、为每个签名添加时间戳以确保其在证书过期后仍然有效、确认您的硬件安全模块 (HSM) 和时间戳机构确实支持后量子计算操作、确保使用您签名的验证生态系统能够对其进行验证，以及在任何生产环境切换之前运行并行签名试点。。
签名软件和固件会流通数年甚至数十年，因此经典签名的风险窗口是该物品的整个生命周期，而不仅仅是量子计算机出现之前的时间。
RFC 3161 时间戳证明签名是在特定时间创建的，这使得即使签名证书本身过期，验证仍然可以继续成功。
大多数公共时间戳机构尚未发布后量子签名支持，而且大多数传统的 FIPS 140-2 HSM 缺乏原生 PQC 算法支持，这两个独立的准备情况差距都需要在试点项目被视为完全后量子之前进行检查。
部署生命周期超过十年的固件面临着一个独特的问题：部署后无法重新签名，因此在构建时应用的签名必须在设备的整个运行生命周期内保持可验证性。
并行签名试点项目，将经典签名和后量子签名应用于同一工件，使组织能够在不破坏尚未具备后量子能力的系统的验证的情况下，验证后量子工具。
揽阁信息提供的Thales Luna HSM已经在固件中支持ML-KEM、ML-DSA、SLH-DSA等 PQC算法。
大多数关于量子风险的讨论都集中在“先捕获后解密”的策略上，即攻击者今天捕获加密流量，待量子计算机出现后再进行解密。代码签名也存在一个相关但不同的风险：一旦具备密码学意义的量子计算机出现，攻击者如果能够伪造经典签名，就可以追溯性地生成恶意文件，这些恶意文件看起来与合法的、经过历史签名的软件难以区分。如果已签名的安装程序、固件镜像或更新包在流通多年，那么风险窗口并非量子计算机出现的那一刻，而是所有届时仍在使用的经典签名文件的整个剩余使用寿命。因此，代码签名迁移计划必须专门考虑文件的生命周期，而不仅仅是设定一个通用的迁移截止日期。
代码签名证书具有有效期，根据当前的证书颁发机构/浏览器论坛要求，通常为 460 天。如果没有时间戳，签名验证就依赖于将其与一个在验证时仍在有效期内的证书进行比对。一旦证书过期，就会出现问题，因为验证几年前签名的软件将无法成功。
RFC 3161 时间戳机构通过使用其自身保存在硬件安全模块 (HSM) 中的签名密钥，将签名的哈希值加密绑定到一个可信的、可独立验证的时间点，从而解决了这个问题。验证者在证书过期后检查带时间戳的签名时，会提出不同的问题：证书在时间戳证明签名创建之时是否有效，而不是证书现在是否有效。这就是为什么为每个生产代码签名操作添加时间戳被视为强制性做法，而不是可选的附加功能。
这是大多数后量子计算（PQC）代码签名方案所忽略的缺陷。时间戳令牌本身就是一个数字签名，由TSA自身的密钥生成，而该密钥必须具备后量子能力，时间戳本身才能抵御未来的密码分析。截至本指南发布之时，后量子时间戳支持仍在TSA生态系统中逐步发展，尚未普及，这意味着目前正在试用ML-DSA代码签名的组织可能会发现，其时间戳仍然是由传统的RSA或ECDSA TSA密钥签发的。
对于长期存在的工件而言，这种差距尤为重要。使用 ML-DSA 签名但时间戳仍使用传统密钥的软件工件存在一个薄弱环节：用于证明后量子签名创建时间的时间戳本身也容易受到后量子签名旨在避免的未来密码分析风险的影响。在将代码签名试点项目视为完全端到端的后量子签名之前，请务必确认您的 TSA 的具体后量子路线图和算法支持情况，并在您的服务提供商提供后量子时间戳功能后，重新为关键的长期工件添加时间戳。
时间戳授权机构的就绪只是基础设施问题的一半；存储实际签名密钥的硬件安全模块 (HSM) 是另一半，而 CA/浏览器论坛的要求规定，代码签名私钥必须存储在符合 FIPS 标准的硬件中，而不是软件中。大多数传统的 FIPS 140-2 认证 HSM 是在 NIST 最终确定 ML-DSA 和 SLH-DSA 标准之前制造的，因此缺乏对这两种标准的原生支持。运行旧版 HSM 固件的组织需要升级到支持后量子签名的 FIPS 140-3 固件，或者采用双栈方案：在过渡期间，在现有硬件上继续进行传统签名，而在更新或新采购的 HSM 上运行后量子签名。
在将生产签名流程部署到特定 HSM 型号和固件版本之前，请务必核实供应商实际发布的后量子计算 (PQC) 支持情况，而非仅参考产品路线图。虽然各大供应商都在推进支持 PQC 的 HSM 固件的 FIPS 140-3 认证，但实际发布的支持情况因型号和固件版本而异。“供应商宣布支持 PQC”与“我们部署的硬件已验证支持 PQC 固件”之间的差距，正是签名流程停滞不前的原因所在。
揽阁信息是Thales的重要合作伙伴，我们提供的 Luna HSM 在固件v7.9.0开始，就已经支持ML-KEM、ML-DSA、SLH-DSA等 PQC算法，目前已经有成功使用的客户案例。我们可以为您提供免费的POC测试环境、技术支持和指导、定制化解决方案，欢迎联系我们获取更多信息。
长期验证 (LTV) 通过在签名时或签名时附近嵌入撤销状态证据（例如 OCSP 响应或 CRL）以及时间戳，进一步扩展了签名的可验证性。可靠的时间来源和签名证书当时未被撤销的证明相结合，使得签名在较长时间内保持可验证性，在文档签名用例中，有时甚至长达二十年，而无需验证者联系可能在验证时已不存在的实时撤销服务。
对于验证要求特别长的工件，可以在第一个时间戳的信任锚点失效之前添加第二个时间戳，从而有效地将签名的可验证时间线进一步延后。这种分层方法，而非单一时间戳，才是真正持久有效的签名所依赖的。
固件存在软件更新通常不会遇到的长期签名问题：一旦部署到设备，固件通常无法重新签名或替换，尤其是在使用寿命长达数十年的嵌入式或工业硬件上。构建时应用的签名是该固件唯一拥有的签名，因此，签名算法的选择，以及其背后的时间戳和长期验证策略，都至关重要，其影响将持续到设备的整个运行生命周期，而不仅仅是其初始部署阶段。
这也是为什么像 LMS 和 XMSS 这样的基于哈希的签名方案以及 ML-DSA 在固件签名方面特别受欢迎的原因：它们的安全性依赖于哈希函数的特性，而不是更新的格假设，这种保守的选择对于无法重新签名的工件比对于可以在正常更新周期中重新发布的工件更为重要。
只有当验证系统能够真正验证签名时，签名才有用。而所有用于验证签名文件的操作系统、浏览器、安全工具和安装平台，都需要先识别后量子算法，才能正确验证签名文件。这确实是一个需要多年才能完成的生态系统同步挑战，而非一次性更新：如果一个组织今天开始使用 ML-DSA 进行签名，那么它生成的文件在任何尚未更新以识别该算法的验证系统上都无法通过验证。而这正是并行签名试点项目旨在管理的兼容性风险。
在正式上线之前，务必梳理好实际的验证生态系统，而不仅仅是签名环节：包括客户或内部用户实际运行的操作系统版本、安全工具和安装程序，以及其中哪些已经能够识别后量子签名。技术上准备就绪的签名流程并不等同于能够真正通过用户验证的部署。
在不影响生产环境验证的前提下，验证后量子代码签名工具的实用方法是对同一工件同时应用经典签名和后量子签名，即采用分离的双签名模式，而非单一的混合签名。已验证经典签名的系统可以继续正常运行；更新后可检查后量子签名的系统可以独立进行验证。这样，组织可以在生产环境中测试其 ML-DSA 签名基础设施、HSM 支持、时间戳和 CI/CD 集成，同时所有现有验证器都能像试点开始前一样正常工作。
在将任何 ML-DSA 签名试点项目视为完全抗量子攻击的端到端方案之前，请务必确认您的时间戳机构和 HSM 是否支持特定的后量子算法；签名、时间戳以及两者背后的硬件都必须是后量子的，才能真正保护工件。现在就对生产工件并行运行经典签名和后量子签名，而不是等待全面切换，以便在真实的生产条件下验证工具，实现零验证风险。对于部署后无法重新签名的固件和其他工件，请将签名算法和时间戳策略视为一项影响设备整个生命周期的决策，并据此权衡该决策。同时，请将您的验证生态系统与签名基础设施进行映射，因为即使技术上完整的签名流程，如果检查这些签名的系统没有跟上，仍然会在生产环境中失效。
保护长期有效的签名工件并非仅仅选择一个后量子算法那么简单。证明签名时间的时间戳、存储签名密钥的硬件安全模块 (HSM) 以及多年后进行验证的验证生态系统，都需要同时具备后量子就绪能力，因为其中任何一个环节的缺陷都会削弱算法选择所旨在提供的保护。明确确认时间序列安全协议 (TSA) 和 HSM 的就绪性、构建长期验证证据、将固件不可重新签名的约束作为首要设计输入，以及将验证生态系统与签名流程进行映射，这些才是决定今天应用的签名在二十年后是否仍然有效的真正关键所在。
为什么在后量子跃迁过程中时间戳变得更加重要？
时间戳可以证明签名是在特定的时间点创建的，这正是证明签名是在经典算法被弃用之前创建的所需的证据，从而保护签名免受量子计算机能够破解该算法后提出的追溯性伪造索赔。
如今，时间戳权威机构和硬件安全模块（HSM）是否已做好后量子时代的准备？
目前，两种生态系统对ML-DSA或SLH-DSA的支持仍在逐步形成，尚未全面普及。大多数传统的FIPS 140-2 HSM缺乏原生支持，大多数公共TSA也尚未发布后量子签名版本。在将试点项目视为完全后量子签名之前，请务必确认您的供应商已发布（而非已宣布）支持该签名。
为什么固件签名与用于 PQC 的常规软件签名有所不同？
固件，尤其是在嵌入式和工业硬件上，一旦部署，通常无法重新签名。构建时应用的签名必须在设备的整个使用寿命期间保持可验证性，而设备的使用寿命可能长达数十年，这使得初始算法和时间戳的决策比定期更新的软件更为重要。
什么是平行签约试点项目？
将经典签名和后量子签名分别应用于同一工件，作为两个独立且互不关联的签名。现有验证器继续验证经典签名，而更新后的验证器可以独立验证后量子签名，从而使组织能够在不影响现有验证的情况下测试后量子签名基础设施。
带有正确时间戳的签名可以保持多久的可验证性？
通过结合时间戳和嵌入式撤销状态证据进行长期验证，文档签名用例的验证期可长达二十年。在原始时间戳的信任锚点失效之前重新添加时间戳，可以进一步延长长期保存文件的验证期。
揽阁信息 · 值得您信赖的信息安全顾问！
沪公网安备31011202021337号 网站地图
友情链接： Thales官网 芯片产品网站 服务热线
