分区表校验机制：从CRC到签名的层层防护

分区表是固件升级的「地图」。地图错了，升级必然翻车。

我早年做消费类产品时，遇到过这么个事：OTA升级后设备变砖，查了三天，最后发现是分区表被篡改了一个字节——起始地址偏移了4KB。从那以后，我对分区表校验这件事，再也不敢马虎。

这一章，咱们就把分区表的校验机制讲透。说白了就三件事：怎么发现数据坏了、怎么确认数据没被改过、校验失败该怎么办。

3.1 校验手段的三种层次

分区表校验不是「有就行」，而是要看场景选方案。我习惯把校验手段分成三个层次：

层次	校验方式	防护能力	计算开销	典型场景
基础	CRC32	检测随机错误	极低	内部存储校验
进阶	哈希校验（SHA256）	防篡改（无密钥）	中等	固件完整性验证
高级	签名校验（RSA/ECDSA）	防伪造+防篡改	较高	安全启动、公网升级

你想想看，如果你的设备只在内部Flash里读写分区表，CRC32就够了。但如果分区表要通过网络下发，那签名校验就是底线。

3.2 CRC32校验：轻量级的「数据指纹」

CRC32不是加密算法，它就是个循环冗余校验。它能检测出数据在传输或存储过程中的随机比特翻转，但对抗不了恶意篡改。

为什么？因为CRC32没有密钥，攻击者改了数据后，可以重新计算CRC32填回去，你根本发现不了。

核心要点：CRC32只防「意外」，不防「人为」。

代码实现很简单，我贴一个嵌入式里常用的查表法：

// CRC32查表法实现
static uint32_t crc32_table[256];

void crc32_init_table(void) {
    for (uint32_t i = 0; i < 256; i++) {
        uint32_t crc = i;
        for (int j = 0; j < 8; j++) {
            if (crc & 1)
                crc = (crc >> 1) ^ 0xEDB88320;
            else
                crc >>= 1;
        }
        crc32_table[i] = crc;
    }
}

uint32_t crc32_calc(uint8_t *data, uint32_t len) {
    uint32_t crc = 0xFFFFFFFF;
    for (uint32_t i = 0; i < len; i++) {
        uint8_t index = (crc ^ data[i]) & 0xFF;
        crc = (crc >> 8) ^ crc32_table[index];
    }
    return crc ^ 0xFFFFFFFF;
}

实际项目中，我会把CRC32值放在分区表的末尾。Bootloader读取分区表时，先算一遍CRC，再跟末尾的值比对。不一致就直接回滚到备份分区表。

我的习惯：CRC32多项式用0xEDB88320（IEEE 802.3标准），这样跟PC工具算出来的值一致，调试时方便比对。

3.3 哈希校验：给分区表上「防篡改锁」

哈希校验比CRC32进了一步。SHA256这类哈希函数有个特性：输入变一点点，输出天翻地覆。而且从哈希值反推原始数据，计算上不可行。

但哈希校验有个前提——你得有个可信的哈希值参照。这个参照存在哪？

存在Bootloader里：最安全，但Bootloader不能随便改
存在另一个存储区域：比如eFuse或OTP，防物理篡改
从服务器下发：需要配合签名，否则中间人攻击

我曾在某个IoT项目里用过这种方案：分区表本身不加密，但它的SHA256哈希值用硬件安全模块（HSM）存储。Bootloader启动时，从HSM读哈希，跟分区表算出来的比对。这样即使攻击者能改Flash，也改不了HSM里的值。

注意：哈希校验只能保证「数据没被改过」，但不能保证「数据来自合法发布方」。要解决后者，必须上签名。

3.4 签名校验：终极防线

签名校验是目前嵌入式安全领域的标准答案。流程是这样的：

开发阶段：用私钥对分区表签名，生成签名值
发布阶段：分区表 + 签名值一起打包下发
验证阶段：设备用公钥验签，通过才认可

常用的签名算法有两种：

算法	密钥长度	签名大小	验签速度	推荐场景
RSA-2048	2048 bit	256 字节	较慢	MCU资源充足
ECDSA-P256	256 bit	64 字节	较快	资源受限设备

我个人更倾向ECDSA。原因很简单：签名短、验签快，对Cortex-M4这类MCU很友好。RSA虽然生态成熟，但2048位的签名有256字节，在小Flash里挺占地方的。

验签代码大致长这样：

// 伪代码：ECDSA验签流程
bool verify_partition_table_signature(
    uint8_t *table, uint32_t table_len,
    uint8_t *signature, uint32_t sig_len,
    uint8_t *public_key) 
{
    // 1. 计算分区表哈希
    uint8_t hash[32];
    sha256_calc(table, table_len, hash);
    
    // 2. ECDSA验签
    ecdsa_verify_result result;
    ecdsa_verify(public_key, hash, sizeof(hash), 
                 signature, sig_len, &result);
    
    // 3. 返回结果
    return (result == ECDSA_VERIFY_PASS);
}

关键点：公钥必须安全存储。如果公钥能被替换，签名校验就形同虚设。我一般把公钥烧录在eFuse或Bootloader的只读区域。

3.5 校验失败的处理策略

校验失败不可怕，可怕的是没有预案。我见过太多产品，校验失败直接死循环，连恢复的机会都没有。

合理的处理策略应该是分级响应：

策略一：静默回滚（推荐）

这是最优雅的方式。Bootloader发现主分区表校验失败，自动切换到备份分区表，然后正常启动。用户完全无感知。

// 回滚逻辑示例
bootloader_status_t load_partition_table(void) {
    // 尝试主分区表
    if (verify_partition_table(PRIMARY_TABLE_ADDR)) {
        return BOOT_OK;
    }
    
    // 主分区表校验失败，尝试备份
    log_warn("Primary partition table invalid, trying backup...");
    
    if (verify_partition_table(BACKUP_TABLE_ADDR)) {
        log_info("Backup partition table loaded successfully");
        return BOOT_OK_BACKUP;
    }
    
    // 两个都坏了，进入恢复模式
    log_error("Both partition tables corrupted!");
    return BOOT_ERROR;
}

策略二：进入恢复模式

如果主备都坏了，设备不能变砖。应该进入一个最小可恢复系统，比如：

启动一个极简的恢复Bootloader
监听特定GPIO电平或串口命令
通过USB/串口接收新的分区表

策略三：记录错误并重试

有时候校验失败是瞬时的（比如电源波动导致读取错误）。可以尝试重新读取并校验，连续失败N次后再执行回滚。

我曾经踩过的坑：某次量产时发现约0.1%的设备启动失败。查到最后，是Flash读取时序在低温下不稳定，导致CRC32偶尔算错。解决方案不是改校验算法，而是加了两次重试。嗯，硬件问题有时候比软件问题更隐蔽。

3.6 本章知识体系总览

下面这张图把分区表校验的完整链路画出来了，从校验方式到失败处理，一目了然：

3.7 小结

分区表校验这件事，没有「一刀切」的方案。选CRC32还是选签名，取决于你的产品对安全的要求有多高。

我个人给团队定的选型原则是这样的：

消费类小家电：CRC32 + 备份分区表，够用
IoT网关/智能锁：SHA256哈希 + 硬件安全存储
车规/医疗/金融：ECDSA签名 + 安全启动链

📚 课程目录

分区表校验机制：从CRC到签名的层层防护

3.1 校验手段的三种层次

3.2 CRC32校验：轻量级的「数据指纹」

3.3 哈希校验：给分区表上「防篡改锁」

3.4 签名校验：终极防线

3.5 校验失败的处理策略

策略一：静默回滚（推荐）

策略二：进入恢复模式

策略三：记录错误并重试

3.6 本章知识体系总览

3.7 小结