行业资讯

资源受限系统的安全检查入口

发布时间:2026/8/28 1:16:04
资源受限系统的安全检查入口 资源受限系统的安全检查入口资源受限 MCU 的 OTA、调试接口和固件存储都应纳入安全设计。CRC 可用于发现传输损坏却不能证明镜像来自可信发布者远程更新需要验证制品来源和版本策略。资源约束会影响实现选择但不应成为忽略身份、完整性与恢复机制的理由。----------------------------------------------------------------------- | MCU 受限环境三重安全防线与 Bootloader | ----------------------------------------------------------------------- | v ------------------ 硬件锁死 ------------------ 安全校验 ------------------ | JTAG/SWD 调试口 | ---------- | Option Bytes ROP | ---------- | Secure Bootloader| | Read Out Protection| | Level 2 永久锁死 | | Ed25519 极简验签 | ------------------ ------------------ ------------------ | v -------------------- | Dual Bank 安全切换 | | 校验失败原区运行 | --------------------1. 物理调试入口防线Option Bytes 读出保护ROP与 JTAG/SWD 锁定绝大多数 MCU 开发者在出厂前容易遗漏最基础的物理安全配置——Option Bytes选项字节中的 Flash 读出保护Read Out Protection, ROP。如果 ROP 处于 Level 0未保护状态任何拿着几十块钱 ST-Link 或 J-Link 的攻击者只需接上 SWD 接口就能直接导出 Flash 中全量编译好的明文 Hex 镜像轻松逆向出机密通讯协议与硬编码加密秘钥。使用st-info工具可以在命令行检查目标芯片的硬件安全锁状态st-info --probe输出日志清晰打印出芯片当前读保护等级Found 1 stlink programmers version: V2J29S7 target voltage: 3.26V flash: 262144 bytes (256 KiB) sram: 65536 bytes (64 KiB) chipid: 0x0435 protection: ROP Level 0 (DANGER: Flash memory is completely readable via SWD!)工程防护措施必须在工厂生产烧录脚本中加入 Option Bytes 锁死逻辑。以 STM32 为例ROP Level 1禁止通过 SWD 读取 Flash但允许重新擦除整片 Flash 将其降级回 Level 0。ROP Level 2彻底永久锁死 SWD 调试接口彻底禁止任何调试器连接芯片熔丝不可逆变更改。在 C 语言初始化代码中也可以嵌入 Option Bytes 自动自检代码#include stm32l4xx_hal.h // 上电自检 Option Bytes 保护状态 void check_and_enforce_flash_rop(void) { FLASH_OBProgramInitTypeDef ob_config; HAL_FLASH_OBGetConfig(ob_config); // 如果检测到出厂漏关 ROP (处于 ROP Level 0) if (ob_config.RDPLevel OB_RDP_LEVEL_0) { // 解锁 FLASH 选项字节控制寄存器 HAL_FLASH_Unlock(); HAL_FLASH_OB_Unlock(); ob_config.OptionType OPTIONBYTE_RDP; ob_config.RDPLevel OB_RDP_LEVEL_1; // 提升至 Level 1 保护 HAL_FLASH_OBProgram(ob_config); HAL_FLASH_OB_Launch(); // 重新加载 Option Bytes 并触发系统复位 HAL_FLASH_OB_Lock(); HAL_FLASH_Lock(); } }2. 固件更新入口防线资源极度受限 8KB Flash下的轻量签名验签在只有 256KB Flash 的 MCU 上移植标准的 mbedTLS 或者 OpenSSL 库光是 RSA-2048 验签代码量就高达 30KB还需要 4KB 的动态 RAM 堆空间是完全不可行的。资源受限环境的最佳安全选择是Ed25519基于 Curve25519 的椭圆曲线数字签名算法公钥长度仅 32 字节。签名长度仅 64 字节。代码量C 语言极简实现如micro-ecc或tweetnacl编译后 Flash 占用不到4KBRAM 占用仅需256 字节。在 Bootloader 校验 OTA 镜像的完整 C 代码实现如下#include stdint.h #include string.h #include ed25519.h // 极简 Ed25519 头文件 // 硬编码在 Bootloader Flash 极简只读区的公钥 (32 字节) static const uint8_t g_vendor_public_key[32] { 0xd7, 0x5a, 0x98, 0x01, 0x82, 0xb1, 0x0a, 0xb7, 0xd5, 0x4b, 0xfe, 0xd3, 0xc9, 0x64, 0x07, 0x3a, 0x0e, 0x17, 0x16, 0x90, 0x80, 0xee, 0x11, 0x49, 0xcd, 0x9d, 0x22, 0x53, 0xa1, 0x9c, 0x30, 0xd5 }; typedef struct { uint32_t payload_len; uint8_t signature[64]; } ota_header_t; int verify_ota_image_signature(uint32_t flash_ota_addr) { const ota_header_t* header (const ota_header_t*)flash_ota_addr; const uint8_t* payload_data (const uint8_t*)(flash_ota_addr sizeof(ota_header_t)); // 执行极速 Ed25519 验签 int is_valid ed25519_verify(header-signature, payload_data, header-payload_len, g_vendor_public_key); if (is_valid 1) { return 0; // 验签成功允许刷入 App } else { return -1; // 验签失败拒绝更新防止变砖或恶意非法固件 } }3. 存储与内存安全防线Dual-Bank 防变砖与静态 SRAM 乱码清零水表、电表等物联网终端往往部署在野外一旦 OTA 失败变砖现场维护成本极其高昂。安全的受限系统方案必须引入Dual-Bank双 BankFlash 分区设计Flash 存储物理划分 (256KB): ------------------------------------------------------------ | Secure Bootloader | App Bank A (Main) | App Bank B (OTA) | | (16KB) | (120KB) | (120KB) | ------------------------------------------------------------原子切换新固件先下载到 Bank B在 Bank B 内完成 Ed25519 验签。只有验签 100% 成功 Bootloader 才修改 Option Bytes 或 Bank 映射寄存器切换运行入口。失败自动回滚若新固件启动后无法在 30 秒内通过 Watchdog 校验向上位机发送健康心跳 Bootloader 会自动切回 Bank A 旧版本固件。敏感内存清零在 Bootloader 跳转至 App 之前必须调用memset将 Bootloader 使用过的 SRAM 区域全部覆写清零防止 App 层通过内存漏洞偷取 Bootloader 遗留的暂存密钥。物理 SWD 锁定、轻量 Ed25519 验签与 Dual-Bank 防变砖机制相辅相成才是 MCU 受限系统生产级安全方案的解题策略。