1. 安全启动概述：IoT设备的第一道防线

大家好，我是你们这门课的老朋友。今天咱们聊聊IoT安全启动——说白了，就是设备上电后，怎么确保它跑的是你写的代码，而不是别人塞进去的恶意程序。

我做了十几年嵌入式安全，见过太多设备“裸奔”上线的案例。有一次，客户说他们的智能网关被黑了，我远程一看，好家伙，启动时连签名校验都没有，攻击者直接替换了根文件系统。从那以后，我养成了一个习惯：任何IoT设备，安全启动都是第一优先级。

什么是IoT安全启动？

安全启动，英文叫Secure Boot。它不是某个具体的算法，而是一套从芯片复位开始的信任链机制。

你想想看，设备上电后，CPU执行的第一段代码是谁的？通常是ROM里的BootROM。这段代码是硬件固化的，改不了。BootROM会去加载下一级Bootloader，然后Bootloader加载内核，内核再挂载文件系统。每一级都验证下一级的签名，环环相扣。

我习惯把这个过程叫做“信任链传递”。起点是芯片出厂时烧录的根公钥，终点是整个系统启动完成。中间任何一环断了，系统就拒绝启动。

为什么需要安全启动？

这个问题，我每次给客户做方案时都会被问到。说白了，没有安全启动的IoT设备，就像没锁门的房子。

攻击者可以：

• 替换固件：把原厂固件换成带后门的版本，窃取数据或控制设备。
• 降级攻击：刷回有已知漏洞的旧版本，然后利用漏洞提权。
• 持久化驻留：在Bootloader里植入代码，每次启动都加载恶意模块。

我记得有个智能摄像头项目，客户说“我们设备在内网，不怕”。结果呢？攻击者通过Wi-Fi漏洞进了内网，直接给摄像头刷了恶意固件，变成了僵尸网络的一员。嗯，这就是典型的“内网迷信”。

安全启动的核心目标

安全启动要解决三个问题：完整性、真实性、抗回滚。我一个个说。

1. 完整性

完整性，就是确保代码在存储或传输过程中没有被篡改。哪怕只改了一个比特，校验就会失败。

实现方式很简单：对固件做哈希计算，比如SHA-256。启动时重新计算哈希，跟存储的参考值比对。不一致，就说明被动了手脚。

我在项目中遇到过一种情况：Flash存储器的某个位因为老化发生了翻转，导致哈希校验失败。嗯，这其实是硬件故障，不是攻击。但安全启动不会区分——它只认结果。所以，设计时一定要考虑容错机制，比如ECC或者冗余存储。

2. 真实性

完整性只能防篡改，不能防伪造。攻击者可以自己写一段代码，算好哈希，替换掉原固件。完整性校验照样能过，因为哈希是自己算的。

真实性靠的是数字签名。用私钥对固件哈希签名，公钥放在芯片里验证。只有持有私钥的人才能生成有效签名。私钥掌握在厂商手里，攻击者拿不到。

我建议你在选型时，优先选择支持硬件密钥存储的芯片，比如eFuse或OTP。软件存储密钥容易被提取，我见过太多因为密钥泄露导致整个产品线沦陷的案例。

3. 抗回滚

抗回滚，也叫版本回滚防护。攻击者可能不篡改固件，而是刷回一个有已知漏洞的旧版本。比如，新版本修复了缓冲区溢出，旧版本没有。攻击者刷回旧版本，然后利用那个漏洞提权。

实现方式：在固件头里加入版本号，安全启动在验证签名后，还会检查版本号是否大于等于当前版本。如果版本号更低，就拒绝启动。

这里有个细节：版本号本身也要被签名保护，否则攻击者可以伪造版本号。我习惯把版本号放在签名数据里，跟哈希一起签名。

核心目标	解决的问题	实现手段	常见失败案例
完整性	固件被篡改	哈希校验（SHA-256等）	Flash位翻转导致校验失败
真实性	固件被伪造	数字签名（RSA/ECDSA）	公钥存储在可写区域被替换
抗回滚	降级到有漏洞的旧版本	版本号检查 + 签名保护	版本号未签名，被攻击者伪造

安全启动的信任链模型

说了这么多，咱们用一张图把整个流程串起来。下面是我手绘的信任链流程图，你仔细看看。

这张图展示了典型的四阶段信任链。从BootROM开始，每一级都验证下一级的签名和完整性。注意看，验证框里我特意加了“版本号”检查，这就是抗回滚的实现点。

我个人习惯在Bootloader阶段做最严格的检查，因为它是软件攻击的第一道门槛。一旦Bootloader被攻破，后面的内核和文件系统再安全也没用。

小结一下

安全启动不是什么黑科技，它就是一套工程化的信任机制。三个核心目标：完整性保证代码没被改过，真实性保证代码是官方发布的，抗回滚保证代码是最新版本。