终端设备的白皮书往往写得又厚又抽象读完之后你大概记住了几个安全术语回到自己的板子上依然不知道第一步该干什么。这篇我不想复述PPT式的架构图而是把 STM32MP1 这块芯片在真实产品里解决安全问题的方式拆开来讲包括启动链路怎么搭、密钥该放哪、TEE 环境怎么用以及我在实际项目里踩过的几个和安全有关的坑。如果你正在评估 STM32MP1 做网关、HMI、边缘计算盒子或者任何需要联网的终端设备这篇内容会比较对胃口。它不要求你已经是安全专家但需要你对嵌入式 Linux 有一定基础知道 U-Boot 和内核启动的大致流程。看完之后你至少能回答三个问题这块芯片的安全能力边界在哪、如何亲手把安全启动跑起来、以及量产时的密钥管理该怎么做才不会被自己坑死。1. 为什么MPU时代的终端安全比MCU时代难了一个量级1.1 MCU时代的“伪安全”不再适用以前做 MCU 产品很多人对安全的理解就是“我把固件加密一下别人读不出来就行”。这个思路在简单的 8 位/32 位单片机上勉强能用因为攻击者拿到芯片后第一道坎是读保护读保护一旦开启想通过调试接口 dump Flash 就没那么容易了。即便有人用侧信道、故障注入这类高阶手段成本往往比产品本身的价值还高攻击者自然就放弃了。但到了 STM32MP1 这种应用处理器级别情况完全不同。芯片上跑的是 Linux 系统有完整的文件系统、网络协议栈、用户空间进程攻击面从“物理接触芯片”扩大到了“远程通过网络攻入系统”。一旦远程拿到 shell固件加密、读保护这些东西全部形同虚设——因为系统自己会把固件读出来执行。所以 STM32MP1 的安全设计思路天然就是朝着“纵深防御”去的不是靠一层锁而是层层设防假设任何一层都可能被攻破。1.2 攻击面扩展从物理攻击到远程攻击我见过不少团队从 MCU 切到 MPU 之后仍然只关注物理安全结果产品上线不久就出了问题。典型场景是这样的设备通过以太网或 Wi-Fi 接入网络运行着一个 Web 服务用于远程配置和固件升级。Web 服务有漏洞攻击者拿到了 root shell。此时如果芯片没有做安全启动攻击者的第一个动作就是替换根文件系统或者内核镜像植入后门然后重启设备整个设备就永久沦陷了。STM32MP1 应对这个问题的核心武器是“信任链”Chain of Trust。从芯片内部的 BootROM 开始每一级启动镜像都要验证下一级镜像的签名签名不合法就拒绝启动。这意味着攻击者即使拿到了 root shell也无法通过修改启动分区实现持久化后门——因为修改过的镜像无法通过签名验证。当然这是理想情况实际部署中还涉及密钥保护、OTP 熔丝配置等细节这些后面展开讲。1.3 安全不只是防黑客也是产品合规的入场券还有一个现实压力现在很多行业对终端设备的安全能力有明确要求。欧洲的 RED 指令网络安全委托法案、美国的物联网标签计划、国内在等保和关键信息基础设施方面的要求都开始把“设备必须具备安全启动、安全更新、加密存储”作为基本门槛。如果产品选型时没考虑这些后面想补会很痛苦——硬件不支持的话软件怎么补都补不回来。这也是我推荐认真研究 STM32MP1 安全特性的原因。它通过 Arm TrustZone、安全启动、硬件加密引擎、防篡改引脚等一系列机制把安全能力做进了硬件层。软件层面能调用的安全原语齐全而且经过大量第三方认证比如 SESIP Level 3、PSA Certified Level 2 这些产品做认证时可以省不少事。芯片本身把地基打好了你在上面盖楼就不容易塌。2. 拆解STM32MP1的安全架构不是单点防护而是一套组合拳2.1 信任根一切安全的起点在芯片内部STM32MP1 的安全信任根是芯片出厂时固化的 BootROM。上电后 CPU 执行的第一个指令来自这块不可修改的 ROM它做两件事初始化最基本的硬件环境然后验证第一级引导程序 FSBLFirst Stage Boot Loader的签名。BootROM 本身是不可篡改的所以只要 BootROM 的逻辑没漏洞信任链的起点就是干净的。这里有个容易被忽视的细节STM32MP1 有两颗 Cortex-A7 核心和一颗 Cortex-M4 核心BootROM 在验证 FSBL 时同时覆盖了两个核心的启动镜像。也就是说M4 核心上跑的裸机程序或 RTOS 固件同样在信任链保护范围内。很多做混合架构产品的团队容易只关注 A7 侧的 Linux 安全忽略了 M4 侧的固件实际上攻击者完全可以盯着 M4 的镜像做文章——M4 往往直接控制电机、传感器、通信外设被攻破后造成的物理破坏甚至比 A7 更严重。2.2 TrustZone在同一颗芯片里划出两个世界TrustZone 是 Arm 架构提供的一种硬件级隔离技术理念很简单把 CPU 的运行环境划分为安全世界Secure World和普通世界Normal World。Linux 运行在普通世界安全敏感的操作系统或可信应用运行在安全世界。两个世界之间的切换由硬件强制实施普通世界的软件无法直接访问安全世界的资源——包括内存、外设、寄存器。用生活里的场景类比普通世界就像酒店的公共走廊安全世界则是每间客房的保险柜。酒店工作人员可以在走廊自由活动但保险柜里的东西只有持有对应钥匙的人才能打开。就算走廊里有人闹事也碰不到保险柜里的财物。在 STM32MP1 上密钥、关键配置、安全关键代码都可以放进安全世界。即便 Linux 内核被攻破攻击者看到的也只是一道无法逾越的墙。不过要说明的是TrustZone 只是提供了隔离机制安全世界里的软件通常是 OP-TEE需要自己写、自己维护。这块芯片的 OpenSTLinux 发行版里集成了 OP-TEE默认就带了一组可信应用比如安全存储、OTP 读写接口等可以直接用。2.3 硬件密码学引擎让加密不拖累主核安全算法全是计算密集型任务。如果 RSA 签名验证、AES 加解密、SHA 哈希全部用 CPU 软件实现不仅慢还会占用大量 CPU 周期影响实时性。STM32MP1 内置了一个完整的硬件加密模块支持 AES128/192/256 位、3DES、SHA-1/SHA-256/SHA-512、RSA、ECC 等主流算法而且这些算法引擎被设计成了“安全世界优先访问”的模式。这意味着安全世界的软件可以通过专用接口使用硬件加密引擎而普通世界想访问同样的引擎时会被 TrustZone 的策略拦住。一套硬件两套权限既保证了性能又避免了密钥在普通世界的内存里暴露。实际项目中我通常在 OP-TEE 的可信应用里封装一层加密服务Linux 侧的应用程序通过 TEE 客户端 API 调用这样密钥从头到尾都不会进入 Linux 的内存空间。2.4 密钥存储OTP 熔丝与安全存储的配合密钥管理是安全系统里最容易被搞砸的部分。STM32MP1 提供了 32 位 OTPOne-Time Programmable熔丝这些熔丝出厂后只能从 0 烧写为 1不能还原。其中一部分用于配置芯片的启动模式、TrustZone 使能等安全策略另一部分可以存放密钥或密钥的哈希值。关键点在于OTP 熔丝本身容量有限不适合直接存放 RSA 私钥这类较大的密钥材料。常见做法是把 OTP 熔丝中的一个 128 位区域作为“硬件唯一密钥”的种子由芯片内部的逻辑生成或派生最终的密钥然后结合 OTP 中存储的哈希值来验证固件签名的公钥。这样攻击者即使物理上探测 OTP 熔丝的状态也无法反推出完整的密钥体系。2.5 防篡改与入侵检测给攻击者制造物理障碍软件层面的防护做得再好如果攻击者能直接拆开芯片外壳用探针接触内部总线照样能窃取数据。为此 STM32MP1 设计了多个 TAMPER篡改检测引脚。当外部传感器检测到外壳被打开、温度异常、电压异常等情况时可以将 TAMPER 引脚拉高或拉低芯片随即做出响应——可以产生中断通知安全世界也可以直接触发安全存储区数据的擦除。我在做一款收费终端类产品时就用过这个功能。产品外壳设计了一个微动开关连接到 TAMPER 引脚一旦外壳被强制打开系统立刻锁定设备并要求输入管理员凭证连续失败多次后自动擦除本地缓存的关键业务数据。这个逻辑在 MCU 上实现比较麻烦但在 STM32MP1 上用 TAMPER OP-TEE 安全存储配合代码量很小可靠性却非常高。3. 实操安全启动链路从 BootROM 到 Linux 的每一道关卡3.1 先搞清楚你的芯片处于什么状态拿到一块 STM32MP1 开发板第一步不是写代码而是确认芯片的当前安全状态。ST 官方推出了一个叫 STM32CubeProgrammer 的工具可以读取芯片的 OTP 状态包括 BootROM 版本、熔丝状态、是否为工程样片等。我习惯用以下命令确认当前启动模式和安全相关配置STM32_Programmer_CLI -c portusb1 -read otp输出会列出所有 OTP 的当前值重点关注几个位域BSEC_MODE是否已锁定、TRUSTZONE是否使能、SRAM2写保护状态等。如果芯片刚出厂这些值通常处于一个比较“开放”的状态刚好适合做开发调试。等到量产方案确定后再一次性把熔丝烧到位并锁定。3.2 生成密钥对安全启动的地基安全启动的核心是非对称签名验证。STM32MP1 的 BootROM 内置了 RSA 或 ECDSA 验证引擎官方推荐使用 ECDSA P-256因为密钥更短、计算更快安全性也不输 RSA-2048。你可以用 OpenSSL 生成密钥对openssl ecparam -name prime256v1 -genkey -noout -out mp1_signing_key.pem openssl ec -in mp1_signing_key.pem -pubout -out mp1_signing_pub.pem私钥mp1_signing_key.pem就是整个信任链的命根子泄露了等于安全体系崩溃。建议在离线机器上生成私钥文件加密存放最好由专人保管遵循“最小权限”原则——不是所有开发人员都有资格接触私钥。公钥则要烧写到 OTP 中让 BootROM 用这个公钥去验证 FSBL 签名。生成密钥后还需要把公钥转换成 STM32MP1 BootROM 能识别的格式。ST 在官方 SDK 里提供了stm32-keygen工具用起来大致是stm32-keygen -p mp1_signing_pub.pem -o fip-key.bin -t ecdsa-p256生成的fip-key.bin在后续烧写 OTP 时会用到。3.3 构建签名固件链路TF-A、U-Boot 与内核镜像STM32MP1 的启动流程大致是BootROM → FSBL通常是 TF-A→ SSBL通常是 U-Boot→ 内核。这三级的签名验证链路是串在一起的上一级验证下一级任何一级被篡改都会导致启动失败。在 OpenSTLinux 的开发环境里可以通过 STM32CubeMX 生成初始工程里面已经包含了完整的启动镜像构建配置。构建时打开签名选项指定刚才生成的私钥工具链会自动完成签名。例如构建 TF-A 时make PLATstm32mp1 DEBUG0 AARCH32_SPsp_min STM32MP_SDMMC1 \ STM32MP_KEYmp1_signing_key.pem STM32MP_ECDSA1 \ STM32MP_SIGNED1构建完成后生成的tf-a-sdcard.stm32就是带签名的 FSBL 镜像。接着用同样的私钥签名 U-Boot 和内核镜像。这里必须提醒一点构建签名固件时开发环境不能乱装工具。我见过同事在同一个 Linux 机器上既做日常开发又做固件签名结果机器被植入木马私钥被窃取整个项目的安全根基瞬间崩塌。签名机应与开发环境物理隔离网络隔离USB 外设也要受控。3.4 烧写 OTP一次做对不可反悔OTP 熔丝的烧写是安全启动配置中最“惊心动魄”的一步因为熔丝只能从 0 变成 1一旦烧错芯片可能变砖而且不可恢复。所以烧写前一定要反复核对配置文件。烧写 ECDSA 公钥到 OTP 时我用的命令大致是STM32_Programmer_CLI -c portusb1 -otp write 0xXX:0xYYYY具体地址和值需要查看对应芯片型号的参考手册不同封装、不同批次可能有差异。我记得在 STM32MP157 上公钥哈希是分几段写入连续 OTP 地址的其中还包含 ECADDR、ECPKEY 等需要正确配置的区域漏掉任何一段都会导致 BootROM 验证失败。烧写完成后可以读取 OTP 确认但要记住OTP 一旦锁定通过写保护位内容就无法再修改。因此强烈建议在开发阶段不要锁死 OTP等所有功能验证完毕确认产品设计冻结再执行最终锁定操作。3.5 验证安全启动效果从“能启动”到“坏人进不来”配置完 OTP 和签名镜像后需要做两类验证。第一类是正向验证正常启动确认系统能跑起来日志里能看到信任链验证通过。第二类是负向验证故意对镜像做一点修改看看芯片是否会拒绝启动。负向验证非常重要但很容易被跳过。我有一个简单的操作习惯用十六进制编辑器修改 U-Boot 镜像的任意一个字节然后尝试从 SD 卡启动。如果安全启动配置正确芯片会在 BootROM 阶段就停下串口输出类似这样的错误信息Authentication failed: invalid signature看到这个提示才算真正放心。如果修改后的镜像照样启动了说明你的安全启动配置有问题赶紧排查不要带着隐患进入量产。4. 运行时保护机制系统跑起来之后的安全博弈4.1 OP-TEE 落地让安全世界真正被用起来安全启动只是第一道防线系统运行起来之后还需要 TrustZone 隔离来保护运行时的敏感数据。OpenSTLinux 默认集成了 OP-TEE但很多人只是觉得“系统里跑了个 TEE”根本没有把业务逻辑放进去。我建议先从最简单的场景开始写一个可信应用TA在里面实现一个“安全加法”或者“安全存储”的接口然后从普通世界的客户端应用CA调用。跑通之后再把真正的业务逻辑——比如密钥派生、签名生成、敏感数据存储——逐步迁移到 TA 中。OP-TEE 的开发模式是CA 通过libteec库访问/dev/teepriv设备节点与 TEE 内核驱动通信最终调用安全世界中的 TA。一个最小化的 CA 调用 TA 的伪代码是这样TEEC_Context ctx; TEEC_Session session; TEEC_UUID uuid TA_SAMPLE_UUID; uint32_t origin; TEEC_InitializeContext(NULL, ctx); TEEC_OpenSession(ctx, session, uuid, TEEC_LOGIN_PUBLIC, NULL, NULL, origin); TEEC_InvokeCommand(session, CMD_DO_WORK, operation, origin); TEEC_CloseSession(session); TEEC_FinalizeContext(ctx);这段代码看起来简单但背后是完整的 RPC 通信机制、内存共享和权限检查。如果你的产品对性能要求高还要注意 TA 和 CA 之间数据拷贝的开销尽量避免频繁传递大数据块。4.2 内存与外设的访问控制不止是 MMU 的活TrustZone 的内存隔离通过 TZASCTrustZone Address Space Controller实现它把物理内存划分为多个区域每个区域可以配置为仅安全世界可访问或普通世界可访问。在 STM32MP1 的默认配置里DDR 的一部分被划分给安全世界使用剩余部分给普通世界。你可能觉得“只要我不在 Linux 里访问那块内存就行了”其实没这么简单。恶意程序可以用 DMA 引擎直接访问物理内存绕过 CPU 的权限检查。所以 TZASC 的配置必须覆盖到 DMA 外设的访问路径——比如以太网 MAC、USB 控制器、SDMMC 控制器它们的 DMA 能力都要受到 TrustZone 约束。STM32MP1 的 ETZPCExtended TrustZone Protection Controller就是干这个的它控制外设的 TrustZone 访问权限确保普通世界的软件无法配置 DMA 去读安全内存。实际设置时我倾向于把所有带 DMA 的外设配置为“安全世界控制”Linux 侧使用时通过 TEE 驱动代为配置。这样虽然多了一层间接层但安全性提升非常大尤其是对以太网和 USB 这类最容易成为攻击入口的外设。4.3 安全存储关键数据不是“存起来”而是“锁起来”很多安全产品需要保存密钥、证书、设备标识等信息。如果直接写入 Linux 文件系统攻击者拿到 root 权限后直接读文件就完事了。正确的做法是使用 OP-TEE 的安全存储功能。OP-TEE 安全存储的底层实现利用了 TEE 内部的加密机制数据在写入时会用从 OTP 派生的硬件密钥进行加密密文存储在文件系统中但解密过程只在安全世界内发生。这样即使攻击者拿到存储介质的完整镜像也读不出明文。我在一个项目中用 OP-TEE 安全存储保存设备的 TLS 客户端证书和私钥。实现时在 TA 中开放了sec_store_write和sec_store_read两个命令CA 侧通过TEEC_InvokeCommand调用。Linux 里的 curl 等应用无法直接访问这些数据只有通过我们提供的安全服务接口才能间接使用私钥完成 TLS 握手整个握手过程的私钥运算也在安全世界内完成私钥从未离开过安全世界。4.4 防回滚保护别让攻击者降级你的固件安全启动解决了“启动时的镜像不被篡改”但还有一个容易被忽视的漏洞版本回滚攻击。攻击者如果能拿到一个旧版本的合法签名固件——比如从废旧设备里提取的旧镜像——就可以把它写回目标设备利用旧版本中已知的漏洞重新入侵系统。ST 的解决方案是“防回滚计数器”Anti-Rollback Counter。将版本号或计数器值存储在 OTP 熔丝中每次固件升级时BootROM 会比较当前镜像版本号与 OTP 中的版本号如果镜像版本低于 OTP 存储的版本就拒绝启动。这个机制简单有效但注意 OTP 熔丝只能从 0 变 1版本号也只能单调递增所以升级策略要想清楚别把自己锁死。我在量产项目中把防回滚计数器与 OTA 升级流程绑定设备从服务器下载新固件时先校验签名和版本号只有版本号高于当前 OTP 值才允许安装安装成功后由安全世界中的应用更新 OTP 计数器。这里面有个细节更新计数器的时机是在新固件第一次成功启动并自检通过后而不是下载完成时防止写入坏镜像后把计数器也烧高了导致无法回退到旧版。5. 量产阶段的安全落地密钥管理、认证与实战教训5.1 工厂烧录密钥分发不能走U盘安全启动进入量产面临的第一大挑战是如何在工厂把密钥和证书安全地烧写到每一片芯片里。最常见的错误是工程师为了省事把包含私钥的完整镜像放到一个 U 盘里带到产线直接烧录。这个操作相当于把保险柜钥匙复制了几百份放在车间里——只要有一个 U 盘流出去全产品线的安全信任就崩塌了。正确的做法是建立一套密钥隔离体系。生产线上使用“生产公钥”和“生产私钥”的分离生产私钥只存在于离线的签名服务器中或者在硬件安全模块HSM中保管产线上的烧录工具只持有生产公钥负责把签名后的镜像写入芯片同时通过产线工具锁定 OTP。烧录完成后产线应该输出一份烧录报告记录芯片序列号、烧录时间、OTP 内容哈希供后续追溯。ST 官方提供了 Secure Provisioning 工具链支持与 HSM 集成。我在实际项目中的流程是这样的产线烧录机通过网线连接一个隔离网段的签名服务器签名服务器调用 HSM 里的私钥完成镜像签名然后把签名结果返回给烧录机。这样私钥永远不会出现在产线电脑的硬盘或内存里。5.2 第三方认证给你带来了什么STM32MP1 拿到了 SESIP Level 3 认证和 PSA Certified Level 2 认证这意味着芯片的安全设计已经经过第三方实验室的评估覆盖面包括安全启动、TrustZone 隔离、密码学引擎、防篡改等关键能力。对产品团队来说选择一颗有认证的芯片等于产品在申请自己的安全认证时可以直接引用芯片的认证报告省去大量从零证明芯片安全性的工作。我参与过一款医疗边缘网关的认证过程当时客户方要求设备必须具备起码的安全启动和加密存储能力。我们在方案评审时直接展示了 STM32MP1 的 SESIP 认证报告配合我们在安全启动和 OP-TEE 上的设计文档认证评审一次通过整体时间比预期缩短了将近两个月。这就是“站在巨人的肩膀上”的实感。不过要注意芯片认证不等于你的产品认证。产品层面的系统安全设计、密钥管理流程、OTA 升级机制、安全维护承诺这些都需要你自己的团队来证明。芯片认证只是地基不是免死金牌。5.3 认证之后的持续安全维护安全不是一个静态状态而是一个持续对抗的过程。产品量产后固件漏洞会不断被发现攻击手法也在不断进化。如果没有一套可靠的 OTA 签名升级机制产品一旦暴露出高危漏洞你只能眼巴巴地看着用户设备暴露在风险中。STM32MP1 的安全启动链天然支持安全升级每次 OTA 升级都会走一遍签名验证而且在防回滚计数器配合下升级管理非常灵活。但这里有个实践上的建议OTA 服务器端的密钥绝对不能和开发环境的密钥共用建议单独生成一套“生产 OTA 密钥”与签名固件的密钥分离或者至少加上不同的用途标识。万一开发密钥泄露了你可以只撤销开发环境的信任不影响生产设备。5.4 几个容易踩的坑和我的避坑经验第一个坑开发阶段的 OTP 熔丝烧早了。有个项目在样机阶段就为了测试安全启动把 OTP 锁死了结果后面发现 U-Boot 的一个配置需要调整但签名的 U-Boot 镜像用的密钥和 OTP 里的公钥对不上只能重新换芯片调试。建议开发样机阶段使用“开发模式”不锁 OTP只验证签名流程等设计冻结再烧写最终 OTP。第二个坑把私钥放在代码仓库里。有些人为了团队协作方便把私钥传到了 Git 仓库结果仓库权限配置不当私钥泄露。我吃过这个亏有一次代码托管平台的成员权限误配置外包人员拿到了仓库访问权万幸私钥是加密过的而且我们及时更换了密钥对。后来我定了条铁律凡是私钥一律不得以任何形式进入代码仓库要共享密钥走专门的安全传输通道或者离线交接。第三个坑只验证安全启动不验证系统运行时的隔离。有些团队把安全启动调通后觉得安全就完成了业务代码全部平铺在 Linux 用户空间。结果某个 Web 服务的一个 PHP 漏洞就导致了整个系统的敏感配置泄露。安全启动只是大门上的锁进门之后的房间与房间之间还有门TEE 隔离就是这些内门一定要根据业务敏感度做好内部划分。第四个坑忽视 M4 核心的安全。STM32MP1 的异构架构意味着 M4 核心同样具有访问外设和部分内存的能力如果 M4 的固件不在信任链范围内攻击者可以利用 M4 的 DMA 能力绕过 A7 侧的防护。在量产配置里一定要确认 M4 固件也被签名保护并且在 ETZPC 中限制 M4 对外设的访问权限。5.5 如果从零开始团队应该怎么搭安全能力如果你的团队之前没有专职的安全工程师我的建议是从最小的闭环开始不要一上来就想搭一个包罗万象的安全体系。第一步先把安全启动跑通确认信任链和防回滚机制有效。第二步用 OP-TEE 做一个最小可信应用把最重要的一个密钥存进安全存储。第三步再逐步扩展把加密引擎调用、篡改检测、OTA 安全升级等能力一一加进来。这个过程大概需要两到四周取决于团队对 Arm 架构和 OP-TEE 的熟悉程度。如果中间卡住了优先查官方文档和 OpenSTLinux 的源码ST 的安全相关文档写得很细还包括许多应用笔记和代码示例。我和团队最初也是摸着石头过河光是在 TZASC 配置上就折腾了整整两天最后发现是设备树里一个属性写错了位置。这种坑文档里其实有但很隐蔽确实要沉下心一行一行排查。我个人在实际项目中的体会是终端安全的最大敌人往往不是外部攻击者而是内部流程的松懈。芯片给了你很强的安全底座但如果密钥管理随意、OTP 烧写混乱、团队安全分工不明确再强的硬件也保护不了你的产品。把安全当作一个工程问题来管理像管理 BOM 表一样管理密钥和证书像做单元测试一样做安全验证这样产出的设备才是真正可信赖的。
终端设备的白皮书往往写得又厚又抽象读完之后你大概记住了几个安全术语回到自己的板子上依然不知道第一步该干什么。这篇我不想复述PPT式的架构图而是把 STM32MP1 这块芯片在真实产品里解决安全问题的方式拆开来讲包括启动链路怎么搭、密钥该放哪、TEE 环境怎么用以及我在实际项目里踩过的几个和安全有关的坑。如果你正在评估 STM32MP1 做网关、HMI、边缘计算盒子或者任何需要联网的终端设备这篇内容会比较对胃口。它不要求你已经是安全专家但需要你对嵌入式 Linux 有一定基础知道 U-Boot 和内核启动的大致流程。看完之后你至少能回答三个问题这块芯片的安全能力边界在哪、如何亲手把安全启动跑起来、以及量产时的密钥管理该怎么做才不会被自己坑死。1. 为什么MPU时代的终端安全比MCU时代难了一个量级1.1 MCU时代的“伪安全”不再适用以前做 MCU 产品很多人对安全的理解就是“我把固件加密一下别人读不出来就行”。这个思路在简单的 8 位/32 位单片机上勉强能用因为攻击者拿到芯片后第一道坎是读保护读保护一旦开启想通过调试接口 dump Flash 就没那么容易了。即便有人用侧信道、故障注入这类高阶手段成本往往比产品本身的价值还高攻击者自然就放弃了。但到了 STM32MP1 这种应用处理器级别情况完全不同。芯片上跑的是 Linux 系统有完整的文件系统、网络协议栈、用户空间进程攻击面从“物理接触芯片”扩大到了“远程通过网络攻入系统”。一旦远程拿到 shell固件加密、读保护这些东西全部形同虚设——因为系统自己会把固件读出来执行。所以 STM32MP1 的安全设计思路天然就是朝着“纵深防御”去的不是靠一层锁而是层层设防假设任何一层都可能被攻破。1.2 攻击面扩展从物理攻击到远程攻击我见过不少团队从 MCU 切到 MPU 之后仍然只关注物理安全结果产品上线不久就出了问题。典型场景是这样的设备通过以太网或 Wi-Fi 接入网络运行着一个 Web 服务用于远程配置和固件升级。Web 服务有漏洞攻击者拿到了 root shell。此时如果芯片没有做安全启动攻击者的第一个动作就是替换根文件系统或者内核镜像植入后门然后重启设备整个设备就永久沦陷了。STM32MP1 应对这个问题的核心武器是“信任链”Chain of Trust。从芯片内部的 BootROM 开始每一级启动镜像都要验证下一级镜像的签名签名不合法就拒绝启动。这意味着攻击者即使拿到了 root shell也无法通过修改启动分区实现持久化后门——因为修改过的镜像无法通过签名验证。当然这是理想情况实际部署中还涉及密钥保护、OTP 熔丝配置等细节这些后面展开讲。1.3 安全不只是防黑客也是产品合规的入场券还有一个现实压力现在很多行业对终端设备的安全能力有明确要求。欧洲的 RED 指令网络安全委托法案、美国的物联网标签计划、国内在等保和关键信息基础设施方面的要求都开始把“设备必须具备安全启动、安全更新、加密存储”作为基本门槛。如果产品选型时没考虑这些后面想补会很痛苦——硬件不支持的话软件怎么补都补不回来。这也是我推荐认真研究 STM32MP1 安全特性的原因。它通过 Arm TrustZone、安全启动、硬件加密引擎、防篡改引脚等一系列机制把安全能力做进了硬件层。软件层面能调用的安全原语齐全而且经过大量第三方认证比如 SESIP Level 3、PSA Certified Level 2 这些产品做认证时可以省不少事。芯片本身把地基打好了你在上面盖楼就不容易塌。2. 拆解STM32MP1的安全架构不是单点防护而是一套组合拳2.1 信任根一切安全的起点在芯片内部STM32MP1 的安全信任根是芯片出厂时固化的 BootROM。上电后 CPU 执行的第一个指令来自这块不可修改的 ROM它做两件事初始化最基本的硬件环境然后验证第一级引导程序 FSBLFirst Stage Boot Loader的签名。BootROM 本身是不可篡改的所以只要 BootROM 的逻辑没漏洞信任链的起点就是干净的。这里有个容易被忽视的细节STM32MP1 有两颗 Cortex-A7 核心和一颗 Cortex-M4 核心BootROM 在验证 FSBL 时同时覆盖了两个核心的启动镜像。也就是说M4 核心上跑的裸机程序或 RTOS 固件同样在信任链保护范围内。很多做混合架构产品的团队容易只关注 A7 侧的 Linux 安全忽略了 M4 侧的固件实际上攻击者完全可以盯着 M4 的镜像做文章——M4 往往直接控制电机、传感器、通信外设被攻破后造成的物理破坏甚至比 A7 更严重。2.2 TrustZone在同一颗芯片里划出两个世界TrustZone 是 Arm 架构提供的一种硬件级隔离技术理念很简单把 CPU 的运行环境划分为安全世界Secure World和普通世界Normal World。Linux 运行在普通世界安全敏感的操作系统或可信应用运行在安全世界。两个世界之间的切换由硬件强制实施普通世界的软件无法直接访问安全世界的资源——包括内存、外设、寄存器。用生活里的场景类比普通世界就像酒店的公共走廊安全世界则是每间客房的保险柜。酒店工作人员可以在走廊自由活动但保险柜里的东西只有持有对应钥匙的人才能打开。就算走廊里有人闹事也碰不到保险柜里的财物。在 STM32MP1 上密钥、关键配置、安全关键代码都可以放进安全世界。即便 Linux 内核被攻破攻击者看到的也只是一道无法逾越的墙。不过要说明的是TrustZone 只是提供了隔离机制安全世界里的软件通常是 OP-TEE需要自己写、自己维护。这块芯片的 OpenSTLinux 发行版里集成了 OP-TEE默认就带了一组可信应用比如安全存储、OTP 读写接口等可以直接用。2.3 硬件密码学引擎让加密不拖累主核安全算法全是计算密集型任务。如果 RSA 签名验证、AES 加解密、SHA 哈希全部用 CPU 软件实现不仅慢还会占用大量 CPU 周期影响实时性。STM32MP1 内置了一个完整的硬件加密模块支持 AES128/192/256 位、3DES、SHA-1/SHA-256/SHA-512、RSA、ECC 等主流算法而且这些算法引擎被设计成了“安全世界优先访问”的模式。这意味着安全世界的软件可以通过专用接口使用硬件加密引擎而普通世界想访问同样的引擎时会被 TrustZone 的策略拦住。一套硬件两套权限既保证了性能又避免了密钥在普通世界的内存里暴露。实际项目中我通常在 OP-TEE 的可信应用里封装一层加密服务Linux 侧的应用程序通过 TEE 客户端 API 调用这样密钥从头到尾都不会进入 Linux 的内存空间。2.4 密钥存储OTP 熔丝与安全存储的配合密钥管理是安全系统里最容易被搞砸的部分。STM32MP1 提供了 32 位 OTPOne-Time Programmable熔丝这些熔丝出厂后只能从 0 烧写为 1不能还原。其中一部分用于配置芯片的启动模式、TrustZone 使能等安全策略另一部分可以存放密钥或密钥的哈希值。关键点在于OTP 熔丝本身容量有限不适合直接存放 RSA 私钥这类较大的密钥材料。常见做法是把 OTP 熔丝中的一个 128 位区域作为“硬件唯一密钥”的种子由芯片内部的逻辑生成或派生最终的密钥然后结合 OTP 中存储的哈希值来验证固件签名的公钥。这样攻击者即使物理上探测 OTP 熔丝的状态也无法反推出完整的密钥体系。2.5 防篡改与入侵检测给攻击者制造物理障碍软件层面的防护做得再好如果攻击者能直接拆开芯片外壳用探针接触内部总线照样能窃取数据。为此 STM32MP1 设计了多个 TAMPER篡改检测引脚。当外部传感器检测到外壳被打开、温度异常、电压异常等情况时可以将 TAMPER 引脚拉高或拉低芯片随即做出响应——可以产生中断通知安全世界也可以直接触发安全存储区数据的擦除。我在做一款收费终端类产品时就用过这个功能。产品外壳设计了一个微动开关连接到 TAMPER 引脚一旦外壳被强制打开系统立刻锁定设备并要求输入管理员凭证连续失败多次后自动擦除本地缓存的关键业务数据。这个逻辑在 MCU 上实现比较麻烦但在 STM32MP1 上用 TAMPER OP-TEE 安全存储配合代码量很小可靠性却非常高。3. 实操安全启动链路从 BootROM 到 Linux 的每一道关卡3.1 先搞清楚你的芯片处于什么状态拿到一块 STM32MP1 开发板第一步不是写代码而是确认芯片的当前安全状态。ST 官方推出了一个叫 STM32CubeProgrammer 的工具可以读取芯片的 OTP 状态包括 BootROM 版本、熔丝状态、是否为工程样片等。我习惯用以下命令确认当前启动模式和安全相关配置STM32_Programmer_CLI -c portusb1 -read otp输出会列出所有 OTP 的当前值重点关注几个位域BSEC_MODE是否已锁定、TRUSTZONE是否使能、SRAM2写保护状态等。如果芯片刚出厂这些值通常处于一个比较“开放”的状态刚好适合做开发调试。等到量产方案确定后再一次性把熔丝烧到位并锁定。3.2 生成密钥对安全启动的地基安全启动的核心是非对称签名验证。STM32MP1 的 BootROM 内置了 RSA 或 ECDSA 验证引擎官方推荐使用 ECDSA P-256因为密钥更短、计算更快安全性也不输 RSA-2048。你可以用 OpenSSL 生成密钥对openssl ecparam -name prime256v1 -genkey -noout -out mp1_signing_key.pem openssl ec -in mp1_signing_key.pem -pubout -out mp1_signing_pub.pem私钥mp1_signing_key.pem就是整个信任链的命根子泄露了等于安全体系崩溃。建议在离线机器上生成私钥文件加密存放最好由专人保管遵循“最小权限”原则——不是所有开发人员都有资格接触私钥。公钥则要烧写到 OTP 中让 BootROM 用这个公钥去验证 FSBL 签名。生成密钥后还需要把公钥转换成 STM32MP1 BootROM 能识别的格式。ST 在官方 SDK 里提供了stm32-keygen工具用起来大致是stm32-keygen -p mp1_signing_pub.pem -o fip-key.bin -t ecdsa-p256生成的fip-key.bin在后续烧写 OTP 时会用到。3.3 构建签名固件链路TF-A、U-Boot 与内核镜像STM32MP1 的启动流程大致是BootROM → FSBL通常是 TF-A→ SSBL通常是 U-Boot→ 内核。这三级的签名验证链路是串在一起的上一级验证下一级任何一级被篡改都会导致启动失败。在 OpenSTLinux 的开发环境里可以通过 STM32CubeMX 生成初始工程里面已经包含了完整的启动镜像构建配置。构建时打开签名选项指定刚才生成的私钥工具链会自动完成签名。例如构建 TF-A 时make PLATstm32mp1 DEBUG0 AARCH32_SPsp_min STM32MP_SDMMC1 \ STM32MP_KEYmp1_signing_key.pem STM32MP_ECDSA1 \ STM32MP_SIGNED1构建完成后生成的tf-a-sdcard.stm32就是带签名的 FSBL 镜像。接着用同样的私钥签名 U-Boot 和内核镜像。这里必须提醒一点构建签名固件时开发环境不能乱装工具。我见过同事在同一个 Linux 机器上既做日常开发又做固件签名结果机器被植入木马私钥被窃取整个项目的安全根基瞬间崩塌。签名机应与开发环境物理隔离网络隔离USB 外设也要受控。3.4 烧写 OTP一次做对不可反悔OTP 熔丝的烧写是安全启动配置中最“惊心动魄”的一步因为熔丝只能从 0 变成 1一旦烧错芯片可能变砖而且不可恢复。所以烧写前一定要反复核对配置文件。烧写 ECDSA 公钥到 OTP 时我用的命令大致是STM32_Programmer_CLI -c portusb1 -otp write 0xXX:0xYYYY具体地址和值需要查看对应芯片型号的参考手册不同封装、不同批次可能有差异。我记得在 STM32MP157 上公钥哈希是分几段写入连续 OTP 地址的其中还包含 ECADDR、ECPKEY 等需要正确配置的区域漏掉任何一段都会导致 BootROM 验证失败。烧写完成后可以读取 OTP 确认但要记住OTP 一旦锁定通过写保护位内容就无法再修改。因此强烈建议在开发阶段不要锁死 OTP等所有功能验证完毕确认产品设计冻结再执行最终锁定操作。3.5 验证安全启动效果从“能启动”到“坏人进不来”配置完 OTP 和签名镜像后需要做两类验证。第一类是正向验证正常启动确认系统能跑起来日志里能看到信任链验证通过。第二类是负向验证故意对镜像做一点修改看看芯片是否会拒绝启动。负向验证非常重要但很容易被跳过。我有一个简单的操作习惯用十六进制编辑器修改 U-Boot 镜像的任意一个字节然后尝试从 SD 卡启动。如果安全启动配置正确芯片会在 BootROM 阶段就停下串口输出类似这样的错误信息Authentication failed: invalid signature看到这个提示才算真正放心。如果修改后的镜像照样启动了说明你的安全启动配置有问题赶紧排查不要带着隐患进入量产。4. 运行时保护机制系统跑起来之后的安全博弈4.1 OP-TEE 落地让安全世界真正被用起来安全启动只是第一道防线系统运行起来之后还需要 TrustZone 隔离来保护运行时的敏感数据。OpenSTLinux 默认集成了 OP-TEE但很多人只是觉得“系统里跑了个 TEE”根本没有把业务逻辑放进去。我建议先从最简单的场景开始写一个可信应用TA在里面实现一个“安全加法”或者“安全存储”的接口然后从普通世界的客户端应用CA调用。跑通之后再把真正的业务逻辑——比如密钥派生、签名生成、敏感数据存储——逐步迁移到 TA 中。OP-TEE 的开发模式是CA 通过libteec库访问/dev/teepriv设备节点与 TEE 内核驱动通信最终调用安全世界中的 TA。一个最小化的 CA 调用 TA 的伪代码是这样TEEC_Context ctx; TEEC_Session session; TEEC_UUID uuid TA_SAMPLE_UUID; uint32_t origin; TEEC_InitializeContext(NULL, ctx); TEEC_OpenSession(ctx, session, uuid, TEEC_LOGIN_PUBLIC, NULL, NULL, origin); TEEC_InvokeCommand(session, CMD_DO_WORK, operation, origin); TEEC_CloseSession(session); TEEC_FinalizeContext(ctx);这段代码看起来简单但背后是完整的 RPC 通信机制、内存共享和权限检查。如果你的产品对性能要求高还要注意 TA 和 CA 之间数据拷贝的开销尽量避免频繁传递大数据块。4.2 内存与外设的访问控制不止是 MMU 的活TrustZone 的内存隔离通过 TZASCTrustZone Address Space Controller实现它把物理内存划分为多个区域每个区域可以配置为仅安全世界可访问或普通世界可访问。在 STM32MP1 的默认配置里DDR 的一部分被划分给安全世界使用剩余部分给普通世界。你可能觉得“只要我不在 Linux 里访问那块内存就行了”其实没这么简单。恶意程序可以用 DMA 引擎直接访问物理内存绕过 CPU 的权限检查。所以 TZASC 的配置必须覆盖到 DMA 外设的访问路径——比如以太网 MAC、USB 控制器、SDMMC 控制器它们的 DMA 能力都要受到 TrustZone 约束。STM32MP1 的 ETZPCExtended TrustZone Protection Controller就是干这个的它控制外设的 TrustZone 访问权限确保普通世界的软件无法配置 DMA 去读安全内存。实际设置时我倾向于把所有带 DMA 的外设配置为“安全世界控制”Linux 侧使用时通过 TEE 驱动代为配置。这样虽然多了一层间接层但安全性提升非常大尤其是对以太网和 USB 这类最容易成为攻击入口的外设。4.3 安全存储关键数据不是“存起来”而是“锁起来”很多安全产品需要保存密钥、证书、设备标识等信息。如果直接写入 Linux 文件系统攻击者拿到 root 权限后直接读文件就完事了。正确的做法是使用 OP-TEE 的安全存储功能。OP-TEE 安全存储的底层实现利用了 TEE 内部的加密机制数据在写入时会用从 OTP 派生的硬件密钥进行加密密文存储在文件系统中但解密过程只在安全世界内发生。这样即使攻击者拿到存储介质的完整镜像也读不出明文。我在一个项目中用 OP-TEE 安全存储保存设备的 TLS 客户端证书和私钥。实现时在 TA 中开放了sec_store_write和sec_store_read两个命令CA 侧通过TEEC_InvokeCommand调用。Linux 里的 curl 等应用无法直接访问这些数据只有通过我们提供的安全服务接口才能间接使用私钥完成 TLS 握手整个握手过程的私钥运算也在安全世界内完成私钥从未离开过安全世界。4.4 防回滚保护别让攻击者降级你的固件安全启动解决了“启动时的镜像不被篡改”但还有一个容易被忽视的漏洞版本回滚攻击。攻击者如果能拿到一个旧版本的合法签名固件——比如从废旧设备里提取的旧镜像——就可以把它写回目标设备利用旧版本中已知的漏洞重新入侵系统。ST 的解决方案是“防回滚计数器”Anti-Rollback Counter。将版本号或计数器值存储在 OTP 熔丝中每次固件升级时BootROM 会比较当前镜像版本号与 OTP 中的版本号如果镜像版本低于 OTP 存储的版本就拒绝启动。这个机制简单有效但注意 OTP 熔丝只能从 0 变 1版本号也只能单调递增所以升级策略要想清楚别把自己锁死。我在量产项目中把防回滚计数器与 OTA 升级流程绑定设备从服务器下载新固件时先校验签名和版本号只有版本号高于当前 OTP 值才允许安装安装成功后由安全世界中的应用更新 OTP 计数器。这里面有个细节更新计数器的时机是在新固件第一次成功启动并自检通过后而不是下载完成时防止写入坏镜像后把计数器也烧高了导致无法回退到旧版。5. 量产阶段的安全落地密钥管理、认证与实战教训5.1 工厂烧录密钥分发不能走U盘安全启动进入量产面临的第一大挑战是如何在工厂把密钥和证书安全地烧写到每一片芯片里。最常见的错误是工程师为了省事把包含私钥的完整镜像放到一个 U 盘里带到产线直接烧录。这个操作相当于把保险柜钥匙复制了几百份放在车间里——只要有一个 U 盘流出去全产品线的安全信任就崩塌了。正确的做法是建立一套密钥隔离体系。生产线上使用“生产公钥”和“生产私钥”的分离生产私钥只存在于离线的签名服务器中或者在硬件安全模块HSM中保管产线上的烧录工具只持有生产公钥负责把签名后的镜像写入芯片同时通过产线工具锁定 OTP。烧录完成后产线应该输出一份烧录报告记录芯片序列号、烧录时间、OTP 内容哈希供后续追溯。ST 官方提供了 Secure Provisioning 工具链支持与 HSM 集成。我在实际项目中的流程是这样的产线烧录机通过网线连接一个隔离网段的签名服务器签名服务器调用 HSM 里的私钥完成镜像签名然后把签名结果返回给烧录机。这样私钥永远不会出现在产线电脑的硬盘或内存里。5.2 第三方认证给你带来了什么STM32MP1 拿到了 SESIP Level 3 认证和 PSA Certified Level 2 认证这意味着芯片的安全设计已经经过第三方实验室的评估覆盖面包括安全启动、TrustZone 隔离、密码学引擎、防篡改等关键能力。对产品团队来说选择一颗有认证的芯片等于产品在申请自己的安全认证时可以直接引用芯片的认证报告省去大量从零证明芯片安全性的工作。我参与过一款医疗边缘网关的认证过程当时客户方要求设备必须具备起码的安全启动和加密存储能力。我们在方案评审时直接展示了 STM32MP1 的 SESIP 认证报告配合我们在安全启动和 OP-TEE 上的设计文档认证评审一次通过整体时间比预期缩短了将近两个月。这就是“站在巨人的肩膀上”的实感。不过要注意芯片认证不等于你的产品认证。产品层面的系统安全设计、密钥管理流程、OTA 升级机制、安全维护承诺这些都需要你自己的团队来证明。芯片认证只是地基不是免死金牌。5.3 认证之后的持续安全维护安全不是一个静态状态而是一个持续对抗的过程。产品量产后固件漏洞会不断被发现攻击手法也在不断进化。如果没有一套可靠的 OTA 签名升级机制产品一旦暴露出高危漏洞你只能眼巴巴地看着用户设备暴露在风险中。STM32MP1 的安全启动链天然支持安全升级每次 OTA 升级都会走一遍签名验证而且在防回滚计数器配合下升级管理非常灵活。但这里有个实践上的建议OTA 服务器端的密钥绝对不能和开发环境的密钥共用建议单独生成一套“生产 OTA 密钥”与签名固件的密钥分离或者至少加上不同的用途标识。万一开发密钥泄露了你可以只撤销开发环境的信任不影响生产设备。5.4 几个容易踩的坑和我的避坑经验第一个坑开发阶段的 OTP 熔丝烧早了。有个项目在样机阶段就为了测试安全启动把 OTP 锁死了结果后面发现 U-Boot 的一个配置需要调整但签名的 U-Boot 镜像用的密钥和 OTP 里的公钥对不上只能重新换芯片调试。建议开发样机阶段使用“开发模式”不锁 OTP只验证签名流程等设计冻结再烧写最终 OTP。第二个坑把私钥放在代码仓库里。有些人为了团队协作方便把私钥传到了 Git 仓库结果仓库权限配置不当私钥泄露。我吃过这个亏有一次代码托管平台的成员权限误配置外包人员拿到了仓库访问权万幸私钥是加密过的而且我们及时更换了密钥对。后来我定了条铁律凡是私钥一律不得以任何形式进入代码仓库要共享密钥走专门的安全传输通道或者离线交接。第三个坑只验证安全启动不验证系统运行时的隔离。有些团队把安全启动调通后觉得安全就完成了业务代码全部平铺在 Linux 用户空间。结果某个 Web 服务的一个 PHP 漏洞就导致了整个系统的敏感配置泄露。安全启动只是大门上的锁进门之后的房间与房间之间还有门TEE 隔离就是这些内门一定要根据业务敏感度做好内部划分。第四个坑忽视 M4 核心的安全。STM32MP1 的异构架构意味着 M4 核心同样具有访问外设和部分内存的能力如果 M4 的固件不在信任链范围内攻击者可以利用 M4 的 DMA 能力绕过 A7 侧的防护。在量产配置里一定要确认 M4 固件也被签名保护并且在 ETZPC 中限制 M4 对外设的访问权限。5.5 如果从零开始团队应该怎么搭安全能力如果你的团队之前没有专职的安全工程师我的建议是从最小的闭环开始不要一上来就想搭一个包罗万象的安全体系。第一步先把安全启动跑通确认信任链和防回滚机制有效。第二步用 OP-TEE 做一个最小可信应用把最重要的一个密钥存进安全存储。第三步再逐步扩展把加密引擎调用、篡改检测、OTA 安全升级等能力一一加进来。这个过程大概需要两到四周取决于团队对 Arm 架构和 OP-TEE 的熟悉程度。如果中间卡住了优先查官方文档和 OpenSTLinux 的源码ST 的安全相关文档写得很细还包括许多应用笔记和代码示例。我和团队最初也是摸着石头过河光是在 TZASC 配置上就折腾了整整两天最后发现是设备树里一个属性写错了位置。这种坑文档里其实有但很隐蔽确实要沉下心一行一行排查。我个人在实际项目中的体会是终端安全的最大敌人往往不是外部攻击者而是内部流程的松懈。芯片给了你很强的安全底座但如果密钥管理随意、OTP 烧写混乱、团队安全分工不明确再强的硬件也保护不了你的产品。把安全当作一个工程问题来管理像管理 BOM 表一样管理密钥和证书像做单元测试一样做安全验证这样产出的设备才是真正可信赖的。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
