一、安全启动概述

1.1 什么是Bootloader

Bootloader，说白了就是芯片上电后第一个跑起来的程序。它的任务很简单——把操作系统从存储介质里搬出来，然后跳转过去执行。

我刚开始做嵌入式时，总觉得Bootloader就是个搬运工。直到有一次，我在一个IoT设备上发现，攻击者通过篡改Bootloader，直接绕过了所有安全校验。嗯，从那以后我再也不敢小看这个「搬运工」了。

Bootloader通常分为两个阶段：

• 第一阶段（BL1）：固化在ROM里，不可修改。负责初始化硬件，加载BL2。
• 第二阶段（BL2）：存放在Flash中，可升级。负责加载操作系统。

你想想看，如果BL1被篡改，整个系统就完了。所以BL1必须放在只读存储器里，这是安全启动的第一道防线。

1.2 为什么需要安全启动

安全启动不是锦上添花，而是刚需。我见过太多设备因为没做安全启动，被攻击者玩得团团转。

举个例子：你开发了一款智能门锁，用户通过手机App开锁。如果Bootloader没有安全校验，攻击者可以：

1. 拆开设备，用编程器读出Flash里的固件
2. 修改固件，植入后门
3. 把篡改后的固件写回去
4. 然后这个门锁就变成了攻击者的「提线木偶」

我曾经帮一家客户做安全审计，发现他们的设备连签名校验都没做。攻击者只需要一个USB转TTL工具，就能随意刷入任意固件。你说可怕不可怕？

安全启动的核心目标有三个：

目标	说明
完整性校验	确保固件没有被篡改
来源认证	确保固件来自可信的发布者
防回滚	防止攻击者降级到有漏洞的旧版本

1.3 安全启动的信任链模型

信任链模型，说白了就是「一级验一级」。从硬件根信任开始，逐级验证，直到操作系统。

我个人习惯把信任链比作「传家宝」的传承：

• 根信任：相当于传家宝的原始主人。通常是固化在芯片ROM里的公钥或哈希值。
• BL1验证BL2：主人把传家宝传给儿子，儿子要验证这是真货。
• BL2验证OS：儿子再传给孙子，同样要验证。

典型的信任链流程如下：

芯片上电 → ROM代码执行
    ↓
ROM验证BL1签名（使用硬件公钥）
    ↓
BL1验证BL2签名
    ↓
BL2验证OS内核签名
    ↓
OS启动完成

这里有个关键点：每一级只信任上一级的签名结果。如果某一级验证失败，系统必须停止启动。

1.4 常见攻击面分析

安全启动不是万能的。我总结了几个常见的攻击面，你在设计时一定要留意：

1.4.1 硬件攻击

• JTAG/SWD调试接口：攻击者通过调试接口直接读取内存，绕过Bootloader。
• 电压/时钟毛刺攻击：通过干扰电源或时钟，让芯片跳过安全校验。
• 探针攻击：用微探针直接读取芯片内部总线数据。

我记得有个项目，客户把JTAG接口留在了量产板上。结果攻击者用J-Link直接读出了固件，还修改了启动参数。嗯，从那以后我要求所有量产板必须熔断调试接口。

1.4.2 软件攻击

• 缓冲区溢出：在Bootloader的输入解析代码中植入恶意数据。
• 回滚攻击：刷入旧版本固件，利用已知漏洞。
• 签名绕过：利用签名验证逻辑的漏洞，比如只检查文件名不检查内容。

1.4.3 侧信道攻击

• 时序分析：通过测量签名验证的时间，推断密钥信息。
• 功耗分析：通过分析芯片的功耗曲线，提取密钥。

1.5 小结

安全启动是嵌入式安全的基石。它通过信任链模型，确保只有经过认证的固件才能运行。但要注意，攻击者不会只盯着一个点，他们会从硬件、软件、侧信道等多个维度发起攻击。

我个人建议，在设计安全启动时，要遵循「纵深防御」的原则：

1. 硬件层面：熔断调试接口，使用安全存储
2. 软件层面：严格签名校验，实现防回滚机制
3. 算法层面：使用抗侧信道攻击的实现

下一章，我会详细讲解签名校验的具体实现，包括RSA和ECDSA的对比、哈希算法的选择，以及我在实际项目中踩过的坑。咱们下章见。

---

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