1. 课程导入与工程全景

在工业网关、车载 T-Box、智能电表、医疗终端这类长期部署且难以现场维护的设备中，i.MX 系列处理器常被用作主控。设备一旦出厂，固件更新只能依赖网络下发，而设备里又保存着密钥、证书、用户数据等敏感资产。安全启动（Secure Boot）与 OTA（Over-The-Air）升级因此成为一对必须同时成立的机制：安全启动保证“设备只运行被授权方签过名的固件”，OTA 保证“授权方能在不拆机的前提下把新固件安全地送进去”。本课程围绕 NXP i.MX（以 i.MX6/8 系列、HAB/HABv4 与 AHAB/Advanced High Assurance Boot 为主线）展开，从威胁模型出发，逐步落到密钥、镜像签名、启动链验证、OTA 包格式、回滚与防降级、失败恢复等工程细节。

典型产品场景与安全目标

以一台基于 i.MX8M Mini 的工业边缘网关为例：设备通过 4G/以太网连接云端，运行 Linux，承载数据采集与协议转换。它的安全目标可以拆成三条：其一，启动完整性——从上电到内核挂载根文件系统，每一级镜像都必须通过密码学验证，任何被篡改的 U-Boot 或内核都不能执行；其二，固件机密性与真实性——OTA 包在公网传输，必须加密并签名，防止窃取与伪造；其三，可恢复性——升级断电、镜像损坏时，设备仍能回到可用状态，而不是变砖。这三条目标决定了后续所有设计：密钥放哪里、镜像怎么签、启动链怎么串、OTA 怎么切分区。

威胁模型：先想清楚“谁在攻击、攻击什么”

安全启动不是抽象概念，它针对的是具体攻击面。常见威胁包括：攻击者拿到设备后通过串口或 USB 下载模式刷入恶意 U-Boot；通过网络中间人替换 OTA 包；利用旧版本固件的已知漏洞降级回滚；通过物理方式读取外部 Flash 中的密钥；以及升级过程中断电导致镜像不完整。对应的防护手段分别是：HAB/AHAB 的签名验证、OTA 包的签名与加密、防降级计数器（Monotonic Counter）、密钥存储于 OTP/eFuse 或 CAAM 加密区、A/B 双分区与回滚机制。理解“威胁—防护”的对应关系，比记住某个命令更重要。

学习路线：从“能启动”到“能安全升级”

本课程按能力递进组织。第一阶段建立概念与实验环境：理解 HAB/AHAB 的信任根、IVT/CSF 结构、eFuse 的作用，并在开发板上完成一次未签名启动与签名启动的对比。第二阶段进入密钥与签名实操：生成 PKI 树、用 CST 工具签名 U-Boot 与内核、烧写 SRK 哈希到 eFuse、观察 HAB 事件日志。第三阶段聚焦 OTA：设计 A/B 分区布局、制作带签名的升级包、实现下载验签与分区切换、处理断电与回滚。第四阶段是工程化：防降级计数器、密钥轮换、量产烧录、安全审计与故障排查。每一阶段都对应可观察的结果，例如 HAB 状态从“OPEN”变为“CLOSED”、OTA 后版本号更新且旧分区仍可回退。

实验环境搭建

建议使用一块支持 HAB 的 i.MX6ULL 或 i.MX8M Mini 开发板，配合 Yocto 构建的 Linux BSP。主机侧需要 NXP 的 imx-cst（Code Signing Tool）、uuu（Universal Update Utility）以及串口终端。关键准备动作包括：确认 SoC 的 HAB 版本与 eFuse 布局；备份原始固件；准备一张可启动的 SD 卡作为恢复介质；在 U-Boot 中打开 hab_status 命令以便读取启动验证结果。下面是一段用于检查 HAB 状态的示例命令与预期输出（示例为合理假设，实际以所用 BSP 为准）：

# 在 U-Boot 命令行中执行
=> hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66
    No HAB Events Found!

当 eFuse 烧写 SRK 哈希并关闭 HAB 后，同样的命令会显示 Secure boot enabled，若签名不匹配则出现 HAB Events Found 及具体事件码。这个“状态—事件”的观察点，是后续所有调试的基础。实验环境搭建完成后，你应当能回答三个问题：当前设备是否已启用安全启动？启动链中哪一级验证失败？OTA 包是否被正确签名？带着这三个问题进入后续章节，学习会更有针对性。