1. 课程导论与背景：为什么需要固件验签？

一次真实的固件篡改攻击

2018年，我接手过一个智能网关的固件安全审计项目。客户说设备运行正常，但用户反馈频繁掉线、流量异常。我们拆机提取固件，用 binwalk 解包后，发现了一个奇怪的现象——固件里多了一个 /usr/sbin/sshd 的副本，而且启动脚本被改过。

说白了，攻击者通过中间人劫持了 OTA 升级通道。他们把篡改后的固件推给了设备。这个固件里植入了后门，攻击者可以远程 SSH 登录，控制整个网关。更可怕的是，设备本身没有任何校验机制——它只管下载、烧写、重启。

嗯，那次之后我养成了一个习惯：只要涉及固件升级，第一件事就是问“验签做了吗？”

固件篡改攻击的常见路径

你想想看，攻击者想篡改固件，通常走哪几条路？我总结了一下，主要有三种：

• OTA 通道劫持：攻击者伪造升级服务器，或者篡改传输中的固件包。设备不验签，直接烧写。
• 本地物理攻击：通过 UART、JTAG 或 SPI Flash 编程器直接读取/写入 Flash。我见过有人在产线上用夹子夹住 Flash 引脚，几秒钟就刷进去了。
• 供应链污染：在固件编译或打包阶段被植入恶意代码。这个最难防，因为源头就脏了。

这三种路径，只要设备有固件验签机制，攻击者基本就废了。为什么？因为验签的本质是信任链——只有持有私钥的人才能生成合法签名，而设备只认公钥。

固件验签的核心逻辑

固件验签说白了就是两件事：签名和验证。

• 签名（Sign）：固件发布方用私钥对固件镜像计算哈希，然后对哈希值做非对称加密，生成签名。签名和固件一起发布。
• 验证（Verify）：设备拿到固件后，用公钥解密签名得到哈希值 A，再自己计算固件的哈希值 B。如果 A == B，说明固件没被改过，且确实是私钥持有者签发的。

我习惯把这个过程画成一张图，方便团队理解：

没有验签的后果

我列一个表格，对比一下有验签和没验签的区别：

场景	无验签	有验签
OTA 升级被劫持	恶意固件直接烧写	签名验证失败，拒绝升级
物理 Flash 读取后篡改	攻击者可以任意修改	篡改后签名不匹配，设备无法启动
供应链投毒	恶意代码进入生产环境	签名链断裂，被拦截
固件逆向分析	攻击者可以随意解包、修改、重打包	重打包后签名无效，设备不认

你看，有没有验签，差距是本质性的。没有验签，你的设备就是裸奔。有验签，至少攻击者需要先搞定私钥——那难度就完全不一样了。

固件验签的工程化挑战

不过，验签这件事说起来简单，落地起来坑不少。我这些年踩过的坑，随便列几个：

• 密钥管理：私钥放哪儿？服务器上？HSM 里？还是直接硬编码在代码里？我见过有人把私钥放在 Git 仓库里——嗯，那基本等于公开了。
• 公钥存储：公钥烧死在 Flash 里，还是放在 BootROM 里？如果公钥能被篡改，验签就形同虚设。
• 验签时机：是在 Bootloader 阶段验？还是在内核启动后验？不同阶段有不同的安全等级和性能开销。
• 回滚攻击：攻击者不篡改固件，而是让你升级一个旧版本——旧版本可能有已知漏洞。验签本身不防回滚，需要额外机制。

课程目标与学习路径

这门课的目标很明确：让你能独立设计并落地一套固件验签方案。不是纸上谈兵，而是真正能在产品里跑起来。

我们会从这几个方面展开：

• 密码学基础：哈希、非对称加密、数字签名——够用就行，不搞数学推导。
• 签名方案设计：单级签名 vs 多级签名、镜像格式设计、签名域定义。
• 密钥生命周期管理：生成、分发、存储、轮换、销毁——每个环节都有坑。
• Bootloader 验签实现：以 U-Boot 为例，手写验签代码。
• 安全启动链：从 BootROM 到 OS，逐级验证。
• OTA 升级中的验签：断点续传、增量升级、回滚保护。
• 测试与攻击模拟：怎么验证你的验签方案是安全的？

我个人习惯把固件验签看作一个系统工程——不是加几行代码就完事了。它涉及硬件、软件、流程、管理。这门课会把这些串起来。