3、镜像签名与验证机制：数字签名原理（RSA/ECDSA）、哈希链（Hash Chain）、镜像签名工具链（OpenSSL/Python脚本）

镜像签名，说白了就是给固件打个「防伪标签」。你想想看，设备启动时怎么知道加载的镜像是你编译的那个，而不是被人动过手脚的？靠的就是这套签名验证机制。

我入行那会儿，有个项目因为赶工期，跳过了签名验证。结果产品上市后，有用户通过串口刷了个第三方固件，直接把设备变砖了。售后成本高得吓人。从那以后，我再也不敢在签名验证上偷懒。

3.1 数字签名原理：RSA 与 ECDSA

数字签名不是加密，它解决的是「谁写的」和「有没有被改过」这两个问题。核心流程分两步：签名方用私钥签名，验证方用公钥验签。

3.1.1 RSA 签名

RSA 签名基于大整数分解难题。签名时对镜像哈希做私钥加密，验证时用公钥解密比对。我习惯用 2048 位以上的密钥，1024 位已经不安全了。

RSA 的优点是算法成熟，库支持广泛。缺点是签名和验签都比较慢，尤其签名时私钥指数很大，计算量不小。

3.1.2 ECDSA 签名

ECDSA 基于椭圆曲线离散对数难题。同样的安全强度下，ECDSA 的密钥长度比 RSA 短得多。256 位 ECDSA 约等于 3072 位 RSA。

我个人更推荐 ECDSA，尤其在嵌入式场景。密钥短，签名快，占用存储空间也小。不过要注意曲线选择，P-256（secp256r1）是主流，别用那些奇奇怪怪的曲线。

特性	RSA (2048位)	ECDSA (P-256)
密钥长度	2048 位	256 位
签名速度	较慢	较快
验签速度	较慢	较快
存储占用	大	小
嵌入式适用性	一般	推荐

3.2 哈希链（Hash Chain）

哈希链不是用来替代数字签名的，而是用来解决「多个镜像之间的依赖关系」的。比如你的系统有 bootloader、kernel、rootfs 三个镜像，它们必须按顺序加载，且每个镜像的合法性都依赖于前一个。

哈希链的做法很简单：每个镜像的哈希值被嵌入到前一个镜像中。bootloader 里存着 kernel 的哈希，kernel 里存着 rootfs 的哈希。启动时逐级验证，形成一条信任链。

我参与过一个车载项目，要求从 ROM 代码开始，每一级都验证下一级的哈希。整个链有 5 级，任何一级断裂，系统都不能启动。这种设计虽然严格，但能有效防止中间人攻击。

3.3 镜像签名工具链

工具链的选择直接影响签名流程的效率和安全性。我常用的组合是 OpenSSL 加 Python 脚本。OpenSSL 负责底层密码运算，Python 负责流程编排和文件处理。

3.3.1 使用 OpenSSL 生成密钥对

生成 ECDSA P-256 私钥：

openssl ecparam -genkey -name prime256v1 -out private.pem

从私钥导出公钥：

openssl ec -in private.pem -pubout -out public.pem

生成 RSA 2048 私钥：

openssl genrsa -out rsa_private.pem 2048

3.3.2 使用 OpenSSL 签名镜像

先计算镜像哈希，再签名：

openssl dgst -sha256 -sign private.pem -out firmware.sig firmware.bin

验证签名：

openssl dgst -sha256 -verify public.pem -signature firmware.sig firmware.bin

3.3.3 Python 脚本封装

手动敲 OpenSSL 命令容易出错，尤其在生产环境。我习惯写个 Python 脚本，把签名流程自动化。

import subprocess
import hashlib
import os

def sign_image(image_path, private_key_path, output_sig_path):
    # 计算镜像哈希
    sha256_hash = hashlib.sha256()
    with open(image_path, "rb") as f:
        for chunk in iter(lambda: f.read(4096), b""):
            sha256_hash.update(chunk)
    hash_hex = sha256_hash.hexdigest()
    print(f"Image hash: {hash_hex}")

    # 调用 OpenSSL 签名
    result = subprocess.run([
        "openssl", "dgst", "-sha256",
        "-sign", private_key_path,
        "-out", output_sig_path,
        image_path
    ], capture_output=True, text=True)

    if result.returncode != 0:
        raise RuntimeError(f"Signing failed: {result.stderr}")
    print(f"Signature saved to {output_sig_path}")

def verify_image(image_path, public_key_path, sig_path):
    result = subprocess.run([
        "openssl", "dgst", "-sha256",
        "-verify", public_key_path,
        "-signature", sig_path,
        image_path
    ], capture_output=True, text=True)

    if result.returncode == 0:
        print("Signature verification: PASSED")
        return True
    else:
        print("Signature verification: FAILED")
        return False

这个脚本我用了好几年，基本没出过问题。唯一要注意的是，生产环境里别把私钥路径硬编码在脚本里，应该从环境变量或安全配置读取。

3.4 签名验证流程总览

下面这张图展示了从镜像编译到启动验证的完整流程。你可以看到，签名发生在编译服务器上，验证发生在设备启动时。

3.5 常见坑与对策

• 私钥泄露：私钥一旦泄露，整个信任体系就崩塌了。对策是使用 HSM 或密钥管理服务，别把私钥放在普通文件系统里。
• 哈希算法过弱：别用 MD5 或 SHA-1，至少用 SHA-256。我见过有人为了省性能用 MD5，结果被碰撞攻击轻松绕过。
• 签名与镜像分离：签名文件和镜像文件必须一起分发，设备端要同时验证两者。如果签名文件丢了，镜像就废了。
• 公钥被替换：公钥必须存储在安全区域，比如一次性可编程（OTP）存储器。如果公钥可以被替换，那签名验证就形同虚设。

镜像签名不是可有可无的装饰，它是安全启动的基石。选对算法、管好密钥、自动化流程，这三件事做好了，你的启动链就稳了。