安全启动

前言：为什么 MCU 也需要可信启动链 过去做单片机项目，很多团队把安全问题理解成“通信加个 TLS”“升级包做个 CRC”或者“调试口量产时关掉”。这些措施当然有价值，但如果设备会联网、会远程升级、会保存业务密钥，真正的风险往往出现在更早的启动阶段：攻击者能不能替换 Bootloader？能不能刷入旧版本固件重新打开已经修复的漏洞？能不能通过普通应用区读出密钥？能不能在升级断电后把设备卡成砖？ ARM Cortex-M23、Cortex-M33、Cortex-M35P、Cortex-M55 等内核引入的 TrustZone-M，正是为这些问题准备的一套硬件隔离基础设施。它不像服务器上的虚拟化那样厚重，也不是简单的软件权限判断，而是把整个地址空间、外设访问、中断入口和函数调用边界都划分成 Secure 与 Non-secure 两个世界。安全世界负责根信任、密钥、签名校验、回滚计数和少量可信服务；普通世界继续运行原有业务逻辑，例如传感器采集、协议栈、UI、云端连接和控制算法。 这篇文章不追求把 ARM 架构手册逐页复述，而是从一个真实产品视角出发，设计一条可落地的 TrustZone-M 安全启动与 OTA 链路。目标设备可以是带 Cortex-M33 的无线 MCU，也可以是安全要求较高的工业控制板。我们会讨论分区怎么切、密钥放在哪里、启动时校验什么、升级包如何设计、回滚防护如何做，以及调试和量产阶段最容易踩的坑。 一、TrustZone-M 的基本模型 TrustZone-M 的核心是“安全属性”。CPU 取指、读写内存、访问外设、响应中断时，硬件都会判断当前访问属于 Secure 还是 Non-secure。这个属性不是单靠软件变量维护，而是由 SAU（Security Attribution Unit）、IDAU（Implementation Defined Attribution Unit）以及厂商外设安全控制器共同决定。简单说，SAU 更像内核侧的安全地址表，IDAU 则是芯片厂商预先定义的安全属性，例如某些系统寄存器或 OTP 区域天然只能由 Secure 访问。 典型工程会把 Flash 分成 Secure Bootloader、Secure Service、Non-secure App、OTA Slot、Scratch 或 Trailer 几类区域。Secure Bootloader 最先运行，负责配置时钟、最小外设、安全属性和镜像验证；Secure Service 提供少量可被普通应用调用的安全接口，例如读取设备证书摘要、发起签名验签、获取随机数、更新回滚计数；Non-secure App 是业务主程序，绝大部分代码都放在这里；OTA Slot 保存待升级镜像；Scratch 或 Trailer 用来记录升级状态、断电恢复信息和镜像确认标志。 与普通 MPU 的区别在于，TrustZone-M 不只是“禁止某段代码访问某段内存”。它还定义了跨世界调用方式。Secure 代码可以主动跳转到 Non-secure；Non-secure 如果要调用安全服务，只能进入被标记为 Non-secure Callable 的小入口，也就是 NSC veneer。这个入口通常非常薄，只做参数检查和转发，真正的密钥操作仍在 Secure 内部完成。这样做的好处是普通应用拿不到安全函数的任意入口地址，也无法随意跳进安全代码中间执行。...