第2章固件签名验证流程分析

第1章：固件签名验证流程分析

大家好，我是你们的嵌入式安全讲师。今天咱们聊聊固件签名验证的完整流程。说实话，这个主题我讲了不下几十次，但每次都有新感悟。为什么？因为攻击者也在进化，他们的绕过手法越来越刁钻。

先问大家一个问题：你手里的设备，从按下电源键到系统跑起来，中间到底发生了什么？很多人觉得就是「上电→加载→运行」三步走。但如果你做过安全审计，就会知道——每一步都可能被劫持。

BootROM，说白了就是芯片出厂时固化在ROM里的一段代码。它不可修改，是信任链的起点。我习惯把它叫做「硬件的第一口呼吸」。

流程大致是这样的：

嗯，这里要注意——BootROM本身不验证任何东西。它只是机械地执行。真正的安全验证，发生在它把控制权交出去之前的那一刻。

关键点：BootROM是信任锚点。如果它被篡改，整个安全链就崩塌了。好在它是只读的，物理上改不了。但攻击者会盯着它加载的下一个镜像。

安全启动链，我更喜欢叫它「信任传递游戏」。每一级都验证下一级的签名，环环相扣。一旦某级验证失败，系统就拒绝启动。

典型的链条长这样：

BootROM → SPL → U-Boot → Kernel → 文件系统
   ↓         ↓        ↓         ↓
  验证      验证     验证      验证
  公钥      公钥     公钥      公钥

我在项目中遇到过一种情况：某厂商只验证了U-Boot，却跳过了SPL的签名检查。结果攻击者直接替换SPL，加载了一个恶意U-Boot。你说这安全链还叫链吗？叫「筛子」更合适。

个人经验：检查安全启动链时，我建议你重点关注「跳级验证」和「回退路径」。很多设备为了兼容旧固件，会保留一个不验证签名的回退模式——这往往是最大的后门。

签名验证不是随时都在跑的。它只在特定「触发点」被激活。搞清楚这些触发点，你就知道该从哪里下手。

常见的触发点有：

你想想看，如果攻击者能绕过某个触发点，比如让BootROM跳过SPL验证直接加载——那后面的所有验证都形同虚设。我曾经在某个IoT设备上就发现过这种漏洞：它的BootROM在检测到特定GPIO电平后，会跳过签名验证。嗯，这设计思路真是让人哭笑不得。

公钥放哪？这是个大学问。放Flash里？攻击者可以改。放RAM里？断电就没了。所以硬件厂商想出了两个方案：OTP和eFuse。

OTP（One-Time Programmable）：一次性可编程存储器。出厂时烧录公钥，之后只能读不能写。我见过有些设备用OTP存了4组公钥，支持多厂商签名——这其实是个安全隐患，因为只要有一组私钥泄露，整个安全链就破了。

eFuse（电子熔丝）：通过熔断电路来存储数据。比OTP更灵活，可以逐位编程。但一旦熔断，不可恢复。我记得有个项目，工程师不小心把调试接口的eFuse熔断了，结果芯片变砖——那场面，真是欲哭无泪。

避坑指南：我曾经在审计一款路由器固件时发现，它的公钥虽然存在eFuse里，但BootROM竟然还保留了一个「测试模式」——从Flash读取公钥。攻击者只需要修改Flash中的公钥，就能用自己的私钥签名固件。所以，检查公钥存储时，一定要确认没有「备用路径」或「回退机制」。

下面我用一张SVG图来总结整个签名验证流程。这张图我画了很多遍，每次讲课时都会微调。它清晰地展示了从BootROM到文件系统的信任传递关系。

这张图里，我特意标出了公钥存储的位置和攻击点。你看，从BootROM到文件系统，每一级都有验证。但攻击者往往不会正面硬刚——他们会找那些「跳过验证」的旁路。

核心总结：固件签名验证的本质是「信任链传递」。公钥存储在OTP/eFuse中，每一级Bootloader验证下一级的签名。攻击者绕过验证的常见手法包括：篡改公钥、跳过验证触发点、利用回退模式。理解这些，你才能设计出真正安全的启动链。

好了，这一章的内容就到这里。记住我强调的：信任链的强度，取决于最弱的那一环。下一章我们会深入分析具体的签名算法和实现细节——到时候我会带大家看一些真实的绕过案例。

公众号:蓝海资料掘金营，微信deep3321