固件中的密码敏捷性：设计能够更换密码算法的设备

每一种密码算法终将退役。MD5 如此，SHA-1 也是如此。RSA 和椭圆曲线密码如今也已有公开的弃用路线。

对于 Web 应用来说，淘汰一个算法是一个迁移项目；对于现场运行的设备来说，这可能意味着召回。

密码敏捷性是指在不重新设计系统的情况下更换系统所用密码算法的能力。听起来像是一个库的功能，但在嵌入式产品中，它是一项架构决策，而且很早就要做出。

敏捷性通常在哪里失效

根据我的经验，设备无法更换密码算法，很少是因为算法本身，而是因为其他地方的某个假设。

• 引导程序 用一个固定算法和一个固定公钥验证固件，并写死在只读存储器中。
• 分区布局 只为今天的签名预留了刚好够用的空间，多一个字节都没有。
• 更新协议 的消息格式无法容纳更大的签名或第二个签名。
• 设备身份 是由一条无法重新签名的证书链签发的证书。
• 密钥 存放在只支持其所属年代算法的安全元件中。

每一个选择在当时都是合理的。但它们叠加在一起，就把一次密码升级变成了一次硬件更换。

设计原则

这是我希望每一款新联网产品都遵循的原则。它们都不要求你今天就选定后量子算法。

1. 把信任根与算法分开。 启动链中不可更改的部分应尽可能小，并能用不止一种方案验证下一阶段，或把控制权交给可更新的阶段。

2. 预留空间。 为比今天大数倍的签名和密钥预留闪存、RAM 和消息长度。后量子签名以千字节计，而不是字节。

3. 为一切承载密码的内容标注版本。 固件镜像、清单文件、证书和协议消息都应声明所使用的算法，让新旧方案能在过渡期共存。

4. 为双重签名做准备。 迁移期间，一次更新可能需要同时用新旧两种方案签名，以便现场的每台设备都能验证。请把清单文件设计得能够支持这一点。

5. 让密钥可替换。 制定一套有文档、经过测试的流程来轮换签名密钥和信任根，包括如何处理离线数月的设备。

6. 了解依赖关系。 如果你不知道哪个供应商的哪个组件实现了哪项密码功能，就不可能具备敏捷性。SBOM 有帮助；一张密码关系图帮助更大。

组织层面

一台设备在技术上可能很敏捷，却依然无法推进，因为没人知道该由谁来决定。

更换签名算法会涉及硬件、固件、更新后台、生产、证书管理、客户支持，有时还有认证。每个团队都掌握部分信息。如果各部分之间的依赖关系不可见，每次迁移都要先花几周时间做“考古”。

这正是我们在 Shorium 致力解决的问题：对联网产品内部的密码依赖关系进行建模，让团队在做出改变之前就能看到它会影响什么。我在《我为什么要做 Shorium》中解释了 Trust Twin 的理念。

一个简单的测试

这是一个我觉得很有用的测试。问问你的团队：

“如果我们必须更换仍在支持的最老产品的固件签名算法，我们要改什么，谁来改，需要多长时间？”

如果答案是一份计划，说明你具备一定的敏捷性；如果答案是沉默，你就知道该从哪里开始了。

监管也在朝同一方向发展。《网络韧性法案》要求产品在整个支持期内保持安全，NIST 计划在 2030 年后弃用今天的公钥算法。现在设计的设备将经历这场变化，它们应该为此而构建。