1. 课程导入

随着智能网联汽车电子电气架构从分布式 ECU 向域控制器、中央计算平台演进，车辆上运行的软件规模与复杂度呈指数级增长。一个中高端车型的代码量已超过一亿行，涉及动力、底盘、座舱、智驾、网关等多个安全关键域。在这样的背景下，"车辆上电后，我凭什么相信正在运行的软件是原始设计的那一份、没有被篡改、也没有被替换？"成为整车信息安全的第一性问题。车载可信启动（Automotive Trusted Boot）正是回答这一问题的底层安全机制。

一、什么是车载可信启动

可信启动是指系统从上电复位开始，以一段不可篡改的信任根（Root of Trust, RoT）为起点，逐级度量、校验并加载后续每一段固件或操作系统镜像，只有当前一级验证通过后，才把控制权交给下一级，从而形成一条可验证的信任链（Chain of Trust）。在车载场景中，这条链通常表现为：BootROM → 一级引导（SPL/BL1）→ 二级引导（U-Boot/BL2）→ 安全监控（Hypervisor/OP-TEE）→ 操作系统内核 → 关键应用与 OTA 代理。

与消费电子不同，车载可信启动有三个鲜明特征：其一，必须满足车规级实时性与可靠性要求，启动时间预算往往被严格限制在数百毫秒到数秒；其二，必须支持整车生命周期内的安全 OTA 升级，信任根与密钥体系要能平滑演进；其三，必须与功能安全（ISO 26262）和信息安全（ISO/SAE 21434）双重要求对齐，任何校验失败都要有确定的降级或安全状态响应。

二、工程价值：为什么整车厂必须做

可信启动的工程价值可以从合规、安全、商业三个维度理解。合规层面，UN R155/R156 法规要求整车厂建立网络安全管理体系并具备检测与响应能力，可信启动是抵御固件篡改的基础手段；国内《汽车整车信息安全技术要求》等标准也明确要求关键固件具备安全启动能力。安全层面，攻击者一旦能够刷写未签名固件，就可能长期驻留、绕过诊断、篡改里程或动力参数，可信启动把攻击面从"运行期"前移到"启动期"，大幅提高攻击成本。商业层面，可信启动是 OTA 升级、数字钥匙、自动驾驶数据存证等业务的安全底座，没有可信启动，后续所有上层安全机制都建立在流沙之上。

三、整体知识框架

本课程共 30 章，围绕"原理—实现—验证—故障分析"四条主线展开。下面的结构图展示了从信任根到应用、从设计到验证的完整知识地图，也是后续各章节的定位参照。

四、典型场景：一次上电启动发生了什么

以某域控制器为例，上电后 BootROM 首先读取熔丝中烧录的公钥哈希，验证一级引导的签名；通过后跳转到 BL1，BL1 再验证 U-Boot 镜像的哈希与签名；U-Boot 校验内核与设备树，随后由 OP-TEE 建立安全世界，最后内核启动并校验关键应用。整个过程可用如下日志片段概括：

[BOOTROM] RoT hash OK, verify BL1 signature ... PASS
[BL1]     load BL2 @0x40000000, sha256 match, rsa2048 verify PASS
[BL2]     verify kernel Image + dtb ... PASS
[OP-TEE]  secure world init, RPMB counter = 0x1A
[KERNEL]  dm-verity root hash OK, mount system
[APP]     OTA agent signature check PASS, boot complete 1.82s

如果其中任何一步失败，系统不会继续启动，而是进入预定义的安全状态：记录事件、点亮故障指示、允许受限诊断或触发恢复分区。这正是可信启动与普通启动的本质区别——失败是显式的、可控的、可追溯的。

五、常见误区与学习建议