2. STM32N6硬件安全基础

STM32N6 的安全启动与固件升级并不是纯软件协议，它首先建立在芯片内部一组硬件安全资源之上。理解这些资源的位置、职责和相互约束，才能判断“密钥放哪里、镜像由谁验、外设归谁管、失败后停在哪”。本节围绕五个对象展开：芯片级安全特性、启动 ROM（BootROM）、安全存储区、TrustZone 与资源隔离机制。它们共同构成一条从复位到应用运行的信任链基础。

一、芯片级安全特性：信任的根从哪里来

STM32N6 属于带 Arm Cortex-M55 与 NPU 的高性能 MCU，其安全能力由若干硬件模块协同提供，而不是单一模块完成。典型组成包括：

• 安全启动 ROM：芯片出厂固化、不可修改的引导代码，是信任链的起点。
• OTP（一次性可编程）区域：存放生命周期状态、启动策略、根密钥摘要或使能位，写入后不可回退。
• 安全密钥存储：用于保存对称密钥、私钥或密钥句柄，受访问控制保护。
• 硬件密码加速器：AES、SHA、PKA/ECC 等，用于验签、解密和摘要计算。
• TrustZone 与 MPU/SAU：把代码、数据和外设划分为安全与非安全两个世界。
• 防回滚与生命周期管理：通过版本计数器和调试口控制，限制降级与非法调试。

这些特性中，OTP 与 BootROM 是“不可改”的部分，密钥存储与 TrustZone 配置是“可配置但受保护”的部分。设计安全方案时，第一步不是写代码，而是确定哪些信息必须固化、哪些可以更新、哪些一旦写入就不可撤销。

二、启动 ROM：复位后的第一段可信代码

芯片复位后，CPU 首先执行的是 BootROM。它不依赖外部 Flash，也不依赖用户代码，因此可以作为信任根。BootROM 的典型职责是：读取启动模式引脚与 OTP 中的启动策略，初始化必要的安全外设，从指定接口（如外部 Flash、SD、USB 或内部 SRAM）加载镜像头，验证签名与完整性，然后决定是否跳转到用户代码。

验证过程通常遵循“先验头、再验体”的顺序：镜像头中包含版本号、长度、算法标识和签名；BootROM 用 OTP 中固化的根公钥或密钥摘要验证头部签名，确认头部可信后，再用头部中的信息验证镜像体。若验证失败，BootROM 不会跳转到用户代码，而是进入错误状态或等待恢复接口。这一“失败即停”的行为，是安全启动与普通启动最本质的区别。

三、安全存储区：密钥与敏感数据放在哪里

安全存储区并不是一块普通 Flash，而是由 OTP、受保护 SRAM 和密钥管理单元共同构成的逻辑区域。它的核心约束是：非安全世界不能直接读取，安全世界也只能通过受控接口访问。实际设计中，常见的存放策略是：

• 根公钥摘要：写入 OTP，不可更改，用于验证镜像头签名。
• 对称密钥：存入安全密钥存储，由硬件加密引擎直接引用，CPU 不直接读出明文。
• 设备唯一密钥：由芯片 RNG 或 PUF 派生，用于会话密钥协商。
• 版本计数器：记录已接受的最低固件版本，防止回滚到旧漏洞版本。

需要特别注意的是，OTP 写入不可逆。量产阶段一旦把调试口关闭或把启动策略锁定，后续就无法通过常规手段恢复。因此，安全存储区的规划必须在开发早期完成，并在样机阶段验证写入顺序。

四、TrustZone 与资源隔离：两个世界的边界

TrustZone 把系统划分为安全世界（Secure）和非安全世界（Non-Secure）。STM32N6 通过 SAU（Security Attribution Unit）和 MPU 定义内存区域属性，通过 TZSC（TrustZone Security Controller）定义外设的安全属性。典型配置如下：

隔离机制的价值在于：即使非安全应用被攻破，攻击者也无法直接读取密钥或篡改安全服务。安全世界通过受控接口（如安全调用）向非安全世界提供服务，接口参数需要严格校验，避免把安全能力暴露成任意读写通道。

五、把硬件基础落到配置动作上

在具体工程中，上述硬件基础会转化为几项可执行的配置动作。以下示例参数仅用于说明配置思路，实际值需以芯片参考手册和项目安全策略为准：

// 示例：SAU 区域配置思路（参数为教学示例）
SAU->RBAR = 0x0C000000;   // 安全 SRAM 起始
SAU->RLAR = 0x0C00FFFF;   // 安全 SRAM 结束，使能区域
SAU->RBAR = 0x20000000;   // 非安全 SRAM 起始
SAU->RLAR = 0x2001FFFF;   // 非安全 SRAM 结束

// 示例：TZSC 外设安全属性
TZSC->SECCFGR |= RNG_SEC | PKA_SEC | SAES_SEC;
TZSC->SECCFGR &= ~(UART1_SEC | USB_SEC);  // 保持非安全

// 示例：OTP 启动策略写入（不可逆，仅示意）
OTP->BOOT_CFG = SECURE_BOOT_EN | DEBUG_LOCK;
OTP->ROOT_KEY_HASH = sha256(root_public_key);

配置完成后，判断是否生效的依据不是“代码是否编译通过”，而是观察启动行为：复位后是否先进入 BootROM、镜像验证失败时是否停在错误状态、非安全代码访问安全外设时是否触发安全异常。这些现象才是硬件安全基础真正起作用的证据。

总结来看，STM32N6 的硬件安全基础可以理解为一条从“不可改的 BootROM 与 OTP”出发，经过“受保护的密钥存储”，最终落到“TrustZone 隔离边界”的信任结构。启动 ROM 决定镜像是否可信，安全存储区决定密钥是否可用，TrustZone 决定资源是否可越界。三者缺一，安全启动与固件升级就失去了硬件支撑。