2. AURIX硬件安全基础

在AURIX平台上做安全OTA，第一步不是写升级协议，而是先弄清芯片内部有哪些“不可绕过的硬件规则”。这些规则决定了密钥放在哪里、固件由谁验签、哪些Flash区域可以被改写、升级失败后能否回滚。本节围绕HSM、SHE、TRNG、安全启动链、Flash保护、UCB与DFlash六个对象展开，并落到它们对OTA升级的具体约束上。

HSM与SHE：两个不同层级的安全执行环境

AURIX的HSM（Hardware Security Module）是一个独立于主核的安全子系统，通常包含独立的CPU、RAM、ROM、定时器和密码加速器，通过共享内存或邮箱与主核通信。它的关键价值在于：密钥和验签逻辑运行在与应用核隔离的域内，主核即使被攻破，也无法直接读取HSM内部密钥。OTA升级中，HSM承担镜像验签、密钥派生、安全计数器和访问授权判断。

SHE（Secure Hardware Extension）则更接近一个轻量级安全规范，定义了密钥槽、命令集和基于AES-128的CMAC/Miyaguchi-Preneel压缩结构。在AURIX上，SHE功能可以由HSM实现，也可以由专门的SHE模块提供。SHE的密钥槽数量有限（典型为10个或更多，取决于配置），每个槽有固定的用途属性，例如MASTER_ECU_KEY、BOOT_MAC_KEY、KEY_1到KEY_N。OTA升级若使用SHE做镜像认证，必须提前规划：哪个槽放验签密钥、哪个槽放解密密钥、哪个槽用于更新授权，且槽一旦写入通常不可明文读回。

TRNG：安全启动与密钥生成的熵源

TRNG（True Random Number Generator）为AURIX提供真随机数，用于生成会话密钥、挑战值、nonce和密钥材料。它与伪随机数发生器（PRNG）的区别在于熵源来自物理噪声，而不是确定性算法。OTA升级中，TRNG的典型用途包括：升级会话的随机挑战、AES密钥的随机生成、安全启动时的随机化校验。若TRNG未就绪或健康检查失败，安全启动链可能拒绝进入安全状态，OTA升级也会被阻断。因此，在升级流程开始前，固件应检查TRNG状态寄存器，确认熵源可用。

安全启动链：从BootROM到应用核的逐级信任

AURIX的安全启动链通常从BootROM开始，依次验证HSM固件、主核启动代码、应用固件。每一级在跳转前，用上一级提供的公钥或哈希对下一级镜像做验签或CMAC校验。验证通过后，才把控制权交给下一级。这个链条的关键约束是：OTA升级后的镜像必须仍然满足每一级的验签规则。如果升级只改了应用固件，但应用固件的签名密钥与BootROM中固化的公钥不匹配，启动会在验签阶段失败，芯片可能进入恢复模式或停止启动。

Flash保护机制：PFlash与DFlash的写入门槛

AURIX的Flash分为PFlash（程序Flash）和DFlash（数据Flash）。PFlash存放启动代码和应用固件，DFlash存放UCB、配置数据和备份镜像。Flash保护通过写保护寄存器、安全端和HSM访问权限共同实现。OTA升级要改写PFlash中的应用固件，必须先满足以下条件：目标扇区未被永久写保护；当前运行模式允许擦写；HSM或安全端授权了写操作。若某扇区被配置为永久保护，OTA无法覆盖它，只能通过备份镜像或外部更新方式处理。

DFlash中的UCB（User Configuration Block）是OTA升级中最容易被忽视、却最关键的约束来源。UCB存放启动模式、Flash保护配置、HSM使能状态、调试接口权限等。UCB通常有多个副本，写入时需要同时更新并校验，否则芯片可能进入不可启动状态。OTA升级若需要修改启动配置，必须通过HSM或安全命令更新UCB，且更新过程不可中断。

对OTA升级的约束汇总

把上述对象放在一起，可以得到几条硬约束：第一，升级镜像的签名密钥必须与BootROM或HSM中已固化的信任根一致，否则验签失败；第二，SHE密钥槽的用途和数量有限，升级方案必须在设计阶段就确定密钥分配；第三，TRNG必须可用，否则会话密钥和挑战值无法生成；第四，PFlash的写保护状态决定哪些区域可被OTA覆盖；第五，UCB的更新必须原子化，且需要HSM授权；第六，DFlash的备份镜像和UCB副本是升级失败后的恢复基础。

一个可参考的升级前置检查清单

这张清单不是固定模板，而是一个检查思路：把“能不能升级”拆成可观察的硬件状态，而不是等到写入失败后再排查。实际项目中，还应结合具体AURIX型号的HSM固件版本、SHE密钥槽定义和UCB布局做细化。只有先尊重这些硬件约束，OTA升级方案才具备可实施性。