摘要： 当 ECU 上电时，它如何判断即将运行的软件是车厂认可的版本，而不是被替换、篡改或伪造的程序？答案之一就是安全启动。本文不绑定某一款芯片，从威胁、密码学基础、信任链和失败处理四个角度，讲清安全启动能做什么、不能做什么。

关键词： 车载 ECU、信息安全、安全启动、Secure Boot、数字签名、信任根、信任链

---

1. 为什么 ECU 需要安全启动？

现代汽车中的 ECU 已经不只是执行简单控制逻辑。智能驾驶域控制器、座舱域控制器、中央计算平台等设备通常包含复杂的启动固件、操作系统、驱动和应用程序。

如果攻击者能够接触 ECU 的存储介质、刷写接口、维修接口或软件更新链路，就可能尝试：

• 修改启动程序，绕过后续安全检查；
• 用未经授权的软件替换原厂固件；
• 在正版固件中植入恶意代码；
• 将系统降级到存在已知漏洞的旧版本；
• 修改设备树、启动参数或安全配置，改变系统行为。

普通启动流程关注的是“镜像能否被读取和运行”，而安全启动在执行前多了一道关键判断：这个镜像是否来自被授权的发布者，并且发布后是否被修改过？

图 1：普通启动与安全启动的核心区别是执行前的可信验证

这里有一个必须提前说明的边界：安全启动主要阻止未通过认证的启动代码被执行。它不能自动修复正版软件中的漏洞，也不能单独解决运行时攻击、网络入侵、密钥泄露或错误权限配置。

2. 安全启动依赖哪些密码学能力？

2.1 哈希：给软件计算“数字指纹”

哈希算法把任意长度的数据转换成固定长度的摘要。只要原始数据发生变化，即使只改动一个比特，重新计算出的摘要通常也会完全不同。

因此，哈希适合检查完整性。但仅有哈希还不够：攻击者修改固件后，也可以重新计算一个新的哈希。ECU 还需要确认“这个摘要是谁认可的”，这就要用到数字签名。

2.2 数字签名：证明来源并保护完整性

软件发布方使用私钥对待发布内容的摘要进行签名，ECU 使用可信公钥验证签名。验证成功可以说明：

1. 签名由相应私钥的持有者产生；
2. 被验证的数据与签名时的数据一致。

在工程上，签名对象可能是镜像本身，也可能是包含镜像摘要、版本和长度等信息的受保护头部或清单。具体格式由平台决定。

图 2：私钥负责签名，ECU 使用预置信任材料验证。

数字签名解决的是真实性与完整性，不是保密性。签名后的固件仍可能被读取。如果产品还要求隐藏固件内容，需要另外采用受控的镜像加密方案。反过来，只有加密而没有可靠认证，也不能证明密文来自合法发布方。

2.3 公钥本身如何可信？

如果攻击者能把 ECU 中的公钥换成自己的公钥，他就可以给恶意程序签名。因此，最初的信任材料必须放在难以篡改的位置。

常见做法是把公钥摘要、根证书摘要或等价的信任配置写入一次性可编程存储、受保护硬件区域或芯片内部不可变区域。芯片上电后先从不可修改或受硬件保护的代码开始执行，这一最初可信起点通常称为硬件信任根（Hardware Root of Trust）。

不同芯片对信任材料、熔丝、ROM 和密钥槽的具体设计不同，不能把某个平台的字段名称和操作步骤直接套到另一个平台。

3. 什么是“逐级信任链”？

一个复杂 ECU 不可能把全部软件都放进不可变 ROM。更常见的方案是让信任逐级传递：

1. 不可变 ROM 中的代码从硬件信任根开始；
2. ROM 验证下一阶段启动组件；
3. 通过验证的启动组件继续验证后续引导程序；
4. 后续引导程序再验证操作系统、配置或其他受保护载荷；
5. 只有链条上的验证均满足策略，系统才进入预期运行状态。

图 3：信任不是“自动存在”，而是由上一可信阶段验证并传递给下一阶段。

这里的“下一阶段”只是通用概念。不同 MCU、SoC、操作系统和虚拟化架构的启动阶段不同，受保护对象也不同。设计安全启动时不能只验证第一个 Bootloader，却把后面的内核、设备树或关键配置留在信任链之外。

4. 固件被篡改后会发生什么？

假设攻击者修改了启动镜像中的一段代码。ECU 重新计算镜像摘要时，结果将与签名所保护的摘要不一致，因此认证失败。

图 4：验证失败的核心要求是不能继续执行未授权镜像。

验证失败以后，设备究竟做什么不能一概而论。根据产品的可用性、安全性和维修策略，它可能：

• 停止当前启动流程并保持在安全状态；
• 尝试另一个已经验证的启动槽位；
• 进入权限受限且同样需要认证的恢复模式；
• 记录启动失败原因，供维修或安全监控系统读取。

因此，“安全启动失败就一定关机”并不准确。真正必须满足的安全目标是：未经授权的代码不能因为验证失败而被继续执行；所有备用和恢复路径也不能成为绕过认证的后门。

5. 安全启动如何防止版本回滚？

数字签名只能证明“这个版本曾被合法签名”，不能天然证明“它仍然允许使用”。如果一个旧版本拥有合法签名，但包含已公开漏洞，攻击者仍可能尝试把 ECU 降级到该版本。

防回滚通常还需要：

• 在签名保护的数据中包含安全版本号；
• 在受保护且难以回退的介质中保存最低允许版本或安全计数；
• 启动时比较镜像版本与设备策略；
• OTA 成功后按照设计更新最低允许版本；
• 为维修、灾难恢复和法规要求设计受控例外，而不是留一个通用降级开关。

版本计数放在哪里、何时更新以及能否恢复，必须结合存储可靠性、OTA 原子性和产品生命周期设计。安全启动本身并不自动等于防回滚。

6. Secure Boot、Measured Boot 和远程证明不是一回事

这三个概念经常被混用：

机制	核心动作	主要目标
Secure Boot（安全启动）	启动前验证，不满足策略则拒绝执行	阻止未授权启动代码运行
Measured Boot（度量启动）	对启动组件计算度量值并保存	留下系统实际启动内容的可信记录
Remote Attestation（远程证明）	向远端提供受保护的状态或度量证据	让远端判断设备是否处于可信状态

三者可以组合，但不能互相替代。一个系统可能启用了安全启动，却没有远程证明；也可能记录了启动度量，却仍允许某些不满足认证策略的软件启动。具体能力必须查看平台说明。

7. 安全启动不等于“整机已经安全”

安全启动是基础防线，但完整的车载 ECU 防护通常还需要：

• 安全刷写与安全 OTA，确保更新来源、完整性和安装策略可信；
• 运行时最小权限、进程隔离、内存保护和接口访问控制；
• 密钥安全生成、存储、使用、轮换、吊销和销毁；
• 量产调试接口、诊断权限与维修模式管理；
• 漏洞监控、事件响应、日志和车端异常检测；
• 对恢复镜像、备用槽位和工厂模式执行同等级别的认证；
• 基于威胁分析与风险评估确定安全目标，而不是机械地勾选功能。

ISO/SAE 21434 面向道路车辆 E/E 系统全生命周期的网络安全工程和风险管理；UN R155 关注车辆网络安全及网络安全管理体系。安全启动可以成为风险处置措施和验证对象，但启用一个安全启动开关不等于已经满足 ISO/SAE 21434 或 UN R155。

8. 常见误区总结

1. “签名以后固件就看不见了。” 错。签名不提供保密性。
2. “加密镜像一定可信。” 错。保密与来源认证是不同目标。
3. “只验证 Bootloader 就够了。” 不一定。信任链应覆盖产品定义的全部关键启动载荷。
4. “合法签名的旧版本一定可以启动。” 不一定。还要看防回滚策略。
5. “验证失败必须直接关机。” 不准确。也可以进入经过认证的备用或恢复路径。
6. “开启安全启动就满足汽车网络安全法规。” 错。法规和标准要求的是系统化、全生命周期的风险管理与证据。

结语

安全启动的本质可以概括为一句话：从一个不可轻易篡改的信任起点出发，在每个关键启动阶段执行密码学验证，只让满足产品安全策略的软件获得执行权。

理解这条主线后，再看不同芯片的 BootROM、硬件熔丝、签名头、密钥槽和启动加载器，就不会被零散名词带偏。下一篇将以 NVIDIA DRIVE Orin 的公开资料为基础，介绍双重签名权限、OEM 密钥方案、量产流程和测试思路。

---

参考资料

1. ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering
2. ISO：Cybersecurity in cars
3. UNECE：UN Regulation No. 155 — Cyber security and cyber security management system
4. NVIDIA DRIVE OS 6.0.9.1：Secure Boot

版本与边界说明： 本文的密码学和信任链部分是通用原理。具体 ECU 的启动阶段、受保护对象、算法、密钥格式、熔丝配置与失败行为，应以对应芯片、BSP/PDK、产品安全需求和已授权文档为准。