1. 课程导入

在汽车电子电气架构快速演进的过程中,电子控制单元(ECU)不再只是执行单一控制逻辑的嵌入式设备,而是承载功能安全、信息安全、在线升级与整车网络通信的可信计算节点。英飞凌AURIX系列微控制器凭借多核锁步架构、硬件安全模块(HSM)、安全启动与丰富的外设安全机制,成为动力、底盘、域控制器等高安全等级场景的主流平台。本课程围绕“安全软件”与“可信启动工程”两条主线展开,帮助学习者建立从芯片安全根到应用软件可信运行的完整工程能力。

本课程的核心问题不是“如何写一段加密代码”,而是:在AURIX平台上,如何让每一级软件在加载与运行前都可被验证、可被度量、可被追溯,并在异常时可控地降级或拒绝启动。

一、学习目标:从“会配置”到“能构建可信链”

学习完本课程后,学习者应达到以下四个层次的目标:

  • 概念层:理解可信根(RoT)、信任链、度量、验证、安全启动、安全刷写、HSM固件、密钥层级等核心术语及其在AURIX中的具体映射。
  • 原理层:掌握AURIX启动流程中BootROM、HSM、Flash、UCB(User Configuration Block)之间的协作关系,理解为什么“先验证再执行”是可信启动的基本约束。
  • 工程层:能够基于AURIX Development Studio或Tasking工具链,完成HSM固件集成、启动头配置、签名与验签流程、安全刷写脚本的搭建与调试。
  • 排障层:能够根据启动日志、HSM状态寄存器、UCB配置和错误码,定位“启动失败”“验签不通过”“HSM未就绪”等典型问题,并给出可复现的修复路径。

二、核心概念:可信启动的五个关键对象

为了避免一开始就陷入寄存器细节,先建立五个关键对象的认知框架:

概念在AURIX中的典型载体作用
可信根 RoTBootROM + HSM内部只读密钥区不可篡改的起点,负责第一级验证
信任链BootROM → HSM固件 → 应用启动头 → 应用代码逐级度量与验证,形成传递信任
度量与验证SHA-256摘要 + ECDSA/RSA签名确认代码完整性与来源真实性
安全配置UCB、HSM配置块、启动模式引脚决定启动策略、调试口状态与密钥选择
安全服务HSM提供的加解密、随机数、安全存储为应用层提供可信执行环境

这五个对象不是孤立存在的。可信根提供初始信任,信任链把信任逐级传递,度量与验证是传递手段,安全配置决定传递规则,安全服务则是可信启动完成后应用可调用的能力集合。

三、整体知识框架:三层结构

本课程的知识框架可以概括为“芯片层—启动层—应用层”三层结构。芯片层关注AURIX的HSM硬件、Flash分区、UCB与安全外设;启动层关注BootROM流程、启动头格式、签名验签、安全刷写与回滚策略;应用层关注安全服务调用、密钥管理、诊断与日志、以及功能安全与信息安全的协同。

AURIX安全软件与可信启动工程 · 知识框架 芯片层 · 安全硬件基础 HSM 硬件安全模块 Flash 分区与 UCB BootROM 只读代码 安全外设与时钟 调试口控制 启动层 · 可信链构建 BootROM 第一级验证 HSM 固件 签名与度量 启动头 摘要与签名 应用镜像 验签后执行 安全刷写与回滚 A/B 分区策略 应用层 · 可信服务与工程落地 HSM 安全服务调用 加解密 / 随机数 密钥管理与生命周期 注入 / 更新 / 吊销 诊断与安全日志 DTC / 事件记录 功能安全与信息安全协同 ISO 26262 / ISO 21434 从硬件可信根出发,逐级验证,最终支撑应用层安全服务与合规落地

四、方法流程:一次可信启动的典型路径

以AURIX TC3xx为例,一次完整的可信启动通常包含以下阶段。理解这条路径,后续章节的配置与调试才有落脚点。

  1. 上电复位:芯片从BootROM开始执行,读取启动模式引脚与UCB配置,确定是否启用安全启动。
  2. HSM固件加载与验证:BootROM根据UCB中的密钥信息,验证HSM固件的签名与完整性。
  3. HSM启动并度量应用:HSM就绪后,对应用启动头和应用镜像进行摘要计算与签名验证。
  4. 应用跳转:验证通过后,控制权交给应用;若失败,则进入安全降级或停止启动。
  5. 运行时安全服务:应用通过HSM接口调用加解密、随机数、安全存储等能力。

在工程实现中,上述流程会体现为一系列配置与命令。例如,使用工具链生成签名镜像时,常见操作如下:

# 生成应用镜像摘要并签名(示意)
hsm_sign_tool --key app_priv.pem \
              --hash sha256 \
              --input app.bin \
              --output app_signed.bin

# 将签名镜像与启动头合并
boot_header_gen --header header.json \
                --image app_signed.bin \
                --out app_final.hex

五、案例场景:安全刷写失败后的复盘

某项目在产线刷写阶段出现“刷写成功但启动失败”的问题。排查发现,新固件的启动头中密钥索引指向了错误的UCB页,导致BootROM在验证HSM固件时使用了旧密钥,验签失败后芯片进入停止状态。复盘结论有三点:第一,密钥索引必须与UCB配置严格一致;第二,刷写脚本应增加启动头校验步骤;第三,产线应保留可回滚的A/B分区镜像。这个案例说明,可信启动不是单点技术,而是配置、工具链与流程的协同。

常见误区:把“能启动”等同于“可信启动”。实际上,未启用安全启动的芯片同样可以正常启动,但没有任何验证过程。可信启动的关键在于“验证失败时拒绝执行”,而不是“启动成功”。

六、学习路径建议

建议按“先框架、再流程、后实操”的节奏推进:

  • 第1阶段:建立概念地图,理解RoT、信任链、HSM、UCB、启动头之间的关系。
  • 第2阶段:跟随启动流程,逐级分析BootROM、HSM固件、应用镜像的验证逻辑。
  • 第3阶段:动手配置UCB、生成签名镜像、搭建安全刷写脚本,并观察启动日志。
  • 第4阶段:结合功能安全与信息安全要求,设计密钥生命周期与诊断策略。