1. 固件签名基础：什么是固件签名、为什么需要签名、签名与哈希的区别
各位同学，咱们今天聊固件签名。说实话，这玩意儿在嵌入式安全里属于「入门级但极其重要」的知识点。我见过太多团队，产品功能做得花里胡哨，结果签名这关一塌糊涂——要么没做，要么做错了。好，咱们从头捋一遍。
1.1 什么是固件签名
固件签名，说白了就是给固件打个「数字指纹 + 防伪标签」。你想想看，一个嵌入式设备要升级固件，它怎么知道下载下来的.bin文件是官方发布的、没被人动过手脚？
签名就是干这个的。流程大致是这样：
- 开发者用私钥对固件哈希值加密，生成签名
- 签名和固件一起发布
- 设备端用公钥解密签名，比对哈希值
我在项目中遇到过一家做IoT网关的客户，他们早期没做签名校验，结果被黑客塞了个恶意固件进去，整批设备变成了肉鸡。嗯，从那以后他们再也不敢省这步了。
核心要点：固件签名 = 私钥签名 + 公钥验签。私钥必须绝对保密，公钥可以公开。
1.2 为什么需要签名
你可能会问：我做个校验和（checksum）不行吗？为什么非要搞签名这么复杂？
原因其实很简单——校验和只能防意外损坏，防不了恶意篡改。攻击者改了固件内容，顺手把校验和也改了，设备根本发现不了。
签名的价值在于：
- 完整性验证：确保固件没被篡改
- 来源认证：确认固件来自可信的发布者
- 抗抵赖性：发布者无法否认自己签过这个固件
- 安全升级：防止恶意固件被刷入设备
我记得有一次帮客户做安全审计，发现他们的设备只做了CRC32校验。我说这不行，攻击者改固件就跟改自己家冰箱一样简单。客户还不信，我当场演示了一下——用十六进制编辑器改了固件里一个字节，重新算CRC，刷进去，设备照跑不误。客户脸都绿了。
避坑指南：我曾经见过一个团队，签名算法用了MD5 + RSA-512。MD5已经被破解，RSA-512在今天的算力下也能被暴力破解。别省那点计算资源，至少用SHA-256 + RSA-2048或ECDSA。
1.3 签名与哈希的区别
很多新手容易把哈希和签名搞混。我习惯用一个比喻来解释：
- 哈希 = 给固件算个「身份证号」。任何人用同样的算法都能算，但算出来都一样。
- 签名 = 给固件盖个「公章」。只有持有私钥的人能盖，但谁都能拿公钥验证。
咱们用表格对比一下：
| 特性 | 哈希 | 签名 |
|---|---|---|
| 是否需要密钥 | 不需要 | 需要（私钥签名，公钥验签） |
| 能否防篡改 | 不能（攻击者可重新计算） | 能（攻击者没有私钥） |
| 能否验证来源 | 不能 | 能 |
| 计算开销 | 低 | 较高 |
| 典型算法 | SHA-256, SHA-384 | RSA, ECDSA, Ed25519 |
实际项目中，签名和哈希是配合使用的。签名不是对整个固件做加密——那样太慢了。正确的做法是：
// 伪代码示例：固件签名流程
1. 计算固件哈希值
hash = SHA256(firmware.bin)
2. 用私钥对哈希值签名
signature = RSA_Sign(private_key, hash)
3. 发布固件 + 签名
publish(firmware.bin, signature)
// 设备端验签流程
1. 计算固件哈希值
hash = SHA256(firmware.bin)
2. 用公钥解密签名，得到原始哈希
original_hash = RSA_Verify(public_key, signature)
3. 比对两个哈希值
if hash == original_hash:
firmware is authentic
else:
reject firmware
你看，签名本质上是对哈希值做了一层「加密保护」。哈希负责压缩数据，签名负责保证这个压缩结果没被篡改。
个人经验：我建议在固件头里同时存放哈希值和签名值。这样设备可以先快速校验哈希（用于检测传输错误），再校验签名（用于安全验证）。两层校验，性能和安全兼顾。
1.4 知识体系总览
为了让你对整个固件签名体系有个全局认识，我画了张图：
这张图把固件签名的三个核心维度串起来了。你仔细看，左边是「是什么」，中间是「为什么」，右边是「和哈希的区别」。这三块搞明白了，固件签名的基础就算打牢了。