1、安全启动概述：什么是安全启动、为什么需要安全启动、安全启动的信任链模型
1.1 什么是安全启动？
安全启动，说白了就是给设备加一道「门禁系统」。
你想想看，一台嵌入式设备上电后，CPU 要执行的第一段代码是什么？是 BootROM。然后 BootROM 去加载 Bootloader，Bootloader 再去加载内核，内核再挂载文件系统。这一连串的加载过程，如果中间任何一个环节被篡改了，设备就「叛变」了。
安全启动要做的，就是确保每一级加载的代码，都是「原厂签发」的，没有被恶意修改过。
我个人的理解是：安全启动不是防黑客的万能药，它解决的是「启动过程的完整性」问题。它保证设备只运行经过签名的、可信的代码。至于代码本身有没有漏洞，那是另一回事。
核心定义：安全启动（Secure Boot）是一种通过密码学验证机制，确保设备从硬件复位到操作系统启动的整个过程中，每一阶段执行的代码都经过数字签名验证，且未被篡改的技术方案。
1.2 为什么需要安全启动？
我在项目中遇到过一件印象很深的事。有个客户反馈说设备启动后行为异常，远程排查发现内核被替换成了恶意版本。后来一查，是攻击者通过物理接触，把 Flash 芯片拆下来重新烧录了。
你看，没有安全启动，攻击者只要拿到物理访问权限，就能为所欲为。具体来说，安全启动解决以下几个痛点：
- 防止恶意固件注入：攻击者通过物理接口（JTAG、UART）或漏洞，将篡改后的固件写入存储介质。
- 防止启动降级攻击：攻击者把设备回滚到有已知漏洞的旧版本固件，然后利用漏洞入侵。
- 保证供应链安全：设备在运输、仓储过程中，可能被中间人替换固件。安全启动能发现这种篡改。
- 满足合规要求：很多行业标准（如金融、医疗、车规）强制要求设备具备安全启动能力。
注意：安全启动并不能防御运行时的攻击。比如内核启动后，攻击者通过网络漏洞注入的恶意进程，安全启动管不了。它只管「启动那一刻」的代码完整性。
1.3 安全启动的信任链模型
信任链模型，是安全启动的「骨架」。它的核心思想是：从一个绝对可信的根开始，一级验证一级，层层传递信任。
为什么会这样设计？因为芯片内部无法存储无限大的公钥列表。所以业界通用的做法是：在芯片出厂时，烧录一个不可更改的「根公钥」到一次性可编程存储器（OTP）中。这个根公钥就是信任的起点。
典型的信任链模型如下：
- Root of Trust（信任根）：芯片内部的 BootROM，它固化在硅片上，不可修改。BootROM 中硬编码了根公钥的哈希值。
- 一级验证：BootROM 从 Flash 中读取 Bootloader（通常是 SPL 或 U-Boot SPL），用根公钥验证其数字签名。验证通过，才跳转执行。
- 二级验证：Bootloader 从 Flash 中读取主引导程序（如 U-Boot proper），用 Bootloader 内置的公钥验证其签名。
- 三级验证：主引导程序读取 Linux 内核镜像和设备树，用其内置的公钥验证签名。
- 四级验证：内核启动后，验证文件系统的 dm-verity 哈希树，确保根文件系统未被篡改。
嗯，这里要注意：每一级验证通过后，才会把执行权交给下一级。如果任何一级验证失败，设备会进入「恢复模式」或直接死机。
我的经验：在实际项目中，我建议把信任链画成一张流程图，贴在工位上。每次调试安全启动问题时，对照这张图，能快速定位是哪个环节出了问题。我曾经因为 BootROM 和 Bootloader 的公钥不匹配，折腾了整整两天，最后发现是 OTP 烧录时写错了位置。
1.4 信任链的密码学基础
信任链依赖非对称加密。简单说就是：
- 私钥：由设备厂商保管，用于对固件进行签名。私钥一旦泄露，整个产品线的安全就完了。
- 公钥：嵌入到设备中，用于验证签名。公钥是公开的，但必须保证其完整性。
签名验证的过程是这样的：
1. 厂商用私钥对固件镜像计算哈希值，然后加密生成签名。
2. 设备端用公钥解密签名，得到哈希值 H1。
3. 设备端对收到的固件镜像计算哈希值 H2。
4. 比较 H1 和 H2。如果一致，说明固件未被篡改。你可能会问：为什么不直接用对称加密？因为对称密钥一旦被提取出来，攻击者就能伪造任意固件。而非对称加密中，私钥不出厂，攻击者拿不到。
1.5 常见的信任链实现方案
| 方案名称 | 信任根位置 | 典型应用 | 特点 |
|---|---|---|---|
| U-Boot 安全启动 | BootROM + OTP | ARM 嵌入式 Linux | 开源、灵活，但配置复杂 |
| Android Verified Boot | Bootloader 中的 avb 公钥 | Android 手机 | 支持 dm-verity，用户可解锁 |
| Intel Boot Guard | CPU 内部 fused 密钥 | x86 平台 | 硬件级保护，不可绕过 |
| ARM TrustZone | 安全世界中的 BootROM | ARM Cortex-A 系列 | 与 TEE 结合，提供运行时安全 |
我个人习惯在项目初期就确定好采用哪种方案。不同方案的配置复杂度、密钥管理方式差异很大。比如 U-Boot 安全启动，你需要自己管理密钥生成、签名脚本、OTP 烧录流程，稍有不慎就会「变砖」。
1.6 信任链的局限性
说实话，信任链模型也不是万能的。我总结了几点：
- 信任根本身的安全：如果 BootROM 有漏洞（比如缓冲区溢出），攻击者可能绕过验证直接执行恶意代码。这种漏洞历史上出现过。
- 密钥管理风险：私钥泄露是灾难性的。我见过一个团队把签名私钥放在共享文件夹里，结果被离职员工带走了。
- 性能开销：每次启动都要做多次非对称签名验证，会延长启动时间。在工业设备上，这个延迟通常可以接受，但在消费电子中，用户可能抱怨开机慢。
- 调试困难：安全启动一旦开启，普通调试工具（如 JTAG）就无法工作了。你需要专门的调试密钥或签名工具。
避坑指南：我曾经在量产前一周发现，某个批次的芯片 OTP 烧录失败，导致所有设备无法启动安全验证。从那以后，我要求团队在硬件设计阶段就预留「调试跳线」，可以在不破坏安全策略的前提下，临时绕过验证进行故障排查。
1.7 小结
安全启动不是什么高深莫测的技术。它的本质就是「一级验一级」，从芯片内部的 BootROM 开始，逐级验证，直到操作系统完全启动。信任链模型是它的核心骨架，非对称加密是它的技术基石。
在后续的章节中，我会带你一步步实现一个完整的安全启动方案。从密钥生成、签名脚本编写，到 BootROM 配置、OTP 烧录，再到内核和文件系统的验证，每一步我都会结合项目中的实际踩坑经历来讲。
记住一句话：安全启动不是终点，而是整个设备安全体系的起点。
公众号:蓝海资料掘金营，微信deep3321