4. 安全启动链的信任根设计
安全启动链的可信性并不来自“启动过程本身”，而来自一个无法被后续软件改写、也无法被攻击者替换的起点。这个起点就是信任根（Root of Trust, RoT）。在 AURIX 这类面向功能安全的 MCU 上，信任根通常由三部分共同构成：固化在芯片制造阶段的不可变 ROM 代码、上电后最先执行的 BootROM 验证逻辑，以及被永久烧写或受硬件保护的信任根密钥与证书。三者缺一不可：ROM 提供“不可改”的代码载体，BootROM 提供“先验证再放行”的执行顺序，密钥与证书提供“凭什么相信下一级”的密码学依据。
一、不可变 ROM 代码：信任根的物理载体
不可变 ROM 代码是在芯片流片时通过掩膜写入的，出厂后既不能擦除也不能重写。它通常只承担最小职责：初始化最基础的时钟与内部 SRAM、建立安全启动所需的执行环境、读取并校验第一级用户代码（如 Flash 中的 Bootloader 或 HSM 固件），然后把控制权交出去。之所以强调“最小”，是因为 ROM 一旦流片就无法修补，代码越少、逻辑越简单，存在漏洞的概率越低，审计也越容易。
在 AURIX 的典型实现中，上电复位后 CPU 从固定的 BootROM 入口地址取指，此时用户 Flash 尚未被信任。ROM 会先检查启动模式引脚或启动配置，判断当前是正常启动、调试启动还是引导加载模式，再决定是否进入安全校验路径。需要特别注意的是：ROM 代码本身不包含业务逻辑，它只负责“把信任传递下去”，因此它的正确性完全依赖流片前的形式化审查与硅后测试。
二、BootROM 验证逻辑：先验证，后放行
BootROM 的验证逻辑是信任链真正“动起来”的地方。其核心思想是：在把控制权交给任何可写介质中的代码之前，先用固化在芯片内的公钥验证该代码的签名。典型流程如下：
- BootROM 从 Flash 固定偏移处读取第一级引导镜像的头部，解析出版本、长度、签名算法标识和签名值。
- 用固化在芯片内的信任根公钥（或公钥哈希）验证镜像头部的真实性，确认镜像未被篡改。
- 计算镜像主体的密码学摘要（如 SHA-256），并与签名解密后得到的摘要比对。
- 校验通过后，将控制权交给该镜像；校验失败则进入安全失败状态，例如停留在 BootROM、触发复位循环或进入受限的恢复模式。
这里有一个容易被忽视的细节：BootROM 必须验证“镜像头部”本身，否则攻击者可以替换头部中的长度或算法字段，诱导验证逻辑跳过部分代码。因此，头部通常也被纳入签名覆盖范围，形成“头部+主体”整体签名。此外，BootROM 还应校验镜像的版本号，防止攻击者用旧版本固件实施回滚攻击。
三、信任根密钥与证书的固化方式
信任根密钥的固化方式直接决定了整个信任链的安全边界。常见做法有三类：
- 公钥哈希固化：将信任根公钥的哈希值烧写在芯片的一次性可编程（OTP）区域或受保护的 Flash 中。BootROM 启动时先计算公钥哈希并与固化值比对，一致后才使用该公钥验签。这种方式不需要在芯片内保存完整公钥，节省空间，且哈希不可逆，攻击者无法从哈希反推公钥。
- 完整公钥固化：将信任根公钥直接写入 ROM 或 OTP。优点是启动时无需额外哈希比对，缺点是公钥占用空间较大，且一旦需要更换密钥，芯片无法复用。
- 证书链固化：芯片内只固化根证书或根公钥，第一级引导镜像携带由根密钥签发的证书。BootROM 用根公钥验证证书，再用证书中的公钥验证镜像。这种方式支持密钥分层，便于量产时对不同批次使用不同的签名密钥，但要求 BootROM 具备解析证书的能力。
无论采用哪种方式，信任根密钥的私钥都必须存放在受控的签名服务器或硬件安全模块（HSM）中，绝不能出现在芯片或产线电脑上。量产签名时，通常由 HSM 对镜像摘要进行签名，签名结果与镜像一起烧录。对于 AURIX 的 HSM（Hardware Security Module）子系统，还可以将部分信任根密钥存放在 HSM 的受保护存储区，由 HSM 固件在启动早期完成校验，形成“主核 BootROM + HSM”双信任根结构。
四、信任根设计的工程要点
在实际项目中，信任根设计需要重点考虑以下几点。第一，密钥生命周期管理：信任根密钥一旦烧录就无法更改，因此必须在量产前完成密钥生成、备份和归档，并制定密钥吊销与芯片更换策略。第二，OTP 区域的访问控制：固化公钥哈希的 OTP 区域必须设置为仅 BootROM 可读，用户代码和调试接口均不可访问，防止侧信道或调试通道泄露。第三，启动失败策略：校验失败后不能简单死循环，而应进入可诊断的安全状态，例如通过 HSM 记录失败原因、点亮故障指示灯或进入受限的恢复模式，便于产线排查和售后分析。第四，与 HSM 的协同：AURIX 的 HSM 可以在主核启动前独立完成自身固件的校验，形成双信任根，主核 BootROM 再验证 HSM 固件的签名，两者互相约束。
最后需要强调的是，信任根不是“一次性配置完成”的静态对象，而是需要在整个产品生命周期中持续维护的安全资产。密钥轮换、固件升级、产线烧录和售后诊断都会与信任根发生交互，因此从架构设计阶段就应把信任根纳入整体安全方案，而不是等到量产前才临时补上。