← 最新论文
💻 computer science

Signing Twice Is Forever: State-Management Discipline for Stateful Hash-Based Signatures Under Operational Faults

本文评估了在运行故障下有状态哈希签名(XMSS 和 LMS)的状态管理机制,证明了只有事务性声明策略能够防止灾难性的密钥重用,同时揭示了快照回滚保护需要外部单调锚点,且批量租约是在未修补的软件库中尽管存在显著性能惩罚的情况下,针对 LMS 唯一安全且低延迟的解决方案。

原作者: Arpan Sharma

发布于 2026-09-04
📖 1 分钟阅读☕ 轻松阅读

原作者: Arpan Sharma

原始论文采用 CC BY 4.0 许可(https://creativecommons.org/licenses/by/4.0/)。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性,请参阅原始论文。 阅读完整免责声明

在数字世界中,有些秘密极其珍贵,以至于它们不能被使用超过一次。想象一把只能开启一扇门的万能钥匙;一旦门被打开,钥匙必须被销毁。如果这把钥匙被使用了第二次,哪怕是无意之中,整个安全系统就会崩溃,任何观察者都能伪造自己的钥匙来打开任何门。对于一种特定类型的数字签名——有状态哈希签名(stateful hash-based signature)而言,这就是现实。这些工具是政府和安全专家正在转向的工具,因为他们正准备迎接一个由强大的量子计算机可能破解当今最常见加密方法的未来。与其他依赖复杂数学难题的数字签名不同,这些签名依赖于哈希函数(一种将数据转化为唯一指纹的过程)那简单且不可破解的特性。它们的唯一弱点不在于数学缺陷,而在于管理上的缺陷:如果系统忘记了刚刚打开了哪扇门,并尝试再次使用相同的钥匙,安全就会永远消失。

挑战在于如何在可能发生崩溃、重启或从备份恢复的计算机网络中追踪这种单次使用的钥匙。独立研究员 Arpan Sharma 的一项新研究深入调查了如何在不犯错的情况下管理这种追踪。该研究重点关注了两种已获批准的方法:XMSS 和 LMS,它们目前已被强制用于签署关键软件和固件。这项研究提出了一个实际问题:当计算机系统故障或重启时,哪些软件规则可以防止系统意外重复使用密钥?为了找到答案,研究人员构建了一个模拟签名服务,模拟了一个计算机共享数据库的真实环境。随后,他们让该系统经历了一系列严苛测试,包括突然终止计算机进程、同时运行多个系统副本,以及像真正的管理员在进行恢复操作时那样,将系统回滚到旧的备份快照。

结果显示,处理这些密钥的最常见方式存在危险的缺陷。许多系统使用一种简单的方法:读取当前的密钥编号,进行签名,然后将新的编号写回数据库。这看起来合乎逻辑,但研究表明,如果计算机在签名与保存之间的极短瞬间崩溃,或者两台计算机试图同时进行签名,系统很容易丢失追踪并重复使用密钥。在这些测试中,这种常见方法导致了在单次运行中重复使用了数十个甚至数百个密钥。研究人员发现,要保证针对崩溃和并发性的安全性,唯一的途径是使用“先声明”(claim-first)原则。在这种方法中,系统必须在执行任何签名操作之前,先在数据库中正式预留下一个密钥编号。这确保了即使计算机在预留后立即崩溃,该密钥也会被标记为已使用,从而使系统永远不会再次尝试使用它。

然而,安全是有代价的,研究揭示了两种签名方法之间令人惊讶的差异。对于其中一种方法 XMSS,管理密钥的安全方式几乎是免费的,即几乎不会给签名过程增加延迟。但对于另一种方法 LMS,情况则要复杂得多。在研究中所使用的软件库版本中,安全的方法速度极慢,以至于几乎无法使用。每次系统在重启后尝试签名时,都必须从头开始重建一个庞大的数字树结构,这使得单次操作耗时数百毫秒。研究人员向软件开发人员报告了这个问题,开发人员在较新版本的库中添加了一个修复程序。这个修复程序允许系统保存树结构的一部分,从而避免每次都重新构建。虽然这使得安全方法快了许多,但仍不足以达到实际应用的水平。

研究得出结论,对于 LMS 方法,既安全又快速的唯一途径是使用“批量租赁”(batched leasing)方法。系统不是一次预留一个密钥,而是同时预留十六个密钥作为一个块。系统会在内存中暂用这些密钥一段时间,然后再请求下一个块。这样可以将昂贵的树重建成本分摊到多次签名中,使过程在保持安全的同时,速度足以满足实际应用需求。研究还强调了一个没有任何软件技巧可以克服的根本限制:如果系统被回滚到旧的备份,任何将密钥计数器存储在该备份中的方法都会失败。备份将包含一个旧的密钥编号,系统会开始重复使用在备份时间与崩溃之间已经使用过的密钥。为了防止这种情况,研究人员发现,计数器必须保存在一个无法被回滚的外部设备中,例如专门的硬件安全模块(HSM)。这证实了对于这些特定的签名,硬件要求不仅仅是一个建议,而是一种结构性的必要。

这些发现为构建下一代安全软件的工程师提供了清晰的路线图。它们表明,仅仅依赖标准的数据库模式是不够的,必须遵循特定的、严谨的规则,以避免灾难性的安全失败。对于一种签名类型,解决方案是简单且廉价的。对于另一种,则需要特定的策略,即预留密钥块,并且至关重要的是,将主计数器保存在主数据库之外,以抵御备份和快照带来的必然失效。随着世界向着量子抗性安全迈进,这些操作细节将决定这些新系统是保持安全,还是在自身的重量下崩塌。

您所在领域的论文太多了?

获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。

试用 Digest →