1. 课程导入

Secure Boot（安全启动）并不是一个“打开开关就结束”的功能，而是一条从芯片出厂、密钥注入、镜像签名、烧录量产到现场故障定位的完整工程链路。很多团队在样机阶段能顺利启动，却在量产阶段遇到签名校验失败、密钥版本不匹配、熔丝烧错、回滚保护触发、日志无法读取等问题。本课程的目标，是把 Secure Boot 从“概念理解”推进到“可量产、可验证、可排障”的工程能力。

一、学习目标：从“知道”到“能做”

本课程不满足于解释“什么是信任链”，而是要求你能够完成以下具体任务：

• 理解信任根（RoT）、一级引导、二级引导与操作系统镜像之间的校验关系；
• 掌握密钥生成、签名、验签、密钥版本与回滚保护的基本配置方法；
• 能够根据芯片手册配置熔丝、OTP、安全启动使能位与调试口策略；
• 能够编写量产签名脚本，并对固件包进行批量签名与校验；
• 能够通过串口日志、启动阶段码、校验错误码定位启动失败点；
• 能够区分“配置错误”“密钥错误”“镜像错误”“硬件熔丝错误”四类问题。

这些目标对应的是量产工程师的真实工作内容：不是单次启动成功，而是成千上万台设备在产线、售后、OTA 升级中保持一致的安全状态。

二、核心价值：为什么量产阶段必须重视 Secure Boot

Secure Boot 的核心价值体现在三个层面。第一是安全价值：防止未授权固件运行，阻止恶意刷机、固件篡改和回滚攻击。第二是商业价值：保护 IP、License、算法和品牌生态，避免设备被第三方固件“劫持”。第三是工程价值：通过标准化的签名、烧录、校验流程，降低产线误操作和售后返修成本。

但量产阶段的风险也恰恰集中在这里。样机阶段可以手动烧录、手动签名、手动改配置；量产阶段必须自动化、可追溯、可复现。一旦密钥管理混乱、签名脚本版本不一致、熔丝配置错误，就会导致整批设备无法启动或安全等级下降。因此，本课程强调“配置即代码、签名即流程、调试即证据”。

三、整体知识框架：四层结构

为了便于理解，我们把 Secure Boot 量产配置与调试划分为四层：信任根层、镜像签名层、量产烧录层、调试排障层。下图展示了这四层之间的依赖关系与关键对象。

四层之间不是孤立知识点，而是逐层依赖：信任根决定设备是否“认”你的密钥；镜像签名决定固件是否“合法”；量产烧录决定每台设备是否“一致”；调试排障决定问题是否“可收敛”。任何一层缺失，都会在量产阶段放大为批量问题。

四、方法流程：一条可复用的量产配置主线

下面给出一条典型的 Secure Boot 量产配置主线，后续章节会逐项展开。你可以先把它当作全局地图：

1. 密钥规划：确定根密钥、签名密钥、版本号、轮换策略与保管方式；
2. 信任根固化：将公钥哈希写入熔丝或 OTP，并确认不可逆操作前的验证；
3. 镜像签名：对 bootloader、kernel、rootfs 等逐级签名，附加签名头和版本信息；
4. 烧录配置：配置分区表、安全启动使能位、调试口策略和启动顺序；
5. 产线校验：烧录后读取校验结果，记录设备序列号、固件版本和签名状态；
6. 异常处理：根据启动阶段码和错误码定位失败点，形成故障树和回归用例。

在实操中，建议把签名和烧录参数写成配置文件，而不是散落在脚本里。例如：

# secure_boot_config.yaml
root_key: keys/root_rsa4096.pem
sign_key: keys/fw_sign_ecdsa.pem
key_version: 3
rollback_index: 7
hash_algo: sha256
sign_algo: ecdsa-p256
fuse_profile: otp_secure_boot_v2
debug_port: disabled
image_list:
  - bl2.bin
  - bl31.bin
  - u-boot.bin
  - kernel.itb
  - rootfs.squashfs

这样做的好处是：签名结果可复现，产线工具可读取同一份配置，调试时也能快速确认“当前设备到底用了哪一版密钥和哪个版本号”。

五、案例与场景：一次典型的量产启动失败

某设备在样机阶段启动正常，量产烧录后约 3% 的设备卡在 BL2 阶段。串口日志显示：

[BL2] Secure boot enabled
[BL2] Verify image: bl31.bin
[BL2] Hash mismatch: expected 9f3a...c21d, got 7b8e...a04f
[BL2] Image authentication failed
[BL2] System halt

排查后发现：产线使用的签名脚本是旧版本，仍然对 bl31.bin 使用 SHA1 签名，而熔丝中配置的是 SHA256。样机阶段因为手动签名，恰好用了新脚本，所以没有暴露问题。这个案例说明：量产问题往往不是“安全启动本身失败”，而是“配置一致性失败”。密钥、算法、版本、烧录工具、签名脚本，任何一项不一致都会导致校验失败。

六、学习路径与检查清单

本课程共 30 章，建议按“概念 → 配置 → 签名 → 烧录 → 调试 → 复盘”的顺序学习。每章都会围绕一个可操作对象展开，而不是停留在术语解释。下表给出本课程第一阶段的核心检查清单，你可以用它对照自己的项目现状。