1. 项目背景与核心需求解析1.1 这个项目解决什么问题OEMiROT全称是 OEM Immutable Root of Trust属于 STM32Trust 安全框架里的一环。提它之前先问一个问题你的固件烧进芯片之后怎么保证它是可信的怎么防止别人把非法的固件刷进设备里冒充你的产品怎么保证运行时的代码没有被人篡改过传统做法是给产品加一个外部安全芯片或者依赖 MCU 内部唯一的 ID 做简单的校验。但这些方案要么增加 BOM 成本要么强度不够。STM32 家族里带 TrustZone 的芯片比如 STM32C5 这颗基于 Cortex-M33 内核的 MCU内置了专门的安全启动引擎OEMiROT 就是在这个引擎上实现的一套完整方案。OEMiROT 做的事情概括起来有三件一是上电后先验证固件签名确保固件确实是厂商签发的二是通过 TrustZone 把安全资源密钥、安全存储区与普通应用隔离三是支持固件升级时的验签流程防止升级过程被中间人劫持。这套方案最大的价值在于安全启动的根密钥和验证逻辑被放在芯片内置的不可修改区域即使应用代码被完全逆向也无法伪造出合法的固件。1.2 为什么用 STM32C5 做 OEMiROTSTM32C5 是 ST 主推的新一代主流型 MCUCortex-M33 内核带 TrustZone主频能跑到 250MHz。选择它做 OEMiROT 项目有几个现实理由Cortex-M33 原生支持 TrustZone 隔离这是硬件层面的安全基础OEMiROT 需要这种隔离能力来保护密钥和验证逻辑。STM32C5 的 Flash 和 SRAM 容量足够承载双镜像固件应用 A/B 分区 bootloader产品方案容易落地。这颗芯片定位是“安全性能成本”的平衡点比 STM32H5 便宜比 STM32L5 性能强正好适合物联网网关、边缘节点、工业控制器这类对安全有要求但又不希望成本失控的产品。另外ST 的官方固件包STM32CubeC5里已经集成了 OEMiROT 的完整参考例程不需要从零写安全启动逻辑难度大幅降低。你要做的只是学会配置、编译、烧录和验证流程理解它背后的机制然后移植到自己的板子上。1.3 适合谁看这篇如果你是在 STM32 上做产品开发的工程师想把安全启动集成进自己的方案正在用 STM32CubeIDE那么这篇内容就是给你的。阅读之前建议先了解一点 TrustZone 的基础概念知道 secure/non-secure 世界是怎么回事。如果你完全没碰过安全启动也不用慌我会把链路理清楚包括一些容易踩坑的细节。2. OEMiROT 工作原理与整体方案拆解2.1 OEMiROT 的信任根模型要理解 OEMiROT先得理解 ROT 这个概念。ROTRoot of Trust信任根是安全世界里所有信任的起点。它必须满足一个条件自身是不可伪造、不可篡改的。OEMiROT 之所以叫“OEM Immutable”因为它的引导代码BootROM 或不可写的 Flash 区域在芯片出厂时就固定下来或者由厂商在首次烧录后通过 Option Byte 锁定之后任何人都改不了这段代码。OEMiROT 的完整信任链是这样的芯片上电 | v BootROM不可修改加载 OEMiROT 引导代码 | v OEMiROT 校验镜像签名RSA/ECDSA | v 通过 - 加载应用固件启动 TrustZone 隔离 | v 失败 - 进入恢复模式/等待升级OEMiROT 本身是“Immutable Root of Trust”里的一环它负责校验可变区域应用固件的真实性。应用固件内部还可以继续建立自己的信任链比如校验外置 Flash 里的资源文件签名这就形成了完整的链式信任。2.2 镜像签名与验证机制OEMiROT 的验签依赖非对称加密。芯片内置或存储在受保护区域一把公钥厂商持有对应的私钥。固件编译完成后用私钥对固件镜像做签名签名值连同镜像一起烧入芯片。上电后 OEMiROT 从受保护区域读出公钥对镜像做验签。这里的几个关键点公钥存储在不可篡改的区域在 STM32C5 上公钥通常存放在 UFBUser Flash Bank的保留区域或者由 TrustZone 保护的安全存储区。签名算法常见为 RSA-2048 或 ECDSA-P256。ECDSA 签名短、验证快适合嵌入式RSA 兼容性更好很多老的升级链路还在用。反回滚保护固件镜像里带一个版本号OEMiROT 会把它和当前记录在案的最低允许版本比较如果版本比现存的还低就拒绝加载。这是防降级攻击的关键。2.3 安全状态机与生命周期管理OEMiROT 还有一个容易被忽略的部分芯片安全生命周期。STM32 的 TrustZone 芯片内部维护一个三态安全状态Open开放、Closed封闭、Locked锁定。Open 状态下可以自由调试、读写 Flash适合开发阶段。Closed 状态下 TrustZone 的隔离生效非安全世界无法访问安全资源调试接口受限。Locked 状态下安全启动彻底封闭任何外部手段都无法改写安全区内容适合量产。在开发阶段你基本保持在 Open 或 Closed烧录时要注意一旦切到 Closed再想用 ST-Link 调试器全功能访问内核就难了需要先做一次 Full Reset 或者通过专用流程才能回到 Open。这个特性你后面部署 CI 自动烧录时肯定会遇到提前记住。3. 开发环境搭建与 CubeMX 工程配置3.1 工具链版本选择做 OEMiROT 这种安全开发工具链版本非常重要。ST 对安全功能的支持是跟随固件包和 IDE 版本迭代的老版本可能缺功能新版本可能引入行为变更。我的建议是直接装当前主流的稳定版本STM32CubeIDE1.16 或更高。我用的 1.16.1实测稳定。STM32CubeMX6.12 或更高。从 CubeIDE 1.16 开始已经集成了 CubeMX不需要单独装但如果你习惯单独用 CubeMX 生成工程再导入 IDE注意版本别差太多。STM32CubeC5 Firmware PackageV1.0.0 或更新版本。这个包在 CubeMX 里选芯片时会自动下载也可以去 ST 官网手动下载然后导入。注意一点STM32CubeC5 的固件包比较大包含所有外设驱动、中间件和例程。首次下载如果网络不稳定容易失败。解决办法是手动下载 ZIP 包然后在 CubeMX 的 Firmware Package Manager 里从本地导入。3.2 CubeMX 工程初始化要点用 CubeMX 创建 OEMiROT 工程最关键的一步是选对例程目录。不要从空工程开始配置因为 OEMiROT 涉及 TrustZone 工程分区、链接脚本、启动文件等一系列复杂设置手搓容易出问题。正确姿势是直接从固件包里拷贝 OEMiROT 例程然后在 CubeMX 里调整配置。具体的步骤如下打开 STM32CubeMX选择 New Project在 MCU Selector 里搜 STM32C5选具体型号比如 STM32C531R6Tx。如果项目不想从零配可以直接 File - New Project 后选 Example Selector在列表里搜 OEMiROT。ST 在 CubeC5 里提供了OEMiROT_Boot引导工程和OEMiROT_App应用示例两个工程。如果没有看到 Example说明固件包没装全。回到 Help - Manage Embedded Software Packages勾选 STM32CubeC5 并完成安装。选定芯片和例程后CubeMX 会自动生成 TrustZone 相关的工程结构包括 secure 和 non-secure 两个子工程。3.3 TrustZone 内存布局配置OEMiROT 成功运行的一个核心条件内存布局必须正确。CubeMX 会生成默认的 TrustZone 分区但不同板子的 Flash/SRAM 大小不同需要手动核对。在 Project Manager - Linker Settings 里重点检查这几项Secure Flash 起始地址OEMiROT 的 boot 代码通常放在 Flash 起始处的 Secure 区比如 0x0C0000 起始的 64KB 区域。Non-Secure Flash 起始地址应用固件放在 Non-Secure 区比如 0x0D0000 起始。Secure SRAM 与 Non-Secure SRAM 的划分注意 Cortex-M33 的 TrustZone 通过 SAUSecurity Attribution Unit控制地址空间的属性CubeMX 生成的配置脚本会处理好但你要确认 SRAM 分界的起始地址没有重叠。提示Debug 配置下 ST-Link 烧录时如果地址配置和链接脚本不一致最常见的表现是烧录成功但一运行就进 HardFault。排查第一步永远是核对内存地址。3.4 生成工程并导入 CubeIDECubeMX 配置完成后点击右上角的 GENERATE CODE选择 Toolchain 为 STM32CubeIDE指定工程名和路径。生成完成后先用 CubeIDE 打开工程。这时你会看到工程里有两个子项目OEMiROT_Boot安全引导工程编译生成 bootloader。OEMiROT_App应用工程编译生成用户应用固件。注意这两个工程是关联的编译顺序有讲究。先编译 boot再编译 app最后烧录时也是先烧 boot再烧 app。CubeIDE 会把两个工程都放进 workspace但你需要手动切换 active project。4. 核心实操编译、烧录与验证全流程4.1 配置密钥与签名工具OEMiROT 的根密钥是整个安全方案的心脏。ST 的例程里已经生成了测试密钥对位于固件包的Middlewares/ST/STM32_TRUSTZONE/OEMiROT/Keys目录下OEMiROT_Boot_private.pem私钥用于签名固件。OEMiROT_Boot_public.pem公钥会被编译进 bootloader用于验证固件签名。OEMiROT_Boot_public.pem对应的.der或.c文件转换格式后嵌入工程。开发阶段直接用 ST 提供的测试密钥没问题但量产前一定要替换成自己生成的密钥对。用 OpenSSL 生成 ECDSA 密钥的命令openssl ecparam -name prime256v1 -genkey -noout -out OEMiROT_Boot_private.pem openssl ec -in OEMiROT_Boot_private.pem -pubout -out OEMiROT_Boot_public.pem生成新密钥后需要把公钥转换成 C 数组并替换工程中的key.c文件。具体格式可以参考 ST 例程自带的转换脚本执行一次替换后要重新编译 boot。4.2 编译步骤与参数设置编译前把 CubeIDE 的 active project 切到OEMiROT_Boot然后 Project - Build。编译过程中如果报错先看是不是密钥文件路径问题再排查是不是链接脚本和内存配置不一致。Boot 编译成功之后切到OEMiROT_App编译应用工程。这里有个关键点应用工程的镜像需要先生成带签名的烧录文件。CubeIDE 的 build 步骤会自动调用 STM32CubeProgrammer 的签名工具完成签名前提是你在工程属性里配置了 Post-build 命令。在OEMiROT_App的 Project Properties - C/C Build - Settings - Build Steps - Post-build steps 里确认里面的签名命令正确。典型命令长这样STM32_Signing_Tool_CLI.exe -s OEMiROT_Boot_private.pem -a 0x0D0000 -d app.bin -o app_signed.bin参数含义-s指定私钥-a指定应用固件的加载地址必须和链接脚本里的 Non-Secure Flash 起始地址一致-d输入 bin 文件-o输出签名后的 bin 文件4.3 烧录顺序与操作细节烧录工具推荐用 STM32CubeProgrammer图形界面和命令行都可以。命令行方式适合脚本化我实际量产用的就是命令行方式。第一块板子建议按以下顺序操作先烧录 bootloader。把 CubeIDE 的 debug configuration 指到 boot 工程的 elf 文件用 ST-Link 烧录。用 STM32CubeProgrammer 烧录签名后的应用固件STM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -w app_signed.bin 0x0D0000验证烧录是否正确STM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -r8 0x0D0000 16如果一切正常复位后 LED 按应用代码逻辑闪烁说明安全启动链路已经跑通。4.4 验证 OEMiROT 是否真的在起作用这里有个很容易犯的错误烧录成功、代码能跑就以为 OEMiROT 生效了。错误的认知。你需要主动做一次负向测试。操作方法用随便一个文本编辑器打开 app_signed.bin修改其中一个字节比如把 0x00 改成 0xFF保存后重新烧录。然后复位看现象如果 OLEDiROT 拒绝启动LED 不闪说明验签真的在工作。如果代码照样跑说明你烧的固件没走 OEMiROT 路径问题出在启动配置上。这个测试我每次切板子型号后都会做一遍花两分钟能省掉后面一堆排查时间。5. 常见问题与排查技巧实录5.1 启动失败LED 不亮代码没跑排查这类问题不要急着看应用代码先从链路源头查。我自己的排查顺序是用 STM32CubeProgrammer 读取芯片的状态和当前启动地址确认 boot 有没有执行。确认 Option Bytes 配置OEMiROT 要求TZEN1、DBANK1、SECBOOT1任何一个不对都会卡在启动早期。确认 boot 工程里链接的公钥和签名用的私钥是对应的。测试密钥替换场景最容易犯这个错。用调试器在 boot 的验签函数入口打断点逐步看是走到验签失败分支还是根本没进到验签逻辑。注意如果芯片已经切到 Closed 状态调试器访问受限需要先做一次全擦除回到 Open 状态才能继续调试。5.2 签名校验失败的典型原因验签失败是安全启动项目里最常见的错误。我整理了一份速查表现象可能原因检查方法一直卡在 boot 不进 app公钥和私钥不匹配重新生成密钥对确认 boot 和签名用的是同一对启动偶尔成功偶尔失败烧录地址不对核对 app 的链接地址与烧录命令地址升级后无法启动反回滚版本号比当前低更新固件版本号确认版本号单调递增烧录后校验失败bin 文件没有签名确认 Post-build 命令正确执行烧录的是签名后的文件5.3 调试接口被锁定怎么办安全项目的必然结果随着安全状态推进调试口会越来越难访问。我在用 STM32C5 的早期阶段就把两块板子的调试口锁死过当时以为芯片废了其实有解。恢复方法使用 STM32CubeProgrammer 的 HOTPLUG 模式连接在复位向量处做 mass erase。前提是芯片还没到 Locked 状态。如果已经 Locked只能通过 boot 引脚进入系统 bootloader 模式再用 UART 或 USB DFU 做全擦除。这个流程建议你在开发板上一开始就测通否则量产阶段遇到问题会非常被动。5.4 CubeIDE 编译报依赖错误的处理OEMiROT 例程涉及两个子工程互相引用头文件和库CubeIDE 的 build 顺序配置一旦丢了就会报各种找不到符号的错误。处理方法右键 boot 工程 - Properties - C/C Build - Project References勾选依赖的 app 工程反过来 app 工程也要勾选依赖的 boot 工程。两边都勾好后Clean 一次重新 Build。另外建议把 cubeide 的 build 并发线程数调低Window - Preferences - C/C - Build - Jobs避免多线程编译时乱序导致路径解析异常。6. 量产准备与脚本化发布6.1 替换量产密钥并重新编译全链路工程项目验证通过后第一件事就是替换测试密钥。这个操作不复杂但涉及面广容易遗漏生成新密钥对ECDSA P-256 或 RSA-2048。把新公钥转换成 C 数组文件替换 boot 工程里旧的key.c。重新编译 boot 和 app。把新私钥放到签名工具调用的固定路径更新 Post-build 命令里的私钥路径。全链路的固件重新签名重新烧录验证。替换密钥后旧签名固件在新 boot 下会验签失败这是预期行为。6.2 用脚本固化烧录流程到了要烧几十块板子的时候手工操作 STM32CubeProgrammer 太慢了。我把整个烧录流程写成批处理核心逻辑分三步烧录 bootSTM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -w OEMiROT_Boot.elf烧录签名 appSTM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -w app_signed.bin 0x0D0000配置 Option Byte 切到 Closed 状态STM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -ob TZEN1 DBANK1 SECBOOT1注意Option Byte 的写入要放在所有烧录动作之后一旦写入 Closed后续调试接口受限所以这个动作要设计成单独的脚本步骤来执行。6.3 生产环境下的反回滚策略反回滚做得好不好直接决定产品的可维护性。OEMiROT 的版本号机制我建议这样设计开发阶段版本号从 0 开始每发一版 1。量产前的 final 版本版本号抬高到 100 以上给后面留足空间。生产线的固件版本号固定不跟随日常开发版本递增。原因是一旦某个版本在产线上被批量烧录反回滚机制会拒绝低于当前版本号的固件回刷。如果版本号规划不好后期想修复 bug 却发不了新版就只能全部返厂成本极高。7. 一点个人经验总结做了几年的 STM32 安全启动方案我的感受是OEMiROT 的难点不在“跑通”而在“想清楚”。跑通只需要跟着例程走一遍想清楚却需要理解安全模型、密钥管理、生命周期管理这些底层逻辑。STM32C5 上跑 OEMiROT 整体体验比老平台顺畅很多CubeIDE 的集成度高CubeMX 生成的工程结构干净出错率低。最后再分享一个实际操作中的小技巧OEMiROT 工程第一次跑通后马上把整个 workspace 打一个 zip 备份注释里写上日期和芯片型号。后面每次调整配置或换板子都从这个基线开始而不是从最新的工程状态开始。这能帮你避免很多“改了一堆东西最后不知道哪一步把链路搞坏了”的窘境。安全启动这种东西一旦遇到问题排查链路非常长有一个干净基线在手很多问题都能快速对照出差异来。
STM32C5 OEMiROT安全启动完整实战：从原理到量产
1. 项目背景与核心需求解析1.1 这个项目解决什么问题OEMiROT全称是 OEM Immutable Root of Trust属于 STM32Trust 安全框架里的一环。提它之前先问一个问题你的固件烧进芯片之后怎么保证它是可信的怎么防止别人把非法的固件刷进设备里冒充你的产品怎么保证运行时的代码没有被人篡改过传统做法是给产品加一个外部安全芯片或者依赖 MCU 内部唯一的 ID 做简单的校验。但这些方案要么增加 BOM 成本要么强度不够。STM32 家族里带 TrustZone 的芯片比如 STM32C5 这颗基于 Cortex-M33 内核的 MCU内置了专门的安全启动引擎OEMiROT 就是在这个引擎上实现的一套完整方案。OEMiROT 做的事情概括起来有三件一是上电后先验证固件签名确保固件确实是厂商签发的二是通过 TrustZone 把安全资源密钥、安全存储区与普通应用隔离三是支持固件升级时的验签流程防止升级过程被中间人劫持。这套方案最大的价值在于安全启动的根密钥和验证逻辑被放在芯片内置的不可修改区域即使应用代码被完全逆向也无法伪造出合法的固件。1.2 为什么用 STM32C5 做 OEMiROTSTM32C5 是 ST 主推的新一代主流型 MCUCortex-M33 内核带 TrustZone主频能跑到 250MHz。选择它做 OEMiROT 项目有几个现实理由Cortex-M33 原生支持 TrustZone 隔离这是硬件层面的安全基础OEMiROT 需要这种隔离能力来保护密钥和验证逻辑。STM32C5 的 Flash 和 SRAM 容量足够承载双镜像固件应用 A/B 分区 bootloader产品方案容易落地。这颗芯片定位是“安全性能成本”的平衡点比 STM32H5 便宜比 STM32L5 性能强正好适合物联网网关、边缘节点、工业控制器这类对安全有要求但又不希望成本失控的产品。另外ST 的官方固件包STM32CubeC5里已经集成了 OEMiROT 的完整参考例程不需要从零写安全启动逻辑难度大幅降低。你要做的只是学会配置、编译、烧录和验证流程理解它背后的机制然后移植到自己的板子上。1.3 适合谁看这篇如果你是在 STM32 上做产品开发的工程师想把安全启动集成进自己的方案正在用 STM32CubeIDE那么这篇内容就是给你的。阅读之前建议先了解一点 TrustZone 的基础概念知道 secure/non-secure 世界是怎么回事。如果你完全没碰过安全启动也不用慌我会把链路理清楚包括一些容易踩坑的细节。2. OEMiROT 工作原理与整体方案拆解2.1 OEMiROT 的信任根模型要理解 OEMiROT先得理解 ROT 这个概念。ROTRoot of Trust信任根是安全世界里所有信任的起点。它必须满足一个条件自身是不可伪造、不可篡改的。OEMiROT 之所以叫“OEM Immutable”因为它的引导代码BootROM 或不可写的 Flash 区域在芯片出厂时就固定下来或者由厂商在首次烧录后通过 Option Byte 锁定之后任何人都改不了这段代码。OEMiROT 的完整信任链是这样的芯片上电 | v BootROM不可修改加载 OEMiROT 引导代码 | v OEMiROT 校验镜像签名RSA/ECDSA | v 通过 - 加载应用固件启动 TrustZone 隔离 | v 失败 - 进入恢复模式/等待升级OEMiROT 本身是“Immutable Root of Trust”里的一环它负责校验可变区域应用固件的真实性。应用固件内部还可以继续建立自己的信任链比如校验外置 Flash 里的资源文件签名这就形成了完整的链式信任。2.2 镜像签名与验证机制OEMiROT 的验签依赖非对称加密。芯片内置或存储在受保护区域一把公钥厂商持有对应的私钥。固件编译完成后用私钥对固件镜像做签名签名值连同镜像一起烧入芯片。上电后 OEMiROT 从受保护区域读出公钥对镜像做验签。这里的几个关键点公钥存储在不可篡改的区域在 STM32C5 上公钥通常存放在 UFBUser Flash Bank的保留区域或者由 TrustZone 保护的安全存储区。签名算法常见为 RSA-2048 或 ECDSA-P256。ECDSA 签名短、验证快适合嵌入式RSA 兼容性更好很多老的升级链路还在用。反回滚保护固件镜像里带一个版本号OEMiROT 会把它和当前记录在案的最低允许版本比较如果版本比现存的还低就拒绝加载。这是防降级攻击的关键。2.3 安全状态机与生命周期管理OEMiROT 还有一个容易被忽略的部分芯片安全生命周期。STM32 的 TrustZone 芯片内部维护一个三态安全状态Open开放、Closed封闭、Locked锁定。Open 状态下可以自由调试、读写 Flash适合开发阶段。Closed 状态下 TrustZone 的隔离生效非安全世界无法访问安全资源调试接口受限。Locked 状态下安全启动彻底封闭任何外部手段都无法改写安全区内容适合量产。在开发阶段你基本保持在 Open 或 Closed烧录时要注意一旦切到 Closed再想用 ST-Link 调试器全功能访问内核就难了需要先做一次 Full Reset 或者通过专用流程才能回到 Open。这个特性你后面部署 CI 自动烧录时肯定会遇到提前记住。3. 开发环境搭建与 CubeMX 工程配置3.1 工具链版本选择做 OEMiROT 这种安全开发工具链版本非常重要。ST 对安全功能的支持是跟随固件包和 IDE 版本迭代的老版本可能缺功能新版本可能引入行为变更。我的建议是直接装当前主流的稳定版本STM32CubeIDE1.16 或更高。我用的 1.16.1实测稳定。STM32CubeMX6.12 或更高。从 CubeIDE 1.16 开始已经集成了 CubeMX不需要单独装但如果你习惯单独用 CubeMX 生成工程再导入 IDE注意版本别差太多。STM32CubeC5 Firmware PackageV1.0.0 或更新版本。这个包在 CubeMX 里选芯片时会自动下载也可以去 ST 官网手动下载然后导入。注意一点STM32CubeC5 的固件包比较大包含所有外设驱动、中间件和例程。首次下载如果网络不稳定容易失败。解决办法是手动下载 ZIP 包然后在 CubeMX 的 Firmware Package Manager 里从本地导入。3.2 CubeMX 工程初始化要点用 CubeMX 创建 OEMiROT 工程最关键的一步是选对例程目录。不要从空工程开始配置因为 OEMiROT 涉及 TrustZone 工程分区、链接脚本、启动文件等一系列复杂设置手搓容易出问题。正确姿势是直接从固件包里拷贝 OEMiROT 例程然后在 CubeMX 里调整配置。具体的步骤如下打开 STM32CubeMX选择 New Project在 MCU Selector 里搜 STM32C5选具体型号比如 STM32C531R6Tx。如果项目不想从零配可以直接 File - New Project 后选 Example Selector在列表里搜 OEMiROT。ST 在 CubeC5 里提供了OEMiROT_Boot引导工程和OEMiROT_App应用示例两个工程。如果没有看到 Example说明固件包没装全。回到 Help - Manage Embedded Software Packages勾选 STM32CubeC5 并完成安装。选定芯片和例程后CubeMX 会自动生成 TrustZone 相关的工程结构包括 secure 和 non-secure 两个子工程。3.3 TrustZone 内存布局配置OEMiROT 成功运行的一个核心条件内存布局必须正确。CubeMX 会生成默认的 TrustZone 分区但不同板子的 Flash/SRAM 大小不同需要手动核对。在 Project Manager - Linker Settings 里重点检查这几项Secure Flash 起始地址OEMiROT 的 boot 代码通常放在 Flash 起始处的 Secure 区比如 0x0C0000 起始的 64KB 区域。Non-Secure Flash 起始地址应用固件放在 Non-Secure 区比如 0x0D0000 起始。Secure SRAM 与 Non-Secure SRAM 的划分注意 Cortex-M33 的 TrustZone 通过 SAUSecurity Attribution Unit控制地址空间的属性CubeMX 生成的配置脚本会处理好但你要确认 SRAM 分界的起始地址没有重叠。提示Debug 配置下 ST-Link 烧录时如果地址配置和链接脚本不一致最常见的表现是烧录成功但一运行就进 HardFault。排查第一步永远是核对内存地址。3.4 生成工程并导入 CubeIDECubeMX 配置完成后点击右上角的 GENERATE CODE选择 Toolchain 为 STM32CubeIDE指定工程名和路径。生成完成后先用 CubeIDE 打开工程。这时你会看到工程里有两个子项目OEMiROT_Boot安全引导工程编译生成 bootloader。OEMiROT_App应用工程编译生成用户应用固件。注意这两个工程是关联的编译顺序有讲究。先编译 boot再编译 app最后烧录时也是先烧 boot再烧 app。CubeIDE 会把两个工程都放进 workspace但你需要手动切换 active project。4. 核心实操编译、烧录与验证全流程4.1 配置密钥与签名工具OEMiROT 的根密钥是整个安全方案的心脏。ST 的例程里已经生成了测试密钥对位于固件包的Middlewares/ST/STM32_TRUSTZONE/OEMiROT/Keys目录下OEMiROT_Boot_private.pem私钥用于签名固件。OEMiROT_Boot_public.pem公钥会被编译进 bootloader用于验证固件签名。OEMiROT_Boot_public.pem对应的.der或.c文件转换格式后嵌入工程。开发阶段直接用 ST 提供的测试密钥没问题但量产前一定要替换成自己生成的密钥对。用 OpenSSL 生成 ECDSA 密钥的命令openssl ecparam -name prime256v1 -genkey -noout -out OEMiROT_Boot_private.pem openssl ec -in OEMiROT_Boot_private.pem -pubout -out OEMiROT_Boot_public.pem生成新密钥后需要把公钥转换成 C 数组并替换工程中的key.c文件。具体格式可以参考 ST 例程自带的转换脚本执行一次替换后要重新编译 boot。4.2 编译步骤与参数设置编译前把 CubeIDE 的 active project 切到OEMiROT_Boot然后 Project - Build。编译过程中如果报错先看是不是密钥文件路径问题再排查是不是链接脚本和内存配置不一致。Boot 编译成功之后切到OEMiROT_App编译应用工程。这里有个关键点应用工程的镜像需要先生成带签名的烧录文件。CubeIDE 的 build 步骤会自动调用 STM32CubeProgrammer 的签名工具完成签名前提是你在工程属性里配置了 Post-build 命令。在OEMiROT_App的 Project Properties - C/C Build - Settings - Build Steps - Post-build steps 里确认里面的签名命令正确。典型命令长这样STM32_Signing_Tool_CLI.exe -s OEMiROT_Boot_private.pem -a 0x0D0000 -d app.bin -o app_signed.bin参数含义-s指定私钥-a指定应用固件的加载地址必须和链接脚本里的 Non-Secure Flash 起始地址一致-d输入 bin 文件-o输出签名后的 bin 文件4.3 烧录顺序与操作细节烧录工具推荐用 STM32CubeProgrammer图形界面和命令行都可以。命令行方式适合脚本化我实际量产用的就是命令行方式。第一块板子建议按以下顺序操作先烧录 bootloader。把 CubeIDE 的 debug configuration 指到 boot 工程的 elf 文件用 ST-Link 烧录。用 STM32CubeProgrammer 烧录签名后的应用固件STM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -w app_signed.bin 0x0D0000验证烧录是否正确STM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -r8 0x0D0000 16如果一切正常复位后 LED 按应用代码逻辑闪烁说明安全启动链路已经跑通。4.4 验证 OEMiROT 是否真的在起作用这里有个很容易犯的错误烧录成功、代码能跑就以为 OEMiROT 生效了。错误的认知。你需要主动做一次负向测试。操作方法用随便一个文本编辑器打开 app_signed.bin修改其中一个字节比如把 0x00 改成 0xFF保存后重新烧录。然后复位看现象如果 OLEDiROT 拒绝启动LED 不闪说明验签真的在工作。如果代码照样跑说明你烧的固件没走 OEMiROT 路径问题出在启动配置上。这个测试我每次切板子型号后都会做一遍花两分钟能省掉后面一堆排查时间。5. 常见问题与排查技巧实录5.1 启动失败LED 不亮代码没跑排查这类问题不要急着看应用代码先从链路源头查。我自己的排查顺序是用 STM32CubeProgrammer 读取芯片的状态和当前启动地址确认 boot 有没有执行。确认 Option Bytes 配置OEMiROT 要求TZEN1、DBANK1、SECBOOT1任何一个不对都会卡在启动早期。确认 boot 工程里链接的公钥和签名用的私钥是对应的。测试密钥替换场景最容易犯这个错。用调试器在 boot 的验签函数入口打断点逐步看是走到验签失败分支还是根本没进到验签逻辑。注意如果芯片已经切到 Closed 状态调试器访问受限需要先做一次全擦除回到 Open 状态才能继续调试。5.2 签名校验失败的典型原因验签失败是安全启动项目里最常见的错误。我整理了一份速查表现象可能原因检查方法一直卡在 boot 不进 app公钥和私钥不匹配重新生成密钥对确认 boot 和签名用的是同一对启动偶尔成功偶尔失败烧录地址不对核对 app 的链接地址与烧录命令地址升级后无法启动反回滚版本号比当前低更新固件版本号确认版本号单调递增烧录后校验失败bin 文件没有签名确认 Post-build 命令正确执行烧录的是签名后的文件5.3 调试接口被锁定怎么办安全项目的必然结果随着安全状态推进调试口会越来越难访问。我在用 STM32C5 的早期阶段就把两块板子的调试口锁死过当时以为芯片废了其实有解。恢复方法使用 STM32CubeProgrammer 的 HOTPLUG 模式连接在复位向量处做 mass erase。前提是芯片还没到 Locked 状态。如果已经 Locked只能通过 boot 引脚进入系统 bootloader 模式再用 UART 或 USB DFU 做全擦除。这个流程建议你在开发板上一开始就测通否则量产阶段遇到问题会非常被动。5.4 CubeIDE 编译报依赖错误的处理OEMiROT 例程涉及两个子工程互相引用头文件和库CubeIDE 的 build 顺序配置一旦丢了就会报各种找不到符号的错误。处理方法右键 boot 工程 - Properties - C/C Build - Project References勾选依赖的 app 工程反过来 app 工程也要勾选依赖的 boot 工程。两边都勾好后Clean 一次重新 Build。另外建议把 cubeide 的 build 并发线程数调低Window - Preferences - C/C - Build - Jobs避免多线程编译时乱序导致路径解析异常。6. 量产准备与脚本化发布6.1 替换量产密钥并重新编译全链路工程项目验证通过后第一件事就是替换测试密钥。这个操作不复杂但涉及面广容易遗漏生成新密钥对ECDSA P-256 或 RSA-2048。把新公钥转换成 C 数组文件替换 boot 工程里旧的key.c。重新编译 boot 和 app。把新私钥放到签名工具调用的固定路径更新 Post-build 命令里的私钥路径。全链路的固件重新签名重新烧录验证。替换密钥后旧签名固件在新 boot 下会验签失败这是预期行为。6.2 用脚本固化烧录流程到了要烧几十块板子的时候手工操作 STM32CubeProgrammer 太慢了。我把整个烧录流程写成批处理核心逻辑分三步烧录 bootSTM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -w OEMiROT_Boot.elf烧录签名 appSTM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -w app_signed.bin 0x0D0000配置 Option Byte 切到 Closed 状态STM32_Programmer_CLI.exe -c portSWD modeHOTPLUG -ob TZEN1 DBANK1 SECBOOT1注意Option Byte 的写入要放在所有烧录动作之后一旦写入 Closed后续调试接口受限所以这个动作要设计成单独的脚本步骤来执行。6.3 生产环境下的反回滚策略反回滚做得好不好直接决定产品的可维护性。OEMiROT 的版本号机制我建议这样设计开发阶段版本号从 0 开始每发一版 1。量产前的 final 版本版本号抬高到 100 以上给后面留足空间。生产线的固件版本号固定不跟随日常开发版本递增。原因是一旦某个版本在产线上被批量烧录反回滚机制会拒绝低于当前版本号的固件回刷。如果版本号规划不好后期想修复 bug 却发不了新版就只能全部返厂成本极高。7. 一点个人经验总结做了几年的 STM32 安全启动方案我的感受是OEMiROT 的难点不在“跑通”而在“想清楚”。跑通只需要跟着例程走一遍想清楚却需要理解安全模型、密钥管理、生命周期管理这些底层逻辑。STM32C5 上跑 OEMiROT 整体体验比老平台顺畅很多CubeIDE 的集成度高CubeMX 生成的工程结构干净出错率低。最后再分享一个实际操作中的小技巧OEMiROT 工程第一次跑通后马上把整个 workspace 打一个 zip 备份注释里写上日期和芯片型号。后面每次调整配置或换板子都从这个基线开始而不是从最新的工程状态开始。这能帮你避免很多“改了一堆东西最后不知道哪一步把链路搞坏了”的窘境。安全启动这种东西一旦遇到问题排查链路非常长有一个干净基线在手很多问题都能快速对照出差异来。
