2、固件签名与验证机制：数字签名原理、固件完整性校验、防篡改机制

好，咱们接着聊固件安全更新。上一章我们讲了为什么要做安全更新，这一章我重点说说怎么保证你下载下来的固件是“原装正品”，没被人动过手脚。

说白了，固件签名与验证就是给固件贴上一张“防伪标签”。你想想看，如果设备连跑在它身上的代码是不是厂家写的都搞不清楚，那还谈什么安全？

2.1 数字签名原理：从“手写签名”到“数学签名”

数字签名不是把你的名字扫描成图片贴上去。它背后是一套非对称加密的玩法。我刚开始接触这个概念时也觉得抽象，后来用了个生活化的比喻才彻底搞明白。

假设你有一把私钥（只有你知道），和一把公钥（全世界都能拿到）。你写了一份固件，想证明这是你写的——

• 签名过程（你这边做）： 用你的私钥对固件的哈希值加密，生成签名。然后把固件 + 签名一起发出去。
• 验证过程（设备那边做）： 设备用你的公钥解密签名，得到哈希值A。同时设备自己算一遍固件的哈希值B。如果A == B，说明固件没被改过，而且确实是你签的。

这里有个关键点：私钥绝对不能泄露。我在一个项目里见过有人把私钥直接硬编码在编译脚本里，还上传到了Git仓库……嗯，那场面，简直是灾难。

2.2 固件完整性校验：不只是“算个哈希”那么简单

完整性校验听起来简单——算个哈希，对比一下。但实际落地时，坑比想象的多。

我记得有一次，设备OTA升级后频繁死机。查了半天，发现是固件包在传输过程中被截断了几个字节，但校验居然通过了。为什么？因为那个团队只校验了固件头的哈希，没校验整个固件体。

所以，真正的完整性校验应该覆盖整个固件镜像，包括：

• 固件头（版本号、硬件ID、签名算法标识等）
• 固件体（实际的可执行代码和数据）
• 签名块（签名本身也要校验格式合法性）

常用的哈希算法，我建议至少用SHA-256。SHA-1已经被证明可以碰撞了，别再用。MD5？那玩意儿现在连防君子都防不住。

算法	输出长度	安全性	我的建议
MD5	128位	已破解，可碰撞	❌ 别用
SHA-1	160位	已破解，可碰撞	❌ 别用
SHA-256	256位	目前安全	✅ 推荐
SHA-384/512	384/512位	更安全，但开销大	✅ 资源充裕时用

2.3 防篡改机制：从“防君子”到“防小人”

签名和校验只是第一步。真正的防篡改，需要一套组合拳。我个人习惯把防篡改分成三个层次：

2.3.1 存储层防篡改

固件烧录到Flash后，能不能被直接读出来改掉？能。所以：

• Flash读写保护： 启用芯片的读保护（RDP）和写保护（WPR）。
• 安全存储区： 把公钥、签名算法ID等关键元数据放在OTP（一次性可编程）区域或安全元件里。
• 加密存储： 固件在Flash里以密文形式存放，运行时再解密。

2.3.2 启动链防篡改

设备上电后，谁先跑？Bootloader。如果Bootloader被改了，后面全是白搭。所以：

• 信任根（RoT）： 芯片内部固化的、不可更改的Boot ROM，作为第一条信任链。
• 安全启动（Secure Boot）： 每一级启动代码都要验证下一级的签名。Boot ROM验证Bootloader，Bootloader验证OS Kernel，Kernel验证App固件。
• 回滚保护： 禁止升级到比当前版本更旧的固件。我见过一个案例，攻击者把设备降级到一个有已知漏洞的旧版本，然后轻松拿下控制权。

2.3.3 运行时防篡改

固件跑起来了，攻击者能不能通过漏洞注入代码修改运行中的内存？能。所以：

• 代码段只读： 利用MPU/MMU把代码段设为只读，防止运行时修改。
• 栈保护： 开启栈Canary，防止栈溢出覆盖返回地址。
• 地址随机化（ASLR）： 让攻击者猜不到代码和数据在内存中的位置。

2.4 固件签名与验证流程全景图

下面这张图，是我自己画的一个完整流程。从开发环境到设备端，每一步都标清楚了。你仔细看一遍，基本就能理解整个体系是怎么串起来的。

2.5 常见签名方案对比

实际项目中，选哪种签名方案，取决于你的芯片算力、功耗预算和安全等级。我列个表，你根据自己情况选。

方案	算法	签名大小	验证速度	适用场景
RSA-2048	RSA + SHA-256	256字节	较慢（指数运算）	网关、服务器、算力较强的设备
ECDSA P-256	ECDSA + SHA-256	64字节	较快（椭圆曲线）	MCU、传感器、资源受限设备
Ed25519	EdDSA + SHA-512	64字节	极快（恒定时间）	IoT设备、高性能需求场景
HMAC（对称）	HMAC-SHA256	32字节	极快	内部网络、可信环境（不推荐用于公网）

2.6 代码示例：固件签名与验证（伪代码）

下面给一段伪代码，帮你理解实际实现时的逻辑。注意，这不是生产级代码，但核心流程是对的。

// ===== 签名端（开发环境） =====
function signFirmware(firmwareBinary, privateKey):
    // 1. 计算固件哈希
    hash = SHA256(firmwareBinary)
    
    // 2. 用私钥签名哈希
    signature = ECDSA_Sign(privateKey, hash)
    
    // 3. 打包固件包
    firmwarePackage = {
        header: {
            magic: 0xAA55,
            version: 2.1,
            hardwareID: 0x1234,
            hashAlgo: "SHA256",
            signAlgo: "ECDSA_P256"
        },
        body: firmwareBinary,
        signature: signature
    }
    
    return firmwarePackage

// ===== 验证端（设备端） =====
function verifyFirmware(firmwarePackage, publicKey):
    // 1. 解析固件包
    header = firmwarePackage.header
    body = firmwarePackage.body
    signature = firmwarePackage.signature
    
    // 2. 校验固件头合法性
    if header.magic != 0xAA55:
        return FAIL("无效的固件头")
    
    // 3. 计算固件体哈希
    hash = SHA256(body)
    
    // 4. 用公钥验证签名
    if ECDSA_Verify(publicKey, hash, signature) == TRUE:
        // 5. 检查版本号（防回滚）
        if header.version >= currentVersion:
            return PASS
        else:
            return FAIL("版本过低，拒绝降级")
    else:
        return FAIL("签名验证失败，固件可能被篡改")