4. AURIX Bootloader功能安全与信息安全需求
在量产刷写系统中，Bootloader 不只是“把程序写进 Flash”的工具，它同时承担着功能安全与信息安全的第一道闸门。对 AURIX 这类面向动力、底盘、域控的高安全 MCU 而言，刷写过程一旦被非法中断、篡改或写入错误镜像，后果可能直接触及整车安全目标。因此，本节从 ISO 26262、ISO 21434 以及 SHE/HSM 三个视角，定义刷写安全等级、访问权限、密钥管理与防篡改要求，并给出可落地的设计约束。
一、ISO 26262：刷写过程的功能安全边界
ISO 26262 关注的是“功能异常导致危害”的风险。Bootloader 本身通常不实现车辆功能，但它决定了应用软件是否完整、是否可被正确激活。因此，刷写安全需求应围绕完整性、原子性、可恢复性三条主线展开。
完整性要求写入的镜像与原始发布版本逐字节一致，通常通过 CRC32 或 SHA-256 校验实现。原子性要求刷写过程中掉电或复位不会留下“半新半旧”的无效程序。AURIX 的 PFlash 支持按 Sector 擦除、按 Page 编程，Bootloader 必须采用“双区（A/B）或主备+备份区”策略：新镜像先写入非活动区，校验通过后再切换激活标志。可恢复性要求任何失败都能回到已知可运行状态，例如保留出厂 Bootloader 与最小通信栈，确保即使应用区全空也能重新进入刷写模式。
从 ASIL 角度看，刷写功能本身可按 QM 处理，但它所保护的应用若为 ASIL B/D，则刷写校验与激活逻辑应继承相应完整性等级。典型做法是：镜像头包含长度、版本、目标地址、CRC 与签名；Bootloader 在跳转前完成全部校验，任一失败即拒绝跳转并停留在刷写模式。
二、ISO 21434：刷写链路的网络安全要求
ISO 21434 将刷写视为“软件更新”这一攻击面。威胁包括：伪造诊断请求、重放旧版本、篡改镜像、降级攻击、未授权访问。对应的安全属性是真实性、完整性、新鲜性、机密性与授权。
真实性通过数字签名保证：OEM 私钥签名镜像，ECU 内预置公钥或公钥证书链验证。完整性由签名与哈希共同覆盖。新鲜性通过单调递增的版本号或防回滚计数器实现，拒绝低于当前版本的镜像。机密性在需要保护标定数据或算法时，可对镜像加密后再签名。授权则要求刷写前完成安全访问（Security Access）解锁，且不同权限对应不同操作范围。
magic(4B) | version(4B) | length(4B) | loadAddr(4B) | crc32(4B) | signAlgo(1B) | reserved(3B) | signature(64B)。Bootloader 先校验 magic 与 length 合法性，再算 CRC32，最后用 ECDSA P-256 验签。只有全部通过才允许写入激活标志。
三、SHE/HSM：密钥管理与硬件信任根
AURIX 的 HSM（Hardware Security Module）与 SHE（Secure Hardware Extension）为刷写提供硬件级密钥保护与加解密加速。SHE 定义了一组密钥槽（Key Slot），每个槽有独立权限，如 BOOT_PROTECTION、DEBUG_PROTECTION、KEY_USAGE。刷写相关密钥通常包括：
- Master Key（MASTER_ECU_KEY）：用于更新其他密钥，必须一次性烧录并锁定。
- Boot MAC Key / Boot Key：用于验证 Bootloader 或镜像的 MAC/签名。
- RAM Key：用于安全访问解锁时的挑战响应。
- User Key：用于应用层安全通信或标定数据保护。
密钥管理要求：私钥永不离开 HSM 或 OEM 签名服务器；ECU 内只存公钥或对称密钥的受保护副本；密钥更新必须经过认证且支持撤销。SHE 的 SECURE_BOOT 功能可在复位时由硬件校验 Bootloader 的 MAC，失败则禁止执行，这构成信任根。
四、刷写安全等级与访问权限矩阵
将上述要求落地，需要定义分级权限。下表给出一种可参考的等级划分（示例，非实测）：
| 等级 | 访问权限 | 认证方式 | 可执行操作 |
|---|---|---|---|
| L0 公开 | 无 | 无 | 读取版本号、进入默认会话 |
| L1 诊断 | 基础 | 会话切换 | 读取 DTC、读取刷写状态 |
| L2 刷写 | 编程 | Security Access 挑战响应 | 擦除、写入、校验应用区 |
| L3 密钥 | 安全 | HSM 认证 + 签名 | 更新密钥、切换激活区、解锁调试 |
权限提升必须逐级进行，且每次提升都有超时与失败计数。连续失败达到阈值后锁定一段时间，防止暴力破解。
五、防篡改与状态机约束
防篡改不仅是“验签”，还包括运行时的状态约束。Bootloader 应维护一个刷写状态机，典型状态包括：IDLE、UNLOCKED、ERASING、PROGRAMMING、VERIFYING、ACTIVATING、ROLLBACK。任何非法跳转（如未解锁直接写 Flash）都应被拒绝并记录安全事件。
此外，调试接口（JTAG/DAP）在量产件上必须锁定，解锁需 L3 权限与签名授权。若检测到签名失败、版本回滚或 CRC 错误，系统应停留在安全状态，不跳转应用，并可通过诊断上报事件码。
综合来看，AURIX Bootloader 的安全设计不是单一机制，而是“功能安全保底 + 网络安全防攻击 + 硬件信任根保密钥”的三层叠加。量产刷写系统应把上述等级、权限、密钥与防篡改要求固化为可测试的需求条目，并在产线端与售后端分别验证：产线关注效率与防误写，售后关注防伪造与防降级。只有把安全等级与访问权限真正映射到状态机和密钥槽，刷写系统才具备可量产、可审计、可恢复的工程属性。