1、启动校验概述：什么是启动校验、为什么需要启动校验、常见的攻击场景分析
1.1 什么是启动校验？
启动校验，说白了就是设备上电后，在运行主程序之前，先做一次「身份核查」。它要确认两件事：
- 当前要执行的固件，是不是我期望的那个版本？
- 这个固件有没有被人动过手脚？
我习惯把它比作机场安检。你想想看，乘客登机前得过安检门、查行李、核身份。启动校验就是固件的安检流程——没通过，就别想进到系统里跑起来。
具体到技术实现，启动校验通常发生在芯片的 BootROM 阶段。BootROM 是芯片出厂时固化的一段只读代码，它不可篡改，是整个信任链的「根」。它会先校验下一级 Bootloader 的签名或哈希值，通过后才把控制权交出去。这个过程一级传一级，形成一条完整的信任链。
核心概念：信任根（Root of Trust）
信任根是启动校验的起点。它必须是硬件层面不可修改的。常见的信任根包括：芯片内部的 BootROM、一次性可编程熔丝（eFuse）中存储的公钥哈希、或者专用的安全协处理器。
嗯，这里要注意：启动校验不是只做一次。现代嵌入式系统里，从 BootROM → SPL → U-Boot → Kernel → 文件系统，每一级都要校验。任何一级断了，整个安全体系就形同虚设。
1.2 为什么需要启动校验？
这个问题，我当年刚入行时也觉得「不就是跑个系统嘛，搞这么复杂干嘛」。直到有一次，我在一个 IoT 网关项目上栽了跟头——产品量产三个月后，客户反馈设备频繁变砖。查到最后发现，有人在生产线上用烧录器刷了未签名的固件，导致 OTA 升级时版本混乱，把 Flash 给写坏了。
从那以后，我深刻理解了启动校验的必要性。归纳起来，核心原因有三个：
- 防止恶意固件注入——攻击者通过物理接口（JTAG、UART）或远程漏洞，把篡改过的固件写进 Flash。没有校验，设备就会乖乖执行恶意代码。
- 保证固件来源可信——只有持有私钥的合法发布者才能生成有效签名。设备端用公钥验签，确保固件来自官方渠道。
- 检测固件完整性——固件在传输或存储过程中可能发生比特翻转（比如 NAND Flash 的位反转），哈希校验能及时发现这类损坏。
我的经验之谈：启动校验不是「要不要做」的问题，而是「做到什么程度」的问题。消费类产品可以只做 BootROM 到 Kernel 的签名校验，但金融终端、汽车 ECU 这类高安全场景，连文件系统的每个可执行文件都要校验。我建议你在产品定义阶段就明确安全等级，否则后期加校验，改 BootROM 的成本极高。
1.3 常见的攻击场景分析
搞安全的人常说「不知道敌人怎么打你，你就不知道怎么防」。我梳理了几个我在项目中和行业报告里见过的真实攻击场景，你看看有没有共鸣。
| 攻击场景 | 攻击手法 | 危害等级 | 典型防御 |
|---|---|---|---|
| 固件替换攻击 | 通过 UART/JTAG 直接写入未签名固件 | 高 | BootROM 强制验签 + eFuse 锁定调试接口 |
| 回滚攻击 | 刷入带已知漏洞的旧版本固件 | 中高 | 版本号防回滚计数器（eFuse/OTP） |
| 中间人攻击 | OTA 传输过程中篡改固件包 | 高 | TLS + 固件包签名校验 |
| BootROM 漏洞利用 | 利用 BootROM 缓冲区溢出执行任意代码 | 极高 | 芯片选型时关注 BootROM 安全审计报告 |
| 侧信道攻击 | 通过功耗/电磁分析提取签名私钥 | 中 | 使用恒定时间比较 + 密钥混淆 |
我重点说一个我亲身经历的场景——回滚攻击。那是一个智能门锁项目，固件有验签机制，但没做版本号防回滚。攻击者拿到了旧版本固件（那个版本有个蓝牙配对漏洞），通过 OTA 降级刷回去，然后利用漏洞远程开锁。你想想看，验签通过了，但安全还是被破了。这就是典型的「校验了来源，没校验版本」的教训。
避坑指南：我曾经在一个车机项目上犯过同样的错——只验签不验版本号。后来被安全评审打回来重做。记住：启动校验不仅要问「你是谁」，还要问「你是哪个版本」。版本号防回滚必须用硬件计数器（eFuse 或 OTP），不能只存在 Flash 里，因为 Flash 可以被擦除重写。
另一个常见的场景是BootROM 漏洞利用。说实话，这个比较棘手。BootROM 是芯片出厂固化的，你改不了。如果芯片厂商的 BootROM 有漏洞，整个设备的安全基础就塌了。我选芯片时，一定会看厂商是否公开了 BootROM 的安全审计报告。有些廉价芯片为了省成本，BootROM 写得极其粗糙，连基本的边界检查都没有。
嗯，总结一下这节的内容。启动校验不是可有可无的「加分项」，而是嵌入式设备安全的基石。它从信任根出发，通过一级一级的签名或哈希校验，构建一条不可中断的信任链。攻击者会从各个环节找突破口——替换固件、回滚版本、利用 BootROM 漏洞、甚至侧信道提取密钥。作为固件开发者，我们要做的就是在设计阶段就把这些攻击路径堵死。