4. 密码学基础

固件升级的安全验证，本质上是一组密码学原语的组合运用。理解每种原语“能解决什么问题、不能解决什么问题”，是设计升级方案的前提。本章从工程视角梳理六类核心机制，并给出在固件验证场景下的选型原则。

一、核心原理：六类原语的角色分工

哈希（Hash）是单向压缩函数，把任意长度固件映像映射为固定长度摘要，如 SHA-256 输出 32 字节。它提供完整性，但不提供任何身份保证——攻击者可以同时替换固件和摘要。因此哈希只能作为其他机制的“被保护对象”。

对称加密（如 AES-128/256-GCM）用同一密钥加解密，速度快、适合大块固件数据，但密钥分发困难：设备端必须预置密钥，一旦泄露则全部设备失守。它解决机密性，不解决来源真实性。

非对称加密（如 RSA、ECC）使用公私钥对。私钥签名、公钥验证，天然适合“一对多”的固件分发：厂商持私钥，海量设备只存公钥。它解决来源真实性与不可否认性，但运算慢，通常只用于签名摘要而非整包固件。

数字签名 = 哈希 + 非对称加密。先对固件算摘要，再用私钥对摘要签名；设备端用公钥验签并比对摘要。它同时提供完整性与真实性，是固件验证的主干机制。

证书链解决“公钥本身是否可信”的问题。设备不直接信任某个公钥，而是信任一个根 CA，通过“根 CA → 中间 CA → 固件签名证书”的链式签名逐级验证，最终确认签名公钥归属合法厂商。

HMAC（基于哈希的消息认证码）用共享密钥同时提供完整性与真实性，速度快、实现简单，但属于对称机制：验证方与签名方共享同一密钥，无法防抵赖，且密钥泄露即全面失守。

二、方法流程：从签名到设备验证的完整链路

厂商侧构建签名包的标准流程如下：

# 1. 计算固件摘要
sha256sum firmware.bin > firmware.sha256

# 2. 用私钥对摘要签名（ECDSA P-256 示例）
openssl dgst -sha256 -sign vendor_private.pem \
  -out firmware.sig firmware.bin

# 3. 打包：固件 + 签名 + 签名证书 + 中间CA证书
tar -cf update.pkg firmware.bin firmware.sig \
  signer_cert.pem intermediate_ca.pem

设备端验证顺序不可颠倒：先验证书链，再验签名，最后比对摘要。若先验签名再验证书，攻击者可用自签证书绕过信任锚。验证通过后才允许写入，且写入前应再次校验目标分区完整性。

三、选型原则与对比

四、案例与误区复盘

案例：某 IoT 厂商早期固件升级仅使用 SHA-256 摘要校验。攻击者篡改固件后同步替换摘要文件，设备照常升级，导致批量设备被植入后门。复盘结论：摘要必须被签名保护，否则完整性形同虚设。

误区一：用 HMAC 替代数字签名做对外升级。HMAC 密钥必须预置在每台设备中，一旦某台设备被物理提取密钥，全部设备失去真实性保障，且厂商无法抵赖。对外分发应使用非对称签名。

误区二：忽略证书链验证。只校验签名证书本身而不回溯到根 CA，攻击者可用自签证书通过验证。必须完整验证“根→中间→签名证书”的每一级签名与有效期。

误区三：签名算法与密钥长度过时。SHA-1 与 RSA-1024 已不安全，固件签名应使用 SHA-256 及以上、RSA-2048/3072 或 ECDSA P-256/P-384。ECC 在同等安全强度下密钥更短，更适合资源受限设备。