1、签名迁移概述：什么是固件签名迁移、为什么需要迁移、迁移的常见场景
各位好，我是老周。做固件安全这么多年，签名迁移这事儿我碰过不下十次。每次听到有人说「换个签名不就是重新签一下吗」，我就知道，又有人要踩坑了。
今天咱们先聊聊最基础的问题——签名迁移到底是什么，为什么非做不可，以及你会在哪些场景下遇到它。
1.1 什么是固件签名迁移
说白了，固件签名迁移就是把一个已经签过名的固件，换成另一套签名体系重新签名。注意，不是改固件内容，是改签名本身。
我举个例子你就明白了。你有一把旧钥匙（旧签名密钥），用它锁了一个箱子（固件）。现在你想换成新钥匙（新签名密钥），但箱子里的东西不变。这个过程，就是签名迁移。
从技术角度看，它通常包含这几步：
- 验旧签——确认当前固件是合法的、没被篡改过
- 解签/剥离——去掉旧的签名信息（有时是去掉签名结构体，有时是清空签名区域）
- 重新计算——用新密钥和新算法重新生成签名
- 写入新签——把新签名写回固件镜像的指定位置
核心要点：签名迁移不是简单的「重新签名」，它涉及签名格式、密钥存储、校验流程的全面切换。迁移后的固件必须能在目标设备上通过新签名校验，同时保持功能不变。
1.2 为什么需要迁移
你可能会问：原来的签名用得好好的，干嘛要折腾？
嗯，我在项目里遇到过几种不得不迁的情况：
- 密钥泄露了——这是最紧急的。私钥一旦暴露，攻击者就能伪造固件。我记得有一次，客户的生产线私钥被内部人员带走了，整个产品线必须在一周内完成密钥更换。那叫一个焦头烂额。
- 算法过时了——比如从 SHA-1 升级到 SHA-256，或者从 RSA-1024 升级到 RSA-2048。SHA-1 的碰撞攻击在 2017 年就已经被证实可行，再用它签名，跟没签差不多。
- 合规要求——某些行业标准（比如汽车行业的 ISO 21434、医疗设备的 FDA 指南）会强制要求使用特定强度的签名算法。不升级，过不了认证。
- 供应链变更——换了芯片平台、换了安全元件供应商，原来的签名方案可能不兼容了。
注意：千万不要等到密钥泄露了才想起迁移。我见过太多团队把签名迁移当成「以后再说」的事，结果出事之后手忙脚乱，甚至导致产品召回。提前规划迁移路径，是固件安全的基本功。
1.3 迁移的常见场景
根据我的经验，签名迁移主要出现在以下三种场景里。咱们一个一个说。
场景一：更换 CA（证书颁发机构）
这个在物联网设备里特别常见。设备出厂时用的是厂商自签的根证书，后来要接入某个云平台，平台要求使用它的 CA 签发的证书。这时候就需要把设备固件里的签名证书链换掉。
举个例子：
- 旧方案：设备使用厂商根证书 → 中间证书 → 设备证书，三级链
- 新方案：云平台根证书 → 平台中间证书 → 设备证书，三级链
迁移时，不仅要换签名，还要保证设备能信任新的根证书。如果设备里写死了旧根证书的哈希值，那就麻烦了——得先通过 OTA 更新信任锚。
场景二：算法升级
这是最「技术」的一种迁移。比如从 RSA-2048 升级到 ECDSA P-256。为什么升级？
| 对比项 | RSA-2048 | ECDSA P-256 |
|---|---|---|
| 密钥长度 | 2048 位 | 256 位 |
| 签名大小 | 256 字节 | 64 字节 |
| 签名速度 | 较慢 | 快（约 3-5 倍） |
| 验签速度 | 较快 | 稍慢 |
| 安全强度 | 112 位 | 128 位 |
你看，ECDSA 的签名更小、更安全，对资源受限的嵌入式设备来说优势明显。但迁移时要注意：设备上的验签代码必须支持新算法。如果原来的验签逻辑是硬件加速的 RSA，换成 ECDSA 后可能得走软件实现，性能会受影响。
我的建议：算法升级时，最好在固件里同时保留新旧两套验签逻辑，做一个「双算法过渡期」。等所有设备都更新到新签名后，再通过另一个固件更新去掉旧逻辑。这样即使有设备没升级成功，也不会变砖。
场景三：密钥轮换
这个跟更换 CA 有点像，但更「轻量」。密钥轮换通常是在同一套签名体系下，定期更换签名密钥对。比如每年换一次签名私钥，但根证书和算法都不变。
为什么要轮换？
- 降低单密钥泄露的风险——就算某个密钥被攻破，也只影响一个批次的产品
- 满足合规要求——很多安全标准要求密钥有有效期
密钥轮换的迁移相对简单，因为签名格式和算法都不变，只需要更新设备上的公钥即可。但要注意：公钥的更新必须也是签名保护的，否则攻击者可以替换公钥来绕过签名校验。
1.4 知识体系总览
下面这张图把签名迁移的核心逻辑串起来了。你可以把它当作本章的「地图」。
这张图把签名迁移拆成了三个维度：是什么、为什么、怎么做。后面的章节会围绕这三个维度展开，但今天咱们先把「是什么」和「为什么」搞清楚。
1.5 一个真实的迁移案例
最后分享一个我踩过的坑。几年前我帮一家做智能门锁的客户做签名迁移。他们的产品用的是 RSA-1024 + SHA-1，因为安全审计没过，必须升级到 RSA-2048 + SHA-256。
听起来很简单对吧？换密钥、换算法、重新签名就行了。但问题出在固件分区上——他们的签名信息放在固件头部的一个固定区域，大小只有 128 字节。RSA-1024 的签名正好 128 字节，但 RSA-2048 的签名是 256 字节，放不下。
怎么办？我们最后不得不修改固件分区布局，把签名区域扩大到 512 字节，同时还要保证 OTA 更新时能兼容旧分区的设备。这个改动涉及 bootloader、固件打包工具、OTA 服务端三个模块的同步修改，前后花了两个月。
教训：签名迁移从来不只是「改个密钥」那么简单。签名大小、存储位置、校验流程、兼容性——每一个细节都可能成为瓶颈。提前做兼容性测试，比事后补救划算得多。
好了，这一章就到这里。记住一句话：签名迁移不是技术问题，是工程问题。技术方案可以抄，但工程落地必须结合你的产品实际。