3. AURIX启动流程与安全启动验证
AURIX TC3xx 的启动过程并不是“上电后直接跳到应用”，而是一条由硬件固化代码逐级放权、逐级校验的信任链。理解这条链的关键，是分清每一级由谁执行、校验什么、失败后落到哪里。只有把 BootROM、启动模式选择、HSM 与用户固件的边界看清楚，后续做安全验证和攻击面测试时才知道哪些点值得测、哪些点理论上不可绕过。
一、信任链的四个阶段
上电复位后，CPU 首先从 BootROM（芯片内固化、不可修改的启动代码）开始执行。BootROM 的第一件事是读取启动模式配置，然后根据配置决定从哪个介质加载下一级代码。TC3xx 常见的启动介质包括内部 Flash（用户固件）、HSM 固件、以及通过 CAN、LIN、Ethernet 等接口的引导加载（Bootstrap Loader, BSL）。
信任链大致分为四段：
- BootROM 阶段：固化代码，负责最基础的时钟、内存初始化，读取启动模式引脚/Flash 配置，决定启动路径。它本身不可被改写，是信任根（Root of Trust）。
- HSM 启动阶段：如果启用了 HSM（Hardware Security Module），BootROM 会先加载并校验 HSM 固件，HSM 启动后再参与后续用户固件的校验。
- 用户固件校验阶段：BootROM 或 HSM 根据配置对用户 Flash 中的固件头部、签名、哈希进行校验，校验通过才跳转到用户代码入口。
- 应用运行阶段：用户固件开始执行，此时信任链已经建立，应用可以依赖 HSM 提供的安全服务。
这条链的核心思想是：每一级只信任上一级校验过的代码，BootROM 信任 HSM，HSM 信任用户固件，用户固件信任自己的应用逻辑。任何一级校验失败，启动流程都会停在安全状态，而不是继续执行未经验证的代码。
二、启动模式与校验点的实际配置
TC3xx 的启动模式由一组配置决定，通常包括启动模式引脚（如 HWCFG 引脚）和 Flash 中的配置块（如 UCB，User Configuration Block）。HWCFG 引脚在复位释放时被采样，决定是从内部 Flash 启动、从 HSM 启动，还是进入 Bootstrap Loader 模式。UCB 中则保存了更细粒度的配置，比如是否启用安全启动、使用哪组密钥、校验失败后的行为等。
校验点主要分布在三个位置：
- HSM 固件校验：BootROM 在加载 HSM 固件时，会校验其签名和完整性。如果 HSM 固件被篡改，BootROM 会拒绝加载，启动流程终止。
- 用户固件头部校验：用户固件在 Flash 中有一个头部区域，包含固件长度、版本、签名算法、公钥索引等信息。BootROM 或 HSM 会先校验头部，确认固件的基本属性合法。
- 用户固件签名校验：对固件主体计算哈希，再用公钥验证签名。只有签名匹配，才允许跳转到用户代码入口。
这些校验点的配置通常通过 UCB 中的启动配置字段完成。例如，可以设置“安全启动使能位”，指定使用哪一组公钥（通常有多组密钥槽位，支持密钥轮换），以及校验失败后是复位还是停留在 BootROM 的调试模式。实际项目中，这些配置往往由 HSM 工具链或芯片厂商提供的配置工具生成，再烧录到 UCB 区域。
三、常见绕过思路与测试关注点
从攻击面测试的角度看，启动流程的绕过思路通常不是“直接改 BootROM”（它不可改），而是寻找配置、密钥管理或校验逻辑中的薄弱环节。以下是几类值得关注的测试方向：
- 启动模式配置错误：如果 HWCFG 引脚或 UCB 配置允许从外部接口进入 BSL，且 BSL 没有强制校验，攻击者可能通过 BSL 加载未签名固件。测试时应确认 BSL 是否受安全启动保护，以及进入 BSL 的条件是否可被外部触发。
- 密钥槽位管理不当：如果多个密钥槽位中有一个被泄露或可被替换，攻击者可能用合法但非预期的密钥签名固件。测试时应检查密钥槽位的访问权限、轮换策略和撤销机制。
- 校验失败后的行为：如果校验失败后芯片没有进入安全停机，而是回退到某个可交互模式（如调试模式或 BSL），就可能被利用。测试时应验证失败路径是否真的不可绕过。
- HSM 与用户固件的边界：HSM 固件和用户固件之间的通信接口如果缺乏访问控制，攻击者可能通过用户固件向 HSM 发送恶意请求，间接影响启动校验。测试时应关注 HSM 服务的调用权限和参数校验。
- 版本回滚：如果启动校验只验证签名而不检查版本号，攻击者可能将固件回滚到存在已知漏洞的旧版本。测试时应确认是否启用了防回滚机制（如单调计数器）。
四、一个可参考的启动校验检查清单
在实际安全验证项目中，可以按下面的清单逐项确认启动链的完整性。清单中的参数和配置项是示例性的，具体值需要根据项目使用的芯片型号、HSM 固件版本和 UCB 配置来确定。
| 检查项 | 关注内容 | 判断依据 |
|---|---|---|
| 启动模式引脚 | HWCFG 采样值是否与预期一致 | 复位释放时引脚电平符合设计文档 |
| UCB 配置 | 安全启动使能位、密钥槽位选择 | 读取 UCB 内容与配置工具输出一致 |
| HSM 固件校验 | 签名算法、公钥索引、校验结果 | 篡改 HSM 固件后启动被拒绝 |
| 用户固件头部 | 长度、版本、签名算法字段 | 头部字段与固件实际属性匹配 |
| 用户固件签名 | 哈希计算范围、签名验证结果 | 修改固件任意字节后校验失败 |
| 失败路径 | 校验失败后的芯片状态 | 不进入可交互模式，不执行未验证代码 |
| 防回滚 | 版本号检查、单调计数器 | 旧版本固件无法通过校验 |
这张表可以作为启动安全验证的起点。实际执行时，每一项都需要具体的测试方法和工具支持，比如用调试器读取 UCB、用 HSM 工具链重新签名固件、用示波器观察启动模式引脚等。验证的目标不是“证明启动流程绝对安全”，而是确认在当前配置下，信任链的每一级都按预期工作，且失败路径不会给攻击者留下可乘之机。
最后要提醒的是，AURIX 的启动流程与具体型号、HSM 固件版本、UCB 配置强相关。TC3xx 系列内部不同型号的 BootROM 行为可能有差异，做安全验证时必须以对应型号的用户手册和 HSM 文档为准，不能把某一型号的结论直接套用到另一型号上。