1. 固件签名概述：为什么需要它？
大家好，我是老周。做嵌入式安全这行十几年了，今天咱们聊聊固件签名。
你想想看，一个设备从产线烧录到用户手里，中间要经过多少环节？供应链、OTA 升级、售后维护……每个环节都可能被动手脚。我见过最典型的案例——某 IoT 厂商的摄像头，固件没签名，黑客直接改了升级包，把后门塞进去，整个设备成了肉鸡。嗯，这就是为什么我们需要固件签名。
1.1 为什么需要固件签名？
说白了，固件签名解决三个核心问题：
- 完整性校验——确保固件在传输或存储过程中没被篡改。哪怕改了一个 bit，签名验证就会失败。
- 来源认证——确认固件确实来自你信任的厂商，而不是第三方伪造的恶意版本。
- 抗抵赖性——厂商不能否认某个固件是自己签发的，这在法律合规场景下很重要。
我在一个车规级项目里遇到过：客户要求所有 ECU 固件必须签名，否则产线直接拒烧。当时我们用的是 RSA-2048 + SHA-256，验证一次大概 50ms，完全能接受。但如果你用 ECDSA，速度还能再快一倍。
核心原则：固件签名不是可选项，而是安全基线。没有签名的设备，就像没锁门的房子——不是一定会被偷，但风险完全不可控。
1.2 签名与加密的区别
很多新手容易搞混这两个概念。我简单解释一下：
| 特性 | 固件签名 | 固件加密 |
|---|---|---|
| 目的 | 验证完整性和来源 | 保护内容机密性 |
| 密钥 | 私钥签名，公钥验签 | 公钥加密，私钥解密 |
| 输出 | 固件 + 签名值（明文可见） | 密文（不可读） |
| 典型算法 | RSA-PSS, ECDSA, Ed25519 | AES, ChaCha20, RSA-OAEP |
| 能否防篡改 | 能 | 不能（加密不防改） |
| 能否防泄露 | 不能 | 能 |
举个例子你就明白了：签名就像你在合同上盖的章——别人能看到合同内容，但改不了你的章。加密就像把合同锁进保险柜——别人看不到内容，但一旦打开，改完再锁上你也不知道。
注意：签名和加密可以同时使用。我建议的做法是：先对固件哈希签名，再对整个包（固件+签名）加密。这样既防篡改又防泄露。但千万别搞反顺序——先加密再签名，验签时你得先解密，流程就复杂了。
1.3 签名流程简介
标准的固件签名流程其实不复杂。我画了张图，你看一眼就明白了：
流程其实就五步：
- 计算哈希——对原始固件做 SHA-256 或 SHA-384，得到一个固定长度的摘要。
- 私钥签名——用厂商的私钥对这个哈希值做签名运算，生成签名值。
- 打包分发——把原始固件和签名值打包在一起，通过 OTA 或烧录工具下发。
- 接收端验签——设备收到后，先用同样的哈希算法计算固件摘要。
- 公钥比对——用预置的公钥解密签名，比对两个哈希值是否一致。
我的经验：签名流程里最容易出问题的是哈希算法选择。SHA-1 已经不安全了，别用。SHA-256 是目前的主流，SHA-384 用于更高安全等级的场景。我曾经在一个项目里发现客户还在用 MD5 做签名哈希——当场就让他们改了。
嗯，到这里你应该对固件签名有了基本认识。记住三个关键词：完整性、认证、抗抵赖。后面几章我们会深入具体的签名工具和实操对比，到时候手把手带你走一遍。