1. 课程导入

在嵌入式设备、车载控制器、工业网关、智能摄像头以及各类物联网终端中，设备上电后执行的第一段代码决定了整个系统的可信起点。如果这段代码可以被替换、篡改或回滚，那么后续操作系统、应用、密钥和用户数据都将失去安全根基。安全Boot（Secure Boot）与镜像验签（Image Signature Verification）正是为了解决“设备到底运行了谁写的代码、这段代码是否被允许运行”这一根本问题而存在的工程机制。

一、核心原理：从信任根到信任链

安全Boot的本质不是“加密启动”，而是“验证后启动”。它依赖一个不可被篡改的信任根（Root of Trust，RoT），通常由芯片内部固化的BootROM、一次性可编程熔丝（OTP/eFuse）中保存的公钥哈希或根公钥证书构成。设备上电后，BootROM首先校验第一阶段引导程序（如BL1、SPL、FSBL）的签名；校验通过后，才把控制权交给它。第一阶段引导程序再用类似方式校验第二阶段引导程序、U-Boot、Linux内核、设备树、根文件系统或容器镜像。每一级都验证下一级，最终形成一条从硬件到应用的信任链（Chain of Trust）。

镜像验签通常采用“哈希+非对称签名”的组合：签名方在发布镜像前计算镜像摘要，用私钥对摘要签名，并把签名、证书链、镜像元数据打包；设备端用烧录在OTP或安全存储中的公钥或公钥哈希验证证书链，再用证书中的公钥验证镜像签名，最后重新计算镜像摘要并与签名解出的摘要比对。常见算法包括RSA-2048/3072、ECDSA P-256、Ed25519，摘要算法以SHA-256、SHA-384为主。验签失败时，设备应拒绝启动、进入恢复模式或触发告警，而不是继续执行可疑镜像。

二、方法流程：一条可落地的验签链路

工程上，安全Boot通常按“签名—打包—烧录—启动—验签—决策”六个阶段推进。签名阶段由发布服务器或HSM完成，私钥不出安全边界；打包阶段把镜像、签名、证书链、版本号、镜像类型等元数据组织成设备可识别的格式，例如FIT Image、Android Boot Image、U-Boot签名镜像或自定义TLV结构；烧录阶段把根公钥哈希写入OTP/eFuse，把镜像写入Flash或eMMC；启动阶段由BootROM逐级加载；验签阶段完成证书链验证、摘要计算和签名比对；决策阶段根据结果选择继续启动、进入恢复模式或记录安全事件。

# 典型镜像签名与验签命令示意（以U-Boot FIT为例）
mkimage -f kernel.its -k keys/ -r kernel.itb
# 设备端验签日志
U-Boot SPL 2024.01
Trying to boot from MMC1
Verifying FIT image signature...
   Hash algo: sha256
   Sign algo: sha256,rsa2048
   Sign key: dev-kernel-2024
   Result: OK
Starting kernel ...

三、案例/场景：车载网关的安全启动

某车载网关采用NXP i.MX8平台，BootROM从OTP读取根公钥哈希，验证FSBL签名；FSBL验证U-Boot与ATF；U-Boot验证Linux内核、设备树和根文件系统哈希；根文件系统通过dm-verity做块级完整性校验。一次OTA升级后设备无法启动，串口日志显示“FIT signature verification failed”。排查发现升级包中的内核镜像被重新压缩，但签名仍基于旧镜像计算，导致摘要不一致。修复方式是在CI流水线中固定“先压缩、后签名”的顺序，并把签名步骤纳入发布门禁。这个案例说明：安全Boot不是单点技术，而是贯穿构建、发布、升级、回滚的工程体系。

四、误区与复盘

• 误区一：把安全Boot等同于加密启动。安全Boot解决“能不能运行”，加密启动解决“代码是否可读”，两者目标不同，可组合使用。
• 误区二：只验内核，不验根文件系统。攻击者可通过替换根文件系统中的init脚本或动态库绕过内核验签，必须把根文件系统、容器镜像、配置分区纳入验证范围。
• 误区三：忽略防回滚。仅验证签名无法阻止攻击者刷入旧版本合法镜像，需要版本号、单调计数器和OTP配合。
• 误区四：密钥管理随意。私钥泄露意味着信任链彻底失效，必须使用HSM、密钥分级、最小权限和审计日志。

五、整体知识框架与工程实践路线