📚 课程目录第3章 AURIX安全启动链审计

3. AURIX安全启动链审计

AURIX 的安全启动不是一次性的“验签通过即放行”，而是一条由硬件信任根逐级向应用软件传递信任的链式过程。审计这条链，核心是回答三个问题：每一级启动阶段到底验证了什么、验证失败时系统留下了什么证据、这些证据如何被提取并还原成可追溯的事件序列。只有把“阶段—验证—失败—日志”四者对应起来，取证才有落点。

启动阶段划分：从 BootROM 到应用

AURIX TC3xx 的启动链通常可划分为四个可审计阶段。第一阶段是 BootROM（固件只读区）执行的上电自检与启动模式判定，它读取启动模式引脚（如 HWCFG 引脚组合）和 Flash 中的启动配置，决定从内部 Flash、外部 Flash 还是调试接口启动。第二阶段是固件头（Firmware Header）解析，BootROM 读取用户固件头中的入口地址、长度、校验和与签名信息，完成对首段固件的完整性校验。第三阶段是 HSM（Hardware Security Module）参与的签名验证，由 HSM 使用存储在受保护密钥槽中的公钥对固件镜像的哈希值做 ECDSA 或 RSA 验签。第四阶段是应用固件接管，完成外设初始化、看门狗配置并跳转到应用入口。

审计视角下，这四个阶段的关键区别在于“信任来源不同”：BootROM 的信任来自芯片出厂固化的不可修改代码，属于硬件信任根；固件头校验依赖 CRC 或哈希，只能发现意外损坏，不能抵抗主动篡改；HSM 验签依赖非对称密钥，才是真正抵抗篡改的环节。因此日志中若只看到 CRC 通过而缺少验签记录，不能判定启动链完整。

固件签名验证的实际过程

以 AURIX TC3xx 配合 HSM 的典型流程为例，签名验证包含三个可审计动作。第一步是镜像哈希计算：HSM 对 Flash 中从固件头声明的起始地址到结束地址的镜像区域计算 SHA-256，得到 32 字节摘要。第二步是签名解码：从固件头中取出签名块，使用密钥槽中存储的公钥对签名做验证运算，得到签名中携带的摘要。第三步是比对：将计算摘要与解码摘要逐字节比较，一致则置验签通过标志，否则置失败标志并记录原因码。

审计时最值得关注的是“验签输入是否与运行镜像一致”。如果攻击者替换了 Flash 中的镜像但保留了旧签名，哈希比对必然失败；如果攻击者同时替换镜像与签名，但没有对应私钥，验签运算会失败。因此日志中应能区分“哈希不匹配”和“签名无效”两类原因码，前者指向镜像被改，后者指向签名被伪造或密钥槽被替换。

启动失败与篡改检测的判据

启动失败并不等于篡改。审计需要把失败原因分成三类：配置类失败（启动模式引脚错误、固件头长度非法）、完整性类失败（CRC 不匹配、哈希不匹配）、真实性类失败（验签失败、公钥标识未知）。配置类失败通常是产线或现场误操作；完整性类失败可能是 Flash 位翻转或刷写中断；真实性类失败才高度指向主动篡改。

篡改检测的另一个重要判据是“启动路径异常”。例如系统本应从内部 Flash 启动，却因 HWCFG 引脚被拉高而进入外部启动或调试启动；或者启动日志中出现多次复位循环，且每次都在同一阶段失败。这类模式比单次失败更有取证价值，因为它说明存在持续性的干预行为。

注意：CRC 通过不能作为“未被篡改”的证据。CRC 是线性校验，攻击者修改镜像后可以重新计算 CRC 并写回固件头。只有 HSM 验签通过，才能作为真实性判据。

启动日志提取方法

AURIX 的启动日志通常不存放在单一位置，而是分散在多个可读区域。审计提取时可按以下顺序操作：

读取复位原因寄存器，确认本次启动是上电复位、看门狗复位还是软件复位，这是日志的起点。
读取启动模式寄存器或 HWCFG 采样值，确认实际启动路径与预期是否一致。
通过 HSM 接口读取验签状态寄存器和失败原因码，记录使用的密钥槽编号。
读取 BootROM 或用户固件维护的启动日志缓冲区，通常包含阶段编号、结果码和递增的启动计数。
若系统支持，通过调试接口或 HSM 安全通道导出日志区，避免直接读取被篡改的普通 Flash 区域。

提取时要注意日志的“可信边界”：如果日志本身存放在可被应用改写的 Flash 区域，其可信度低于 HSM 内部寄存器中的状态。审计报告应标注每条证据的来源和可信级别。

日志分析方法与示例

拿到日志后，分析方法可以归纳为“对齐—比对—关联”三步。对齐是把日志条目按启动计数和时间顺序排列；比对是把每次启动的阶段结果与预期基线比较；关联是把失败原因码与复位原因、启动模式、密钥槽状态关联起来，判断是否存在人为干预。

下面是一段示例日志片段（示例数据，用于说明分析方法，非实测结果）：

boot_count=0042  reset=POR   mode=internal_flash
stage1_bootrom   result=OK
stage2_fw_header result=OK   crc=0x8A3F
stage3_hsm_verify result=FAIL reason=HASH_MISMATCH keyslot=2
stage4_app       result=SKIPPED
action=enter_safe_state

boot_count=0043  reset=WDT   mode=internal_flash
stage1_bootrom   result=OK
stage2_fw_header result=OK   crc=0x8A3F
stage3_hsm_verify result=FAIL reason=HASH_MISMATCH keyslot=2
stage4_app       result=SKIPPED
action=enter_safe_state

分析这段日志：两次启动都在 stage3 以 HASH_MISMATCH 失败，且 CRC 相同、密钥槽相同，说明镜像区域被修改但固件头 CRC 未同步更新，或者修改发生在 CRC 覆盖范围之外。第二次复位原因是看门狗，说明系统进入安全状态后未能正常喂狗。结合“连续两次同一阶段失败”，可以判定这不是偶发位翻转，而是持续性篡改或刷写不完整。审计结论应指向：镜像完整性被破坏，需重新刷写并核查刷写工具与流程。

建立基线是日志分析的前提。建议在产线首次刷写后记录一次“黄金启动日志”，包含各阶段结果码、密钥槽编号和启动计数初值，后续审计以此为参照比对。

把上述内容串起来，AURIX 安全启动链审计的落点就是：用阶段划分确定审计对象，用验签过程确定真实性判据，用失败分类区分误操作与篡改，用日志提取与对齐比对形成可追溯的证据链。四者缺一，审计结论都会失去支撑。