1. 项目缘起为什么要在资源受限的MCU上折腾可信启动最近在做一个工业边缘数据采集的项目主控用的是中科蓝讯的AB32VG1开发板跑RT-Thread操作系统。项目临近交付客户突然提了一个要求设备固件要防篡改启动过程要能验证确保上电跑的是我们签名的“正经”代码而不是被人恶意刷入的“李鬼”程序。这个要求听起来很合理但在AB32VG1这种典型的MCU环境里实现却让我头疼了好一阵。AB32VG1基于RISC-V架构主频120MHz内置640KB Flash和192KB SRAM资源说不上捉襟见肘但也绝对不算富裕。传统的“可信启动”或“安全启动”概念往往和ARM TrustZone、HSM硬件安全模块、TPM可信平台模块这些“高大上”的名词绑定需要硬件层面的强力支持。而AB32VG1这类通用MCU硬件上并没有专为安全设计的安全启动ROM或不可变的根密钥。那么在资源受限、无专用安全硬件的环境下实现一个“够用”的可信启动还有可能吗答案是肯定的。这个项目就是一次具体的实践在RT-Thread操作系统上为AB32VG1设计并实现一套基于软件密码学、引导顺序控制和运行时校验的嵌入式可信启动方案。它可能达不到银行级的安全标准但足以应对固件被恶意替换、设备被“越狱”等常见威胁为物联网边缘设备建立起第一道安全防线。2. 可信启动的核心逻辑从“信任根”到“链式验证”在深入代码之前我们必须先厘清“可信启动”到底在干什么。它的核心思想叫做“信任链”Chain of Trust。想象一下古代传递军令第一道命令信任根必须绝对可靠然后每一级军官在向下传达时都要验证上一级的印信签名确认无误后才执行并继续传递。如果中间任何一环印信对不上就说明命令可能被篡改必须停止执行。在嵌入式系统里这个“信任链”通常是这样的信任根Root of Trust这是整个链条的起点必须是系统内唯一、不可篡改、绝对可信的代码或数据。在有安全硬件的芯片里它可能是一段烧死在ROM里的引导代码和公钥。在我们的AB32VG1方案里由于缺乏硬件支持我们需要在软件层面“构造”一个尽可能稳固的信任起点。一级引导加载器BL0验证信任根代码首先验证一级引导加载器比如芯片内部的BootROM或者我们烧录在Flash起始地址的Bootloader的完整性和真实性。验证通过后才将控制权交给它。二级引导加载器/RT-Thread镜像验证一级引导加载器被信任后它负责去验证接下来要运行的代码比如RT-Thread操作系统的镜像文件。验证通过后加载并跳转执行。应用层验证可选RT-Thread内核启动后还可以进一步验证其上层应用比如你的业务逻辑线程的完整性。对于AB32VG1芯片上电后默认从0x00000000地址Flash起始开始执行。我们没有硬件熔断的密钥所以“信任根”无法做到物理不可变。退而求其次我们的策略是将一段极其精简、功能单一的“安全引导头”Secure Boot Header作为事实上的信任根并利用Flash的写保护机制尽可能将其“固化”。整个验证链条简化为芯片硬件 → 安全引导头验证Bootloader→ Bootloader验证RT-Thread镜像→ RT-Thread内核。下面我们就来拆解每一个环节的具体实现。3. 方案设计与关键组件选型3.1 总体启动流程设计我们的Flash空间布局和启动流程需要重新规划。传统的简单项目可能直接把RT-Thread的镜像烧录到0x8000000Flash起始上电就运行。现在为了加入验证流程变得复杂上电 ↓ 执行 Flash 0x00000000 处的“安全引导头” ↓ 安全引导头验证 0x00004000 处的“Bootloader”签名 ↓ 验证成功 ——否—— 进入故障处理如红灯闪烁 ↓是 跳转到 Bootloader ↓ Bootloader验证 0x00010000 处的“RT-Thread Firmware”签名 ↓ 验证成功 ——否—— 进入故障处理如尝试恢复备份固件 ↓是 跳转到 RT-Thread 内核入口 ↓ RT-Thread 启动可选进行应用完整性检查 ↓ 运行用户应用程序地址说明以AB32VG1的1MB Flash为例0x00000000 - 0x00003FFF: 安全引导头区域16KB。存放验证逻辑和公钥。0x00004000 - 0x0000FFFF: Bootloader区域48KB。负责初始化基础硬件、验证主固件、升级逻辑等。0x00010000 - 0x000EFFFF: 主固件RT-Thread App区域896KB。0x000F0000 - 0x000FFFFF: 备份区/参数存储区64KB。可用于存放备份固件或设备唯一密钥。3.2 密码学算法选型在资源与安全间权衡密码学是可信启动的基石主要用到两种技术哈希Hash用于计算固件的“数字指纹”确保完整性数据没被改动。常用SHA-256。数字签名Signature用于验证固件的真实性确实来自合法的开发者。常用ECDSA椭圆曲线数字签名算法或RSA。在MCU上我们必须考虑算法对CPU和内存的消耗RSA验证速度快但签名长度较长例如RSA-2048的签名是256字节公钥也较大。在Flash中存储多个公钥或签名会占用较多空间。ECDSA以更短的密钥长度如ECC-256提供与RSA-2048相当的安全强度签名长度更短例如64字节节省Flash空间。但签名生成和验证的计算量比RSA略大。对于AB32VG1我选择了ECDSA with secp256r1曲线。原因如下空间优势签名和公钥更小对于存储空间紧张的Bootloader区域非常友好。安全性足够NIST P-256secp256r1是行业广泛接受的标准安全性对于物联网设备绰绰有余。有现成优化库RT-Thread的软件包生态系统中有tinycrypt或mbedtls的裁剪版它们都支持ECC并且针对嵌入式设备有优化。注意如果项目对启动速度极其敏感例如要求1秒内完成所有验证并进入应用可能需要实测对比RSA验证和ECDSA验证在AB32VG1上的耗时。有时RSA的验证速度优势可能更明显。3.3 工具链与开发环境准备实现这个方案需要一系列工具配合签名工具离线在PC端运行我们需要一个程序在编译生成RT-Thread的bin文件后为其计算哈希值并用开发者的私钥进行签名然后将签名附加到bin文件末尾或生成一个独立的签名文件。这个工具可以用Pythonecdsa库或C语言结合mbedtls库来写。# 一个极简的Python签名工具示例思路 import hashlib, ecdsa # 1. 读取固件bin文件 with open(rtthread.bin, rb) as f: firmware_data f.read() # 2. 计算SHA-256哈希 hash_obj hashlib.sha256(firmware_data).digest() # 3. 加载私钥PEM格式 with open(private_key.pem, r) as f: private_key ecdsa.SigningKey.from_pem(f.read()) # 4. 对哈希值进行签名 signature private_key.sign(hash_obj) # 5. 将签名附加到固件末尾或单独存放 signed_firmware firmware_data signature with open(rtthread_signed.bin, wb) as f: f.write(signed_firmware)密钥管理务必妥善保管私钥private_key.pem它代表了开发者的身份一旦泄露攻击者就可以签发任意恶意固件。公钥public_key.c则会被编译进安全引导头和Bootloader中。绝对不要将私钥硬编码到设备固件里。RT-Thread 开发环境使用scons进行项目编译。需要为Bootloader和主应用分别创建不同的工程并配置不同的链接脚本link.lds来指定它们烧录到Flash的绝对地址。4. 安全引导头实现构筑信任起点安全引导头是整个链条的第一环必须尽可能简单、健壮。它的代码量要小功能要单一就是验证Bootloader然后跳转。4.1 代码结构与内存布局由于它位于Flash最开头我们需要用汇编或纯C不依赖任何库函数来编写核心验证逻辑。通常包含以下部分向量表重置简单的堆栈指针设置和跳转到main函数。公钥存储将用于验证Bootloader签名的公钥一个secp256r1的公钥点约64字节以常量数组形式硬编码在代码中。Flash读取函数提供从指定Flash地址读取数据到内存的函数。密码学验证函数实现ECDSA签名验证的算法。这里可以直接嵌入一个高度裁剪的tinycrypt的ecc_verify函数实现。主逻辑读取Bootloader区域的镜像和其附带的签名调用验证函数根据结果决定跳转或进入错误处理。它的链接脚本需要将.text代码段和.rodata只读数据如公钥严格定位在0x00000000开始的位置。4.2 验证逻辑详解安全引导头启动后的操作序列初始化最小硬件可能只需要初始化系统时钟和必要的GPIO用于错误指示LED。定位Bootloader信息从约定好的地址如0x00004000 Bootloader长度读取附加的ECDSA签名。同时从0x00004000开始读取Bootloader的二进制内容到内存缓冲区或计算流式哈希。计算哈希对Bootloader的二进制内容计算SHA-256哈希值。验证签名使用内置的公钥对“步骤3得到的哈希值”和“步骤2读取的签名”进行ECDSA验证。决策与跳转验证成功将PC程序计数器指针跳转到Bootloader的入口地址0x00004000 向量表偏移。验证失败触发错误处理例如让一个LED快速闪烁然后陷入死循环或执行软复位。切勿跳转到未经验证的代码4.3 提升“信任根”安全性的实践技巧既然硬件无法提供绝对信任根我们就在软件和工艺上想办法启用Flash写保护AB32VG1的Flash通常可以设置写保护区域。在量产时通过Bootloader或调试工具将安全引导头所在的扇区如前16KB设置为只读。这样即使设备被入侵攻击者也很难修改这段核心验证代码。注意设置写保护前务必确保代码100%正确否则设备将“变砖”。代码混淆与精简安全引导头的代码应避免使用复杂的控制流和字符串减少被逆向分析的风险。所有关键函数尽量内联。心跳检测安全引导头可以在跳转前在一个GPIO上输出一个特定脉冲。主程序运行后可以监控这个脉冲。如果脉冲消失可能意味着系统被复位后未经过安全引导头例如通过调试接口直接跳转可以触发安全警报。5. Bootloader实现承上启下的验证者Bootloader是功能更丰富的一环。它被安全引导头验证后就成为了可信代码它的任务是去验证并加载最终的RT-Thread固件。5.1 Bootloader的双重职责固件验证与加载这是核心任务。流程与安全引导头类似 a. 从主固件区0x00010000读取RT-Thread镜像。 b. 从约定位置如镜像文件末尾读取该镜像的签名。 c. 使用另一套公钥与验证安全引导头的公钥不同实现密钥分离验证签名。 d. 验证成功则跳转到RT-Thread的复位向量失败则尝试跳转到备份固件区或进入升级模式。固件升级OTA提供一个接口如串口、蓝牙、Wi-Fi用于接收新的、已签名的固件包将其写入备份区并在下次启动时切换过去。5.2 在Bootloader中集成密码学库Bootloader可以链接一个轻量级的加密库如mbedtls的裁剪配置。在rtconfig.h中我们只启用需要的功能#define MBEDTLS_SHA256_C #define MBEDTLS_ECDSA_C #define MBEDTLS_ECP_DP_SECP256R1_ENABLED #define MBEDTLS_BIGNUM_C #define MBEDTLS_OID_C #define MBEDTLS_ASN1_PARSE_C #define MBEDTLS_ASN1_WRITE_C // 关闭所有SSL/TLS、非必要的密码套件、平台无关函数等以节省空间然后在Bootloader代码中调用mbedtls_ecdsa_verify函数进行验证。5.3 处理镜像格式RT-Thread的bin文件RT-Thread编译后通常生成.elf文件和.bin文件。.bin是纯二进制镜像不包含地址信息。Bootloader需要知道镜像的准确长度和入口地址。方法一推荐在.bin文件头部添加一个小的信息头Header。例如头结构包含魔数Magic、固件大小、版本号、SHA-256哈希值、ECDSA签名。这样Bootloader先解析头获取大小再读取正确的数据量进行哈希计算。方法二依赖链接脚本的固定定义。确保RT-Thread镜像的链接地址从0x00010000开始并且Bootloader知道镜像的固定最大尺寸。计算哈希时就读取这个固定大小的区域。缺点是可能会哈希到Flash末尾的无效数据0xFF需要镜像本身严格对齐。我们的签名工具需要在生成.bin文件后为其添加这个信息头包含签名。Bootloader则首先读取这个头提取出签名和声明的固件长度然后根据长度读取固件数据计算哈希最后用头中的签名进行验证。6. RT-Thread侧的配合与运行时完整性检查当Bootloader将控制权交给RT-Thread后可信启动的“启动”部分就完成了。但安全是一个持续的过程。我们可以在RT-Thread内核启动后增加一道运行时检查。6.1 内核启动初期的自检在RT-Thread的main函数或rtthread_startup的早期可以添加一个自检函数。这个函数可以验证自身关键代码段计算.text段的CRC32或哈希值与一个预先烧录在Flash只读区域如安全引导头附近的基准值对比。这可以防止运行时通过漏洞修改内核代码。验证关键数据检查系统配置参数是否被篡改。// 示例在RT-Thread启动早期进行自检 int firmware_self_check(void) { uint32_t computed_crc calculate_crc_over_range((uint32_t*)_stext, (uint32_t*)_etext); uint32_t stored_crc *(uint32_t*)STORED_CRC_ADDRESS; if (computed_crc ! stored_crc) { rt_kprintf(FATAL: Kernel text CRC mismatch!\n); // 触发安全响应停止调度、擦除密钥、重启等 take_security_action(); return -RT_ERROR; } return RT_EOK; } // 在 startup.c 的 rtthread_startup() 中调用6.2 对外设和驱动的保护可信启动确保了软件起点的纯净但设备安全还涉及外设。例如防止通过未经验证的调试接口如JTAG/SWD访问内存。虽然AB32VG1可能没有专用的调试认证功能但可以在初始化后尝试禁用或锁定调试端口如果芯片支持相关寄存器操作。注意此操作不可逆仅适用于量产设备。7. 开发、调试与量产工作流实现可信启动后整个开发、测试和量产流程都需要调整。7.1 完整的镜像构建与签名流程编译主应用在RT-Thread项目目录下使用scons编译生成rtthread.elf和rtthread.bin。生成签名运行自定义的Python签名工具输入rtthread.bin和开发者私钥输出带签名的rtthread_signed.bin。这个工具会在.bin文件末尾附加信息头含签名和长度。编译Bootloader在Bootloader项目目录下使用scons编译。Bootloader的代码里已经硬编码了验证主固件的公钥。它编译后生成bootloader.bin。签名Bootloader运行签名工具使用另一对专用于Bootloader的密钥为bootloader.bin生成签名得到bootloader_signed.bin。编译安全引导头编译安全引导头项目生成secure_header.bin。它内部包含了验证Bootloader的公钥。组合最终镜像使用dd或Python脚本将三个文件按地址偏移合并成一个完整的Flash镜像# 示例合并命令 dd if/dev/zero offull_image.bin bs1k count1024 # 创建1MB空文件 dd ifsecure_header.bin offull_image.bin convnotrunc # 写入开头 dd ifbootloader_signed.bin offull_image.bin bs1k seek16 convnotrunc # 从16KB处写入 dd ifrtthread_signed.bin offull_image.bin bs1k seek64 convnotrunc # 从64KB处写入烧录与测试使用编程器或调试器将full_image.bin烧录到AB32VG1的Flash中进行上电测试。7.2 调试技巧与常见“坑点”“变砖”救援在开发阶段验证逻辑有bug或签名不对会导致启动失败设备“黑屏”。务必保留一个物理调试接口如UART或一个未被写保护的“救援Bootloader”。救援Bootloader可以放在Flash后面通过按住某个按键上电来触发它忽略验证直接通过网络或串口接收新固件进行刷写。签名验证失败99%的情况是镜像布局或签名处理不对。仔细检查安全引导头/Bootloader中公钥的编码格式是否是裸的X, Y坐标字节流。签名工具生成的签名格式通常是ASN.1 DER编码或裸的r, s拼接与验证代码中期待的格式是否一致。计算哈希的数据范围是否完全一致是否包含了信息头是否多读了或少读了字节。性能考量在AB32VG1上计算SHA-256和ECDSA验证需要时间。实测下来验证一个500KB的固件可能需要几百毫秒到1秒。如果启动时间敏感可以考虑只验证固件的前面一部分关键代码段如向量表、初始化代码。使用更快的哈希算法如SHA-256硬件加速如果芯片支持。在Bootloader中显示进度条或状态让用户感知到验证过程。7.3 量产考量密钥管理量产时用于签名的私钥必须离线保存在安全的服务器HSM上。烧录到设备中的是公钥。每个产品可以使用相同的公钥也可以使用同一主密钥派生的不同公钥更复杂。写保护在烧录完最终镜像后通过Bootloader或量产工具将安全引导头区域甚至整个Bootloader区域设置为写保护。版本回滚保护为了防止攻击者用旧版本有漏洞的已签名固件替换新版本可以在信息头中加入版本号或时间戳。Bootloader验证时不仅要验证签名有效还要检查固件版本号必须大于设备内存储的当前版本号。8. 方案评估与局限性我们实现的这套基于RT-Thread和AB32VG1的可信启动方案是一个在有限硬件条件下达成的务实安全方案。它的优势在于成本极低无需更换硬件利用现有芯片和开源软件栈实现。有效防御一类攻击能有效防止攻击者通过串口、SWD等接口随意刷入未签名的恶意固件提升了物理接触攻击的门槛。与RT-Thread生态良好融合可以利用RT-Thread的软件包如mbedtls和构建系统开发效率较高。其局限性也非常明显信任根非硬件固化安全引导头本身存储在Flash中虽然可写保护但理论上仍有可能通过芯片漏洞或物理攻击如Flash解焊读取被篡改或旁路。这无法达到专用安全芯片的级别。运行时保护有限方案重点在启动阶段对于系统启动后内存中的代码和数据被运行时漏洞修改的攻击防护较弱。需要结合其他技术如MPU内存保护单元划分权限等。密钥一旦泄露后果严重如果用于签名的私钥泄露攻击者就可以签发任何合法固件。因此私钥的保护至关重要。适用场景这套方案非常适合对成本敏感、但又需要一定固件防篡改能力的物联网设备如智能家居设备、工业传感器、消费级电子产品等。它是对“毫无防护”状态的一次显著升级能够抵挡大多数简单的、非针对性的软件攻击。最后安全是一个持续的过程没有一劳永逸的方案。可信启动是设备安全架构的第一块基石。在AB32VG1这类资源受限的平台上实现它更像是一次平衡艺术在有限的内存、闪存和算力下尽可能编织一张细密的安全网。这个过程让我深刻体会到嵌入式安全不仅仅是算法的堆砌更是对系统每一处细节的审慎考量和对潜在威胁的清醒认知。