4. TEE固件签名与验证：签名算法选择、密钥生成与管理、固件哈希计算、验签流程实现

各位好，欢迎来到第四章。这一章我们聊点硬核的——固件签名与验证。

你想想看，TEE 环境再安全，如果加载的固件被人篡改了，那整个安全根基就塌了。签名验证，就是给固件加一把「数字锁」。我这些年做 TEE 项目，见过太多因为签名环节出纰漏导致设备变砖的案例。嗯，咱们今天就把这块彻底讲透。

4.1 签名算法选择：RSA 还是 ECDSA？

选算法，说白了就是选「安全强度」和「性能开销」的平衡点。目前主流 TEE 方案里，RSA 和 ECDSA 是两大阵营。

对比维度	RSA (2048/4096位)	ECDSA (P-256/P-384)
安全强度	2048位 ≈ 112位对称密钥	P-256 ≈ 128位对称密钥
签名速度	慢（私钥操作）	快（私钥操作）
验签速度	快（公钥操作）	较慢（公钥操作）
密钥体积	大（公钥约256字节）	小（公钥约32字节）
签名体积	固定256/512字节	固定64/96字节
硬件加速	多数TEE支持	部分TEE原生支持

4.2 密钥生成与管理：别把钥匙放在锁旁边

密钥管理是签名体系里最容易翻车的地方。我曾经见过一个团队把签名私钥直接放在 CI 脚本里……嗯，后果可想而知。

4.2.1 密钥生成流程

我推荐使用硬件安全模块（HSM）或 TEE 内部的安全密钥生成接口。下面是一个基于 OpenSSL 的 ECDSA 密钥生成示例，仅供开发阶段使用：

# 生成 ECDSA P-256 私钥
openssl ecparam -genkey -name prime256v1 -out tee_signing_private.pem

# 提取公钥
openssl ec -in tee_signing_private.pem -pubout -out tee_signing_public.pem

# 查看公钥细节
openssl ec -pubin -in tee_signing_public.pem -text -noout

4.2.2 密钥生命周期管理

密钥不是生成出来就完事了。我习惯把密钥生命周期分为五个阶段：

1. 生成：在安全环境中生成，确保随机数质量。
2. 分发：公钥通过证书链分发，私钥永不离开 HSM。
3. 使用：签名操作在 HSM/TEE 内部完成，外部只能拿到签名结果。
4. 轮换：建议每 1-2 年轮换一次签名密钥，旧公钥加入吊销列表。
5. 销毁：私钥退役后必须物理销毁，不能只删除文件。

4.3 固件哈希计算：先摘要，再签名

签名不是直接对固件二进制做运算——那样太慢了。正确的做法是：先计算固件的哈希值，再对哈希值签名。

为什么？因为哈希函数能把任意长度的固件「压缩」成一个固定长度的摘要（比如 SHA-256 是 32 字节）。签名算法只处理这个摘要，效率高得多。

哈希计算示例（C 语言风格）：

#include <openssl/sha.h>

int compute_firmware_hash(const uint8_t *firmware, size_t fw_len,
                          uint8_t *hash_out) {
    SHA256_CTX ctx;
    SHA256_Init(&ctx);
    SHA256_Update(&ctx, firmware, fw_len);
    SHA256_Final(hash_out, &ctx);
    return 0; // 成功
}

4.4 验签流程实现：从固件加载到信任链建立

好了，前面都是准备工作。现在咱们看看真正的验签流程是怎么跑的。

我把整个流程画了一张图，方便你理解：

流程看起来简单，但实际落地时有很多细节。我分享一个实际验签的伪代码实现：

// 验签核心逻辑（伪代码）
int verify_firmware(const uint8_t *fw_bin, size_t fw_len,
                    const uint8_t *signature, size_t sig_len,
                    const uint8_t *public_key, size_t key_len) {
    
    // 1. 计算固件哈希
    uint8_t hash[SHA256_DIGEST_LENGTH];
    compute_firmware_hash(fw_bin, fw_len, hash);
    
    // 2. 使用公钥验签
    // 这里以 ECDSA P-256 为例
    EC_KEY *ec_key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
    if (!ec_key) return -1;
    
    // 导入公钥（实际项目中公钥从 TEE 安全存储读取）
    const unsigned char *p = public_key;
    ec_key = o2i_ECPublicKey(&ec_key, &p, key_len);
    
    // 执行验签
    int ret = ECDSA_verify(0, hash, SHA256_DIGEST_LENGTH,
                           signature, sig_len, ec_key);
    
    EC_KEY_free(ec_key);
    
    // 3. 返回结果
    if (ret == 1) {
        // 验证通过，允许启动
        return 0;
    } else {
        // 验证失败，触发安全响应
        trigger_security_policy();
        return -1;
    }
}

4.5 信任链的建立：从 BootROM 到 TEE OS

单个固件的验签只是起点。真正的安全启动需要建立一条完整的信任链。

我习惯这样设计：

1. BootROM（只读，不可篡改）验签第一级 Bootloader。
2. 第一级 Bootloader 验签 TEE 固件。
3. TEE 固件 验签安全应用和普通世界的内核。

每一级都使用上一级的公钥进行验签，公钥本身通过硬件熔丝或证书链保护。这样，只要 BootROM 是安全的，整个链条就安全。