2. AURIX安全启动与信任根建立
AURIX TC3xx 的安全启动不是“上电后校验一下固件”这么简单，它是一条由硬件固化逻辑逐级传递信任的链：BootROM 先信任自己，再信任 UCB 中的配置，然后信任 HSM 中的密钥，最后才把控制权交给应用固件。理解这条链的关键，是分清“谁在什么时候、用什么依据、对什么对象做判断”。
一、信任根从哪里来：BootROM 与 UCB
芯片复位后，CPU 首先执行的是固化在 BootROM 中的代码。BootROM 位于不可修改的 ROM 区域，是整条信任链的起点，它本身无法被固件改写，因此成为天然的信任根。BootROM 在初始化阶段会读取 UCB（User Configuration Block）中的配置字，决定后续启动行为。
UCB 位于 Flash 的特定扇区，典型包含 UCB_PFLASH、UCB_HSMCOTP、UCB_DFLASH 等区域。每个 UCB 都有主副本和若干备份副本，BootROM 读取时会做一致性校验：若主副本损坏，则尝试备份副本；若全部副本均无效，则按默认（通常是最保守）配置继续。UCB 中与安全启动直接相关的字段包括：
- PROCONHSMCFG：HSM 保护配置，决定 HSM 是否使能、启动模式及调试访问权限；
- PROCONPFLASH：PFlash 保护配置，控制应用 Flash 的读/写/擦除保护；
- PROCONDFLASH：DFlash 保护配置，影响 HSM 密钥与数据存储区；
- PROCONRAM：RAM 初始化与保护配置。
这些字段一旦写入并确认，就通过 UCB 的确认机制（写入确认码）锁定，后续只能通过特定解锁流程修改。因此 UCB 的配置阶段本身就是安全启动设计的一部分：配置错了，后面所有验证都无从谈起。
二、HSM 的角色：密钥的保险箱与验证的执行者
HSM（Hardware Security Module）是 AURIX 内部独立的安全子系统，拥有自己的 CPU、RAM、Flash 和加密加速器。它不直接参与应用代码执行，而是作为“可信执行环境”承担密钥存储、签名验证、安全计数等任务。
HSM 的固件通常存放在 HSM Flash 中，由 BootROM 根据 UCB 配置加载并启动。HSM 启动后，应用侧通过共享内存和中断与 HSM 通信，请求它执行验证操作。密钥不会以明文出现在应用 Flash 中，而是存放在 HSM 受保护的密钥槽（Key Slot）内，应用只能通过句柄引用，无法直接读出。这是“密钥存储”与“固件验证”分离的核心设计。
三、安全启动的完整流程
把上述组件串起来，一次典型的安全启动按以下顺序发生：
- 复位释放：CPU 从 BootROM 入口开始执行，此时所有外设处于默认状态。
- BootROM 自检与 UCB 读取：BootROM 校验自身完整性（硬件层面），然后读取 UCB 主副本；若主副本 CRC 或确认码无效，回退到备份副本。
- HSM 启动：根据
PROCONHSMCFG决定是否使能 HSM。若使能，BootROM 将 HSM 固件从 HSM Flash 加载到 HSM RAM 并启动 HSM CPU。 - 应用固件验证：HSM 启动后，根据配置对应用 Flash 中的固件镜像执行签名验证。验证对象通常包括固件头、代码段和常量段。
- 结果处理：验证通过则释放应用 CPU 复位，跳转到应用入口；验证失败则进入安全失败处理路径。
这里有一个容易混淆的点：BootROM 本身并不直接做应用固件的签名验证，它负责的是“把 HSM 拉起来并告诉它该验证什么”。真正的密码学验证由 HSM 完成。这种分工使得验证逻辑和密钥都不暴露在应用可访问的空间里。
四、密钥存储与固件验证机制
HSM 中的密钥槽按用途分为几类：验证公钥槽、加密密钥槽、HMAC 密钥槽等。安全启动主要使用验证公钥槽。公钥在 HSM 生产阶段或首次配置阶段写入，写入后可通过 UCB 中的保护位禁止读出。应用侧只能通过密钥句柄请求 HSM 用指定公钥验签，无法获取公钥明文。
固件验证的典型参数关系如下（以下为教学示例，非实测数据）：
| 参数 | 示例值 | 说明 |
|---|---|---|
| 签名算法 | ECDSA P-256 | 也可选 RSA-2048/3072 |
| 哈希算法 | SHA-256 | 与签名算法匹配 |
| 固件镜像大小 | 512 KB | 覆盖头部+代码+常量 |
| 签名长度 | 64 字节 | ECDSA P-256 的 r+s |
| 验证耗时（示例） | 约 8~15 ms | 取决于 HSM 主频与算法 |
验证时，HSM 先对固件镜像计算 SHA-256 摘要，再用密钥槽中的公钥对签名值做验签运算，最后比对两个摘要。若一致，返回验证通过；否则返回失败。整个过程在 HSM 内部完成，应用 CPU 在此期间处于等待状态。
五、安全启动失败时的诊断策略
安全启动失败并不只有“起不来”一种表现。根据失败发生的阶段，可以分为三类：
- UCB 阶段失败：主副本和备份副本均无效，BootROM 回退到默认配置。此时 HSM 可能未使能，应用固件可能被直接加载，但安全等级下降。诊断方法是读取 UCB 状态寄存器，确认哪一份副本校验失败。
- HSM 启动失败：HSM 固件加载或自检失败。此时应用侧无法获得验证服务，通常表现为启动卡死或反复复位。诊断需要检查 HSM Flash 内容是否完整、HSM 配置字是否正确。
- 固件验签失败：HSM 正常工作但验签不通过。常见原因包括固件被篡改、签名与公钥不匹配、镜像覆盖范围配置错误。诊断时可通过 HSM 返回的错误码区分“哈希不匹配”和“签名无效”。
实际调试中，可以借助调试器读取启动状态寄存器（如 SCU_STAT、HSM_STAT 等）以及 HSM 返回的错误码。若调试口在安全启动失败后被关闭，则需要通过 UCB 中的调试配置位在下次启动时临时开放调试访问，但这一操作本身会降低安全等级，仅建议在开发阶段使用。
总结来看，AURIX 安全启动的信任根是 BootROM，配置依据是 UCB，验证执行者是 HSM，验证对象是应用固件。四者形成一条单向信任链：每一级只信任上一级的输出，不信任任何未经校验的输入。理解这条链的每一环，才能在启动失败时快速定位是配置问题、密钥问题还是固件问题。