摘要当 ECU 上电时它如何判断即将运行的软件是车厂认可的版本而不是被替换、篡改或伪造的程序答案之一就是安全启动。本文不绑定某一款芯片从威胁、密码学基础、信任链和失败处理四个角度讲清安全启动能做什么、不能做什么。关键词车载 ECU、信息安全、安全启动、Secure Boot、数字签名、信任根、信任链1. 为什么 ECU 需要安全启动现代汽车中的 ECU 已经不只是执行简单控制逻辑。智能驾驶域控制器、座舱域控制器、中央计算平台等设备通常包含复杂的启动固件、操作系统、驱动和应用程序。如果攻击者能够接触 ECU 的存储介质、刷写接口、维修接口或软件更新链路就可能尝试修改启动程序绕过后续安全检查用未经授权的软件替换原厂固件在正版固件中植入恶意代码将系统降级到存在已知漏洞的旧版本修改设备树、启动参数或安全配置改变系统行为。普通启动流程关注的是“镜像能否被读取和运行”而安全启动在执行前多了一道关键判断这个镜像是否来自被授权的发布者并且发布后是否被修改过图 1普通启动与安全启动的核心区别是执行前的可信验证这里有一个必须提前说明的边界安全启动主要阻止未通过认证的启动代码被执行。它不能自动修复正版软件中的漏洞也不能单独解决运行时攻击、网络入侵、密钥泄露或错误权限配置。2. 安全启动依赖哪些密码学能力2.1 哈希给软件计算“数字指纹”哈希算法把任意长度的数据转换成固定长度的摘要。只要原始数据发生变化即使只改动一个比特重新计算出的摘要通常也会完全不同。因此哈希适合检查完整性。但仅有哈希还不够攻击者修改固件后也可以重新计算一个新的哈希。ECU 还需要确认“这个摘要是谁认可的”这就要用到数字签名。2.2 数字签名证明来源并保护完整性软件发布方使用私钥对待发布内容的摘要进行签名ECU 使用可信公钥验证签名。验证成功可以说明签名由相应私钥的持有者产生被验证的数据与签名时的数据一致。在工程上签名对象可能是镜像本身也可能是包含镜像摘要、版本和长度等信息的受保护头部或清单。具体格式由平台决定。图 2私钥负责签名ECU 使用预置信任材料验证。数字签名解决的是真实性与完整性不是保密性。签名后的固件仍可能被读取。如果产品还要求隐藏固件内容需要另外采用受控的镜像加密方案。反过来只有加密而没有可靠认证也不能证明密文来自合法发布方。2.3 公钥本身如何可信如果攻击者能把 ECU 中的公钥换成自己的公钥他就可以给恶意程序签名。因此最初的信任材料必须放在难以篡改的位置。常见做法是把公钥摘要、根证书摘要或等价的信任配置写入一次性可编程存储、受保护硬件区域或芯片内部不可变区域。芯片上电后先从不可修改或受硬件保护的代码开始执行这一最初可信起点通常称为硬件信任根Hardware Root of Trust。不同芯片对信任材料、熔丝、ROM 和密钥槽的具体设计不同不能把某个平台的字段名称和操作步骤直接套到另一个平台。3. 什么是“逐级信任链”一个复杂 ECU 不可能把全部软件都放进不可变 ROM。更常见的方案是让信任逐级传递不可变 ROM 中的代码从硬件信任根开始ROM 验证下一阶段启动组件通过验证的启动组件继续验证后续引导程序后续引导程序再验证操作系统、配置或其他受保护载荷只有链条上的验证均满足策略系统才进入预期运行状态。图 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. 常见误区总结“签名以后固件就看不见了。”错。签名不提供保密性。“加密镜像一定可信。”错。保密与来源认证是不同目标。“只验证 Bootloader 就够了。”不一定。信任链应覆盖产品定义的全部关键启动载荷。“合法签名的旧版本一定可以启动。”不一定。还要看防回滚策略。“验证失败必须直接关机。”不准确。也可以进入经过认证的备用或恢复路径。“开启安全启动就满足汽车网络安全法规。”错。法规和标准要求的是系统化、全生命周期的风险管理与证据。结语安全启动的本质可以概括为一句话从一个不可轻易篡改的信任起点出发在每个关键启动阶段执行密码学验证只让满足产品安全策略的软件获得执行权。理解这条主线后再看不同芯片的 BootROM、硬件熔丝、签名头、密钥槽和启动加载器就不会被零散名词带偏。下一篇将以 NVIDIA DRIVE Orin 的公开资料为基础介绍双重签名权限、OEM 密钥方案、量产流程和测试思路。参考资料ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineeringISOCybersecurity in carsUNECEUN Regulation No. 155 — Cyber security and cyber security management systemNVIDIA DRIVE OS 6.0.9.1Secure Boot版本与边界说明本文的密码学和信任链部分是通用原理。具体 ECU 的启动阶段、受保护对象、算法、密钥格式、熔丝配置与失败行为应以对应芯片、BSP/PDK、产品安全需求和已授权文档为准。