一、固件签名概述
什么是固件签名
固件签名，说白了就是给固件打个「数字指纹」。
我习惯这么跟新人解释：你写了一份代码，编译成二进制文件。这个文件在传输或烧录过程中，会不会被人篡改？会不会被人掉包？固件签名就是解决这个问题的。
具体做法是——用私钥对固件做哈希运算，生成一个签名值。这个签名值会附在固件后面，或者单独存放。设备端拿到固件后，用对应的公钥验证签名。验证通过，说明固件是可信的、完整的。
核心要点：固件签名 = 哈希 + 非对称加密。哈希保证完整性，非对称加密保证真实性。
我在项目中遇到过一件事：有个客户反馈设备升级后频繁死机。排查了半天，发现是升级包被人中间人攻击替换了。从那以后，我所有项目都强制要求固件签名。
为什么需要固件签名
你想想看，嵌入式设备现在到处都是。智能门锁、医疗设备、汽车ECU、工业控制器……这些设备如果跑着被篡改过的固件，后果是什么？
- 安全风险：攻击者植入后门，窃取数据或控制设备
- 功能异常：固件被破坏，设备无法正常工作
- 知识产权泄露：固件被逆向，核心算法被盗用
- 合规问题：很多行业标准（如IEC 62443、ISO 21434）明确要求固件签名
嗯，这里要注意——固件签名不是可选项，而是必需品。尤其现在物联网设备那么多，没有签名的固件就像没锁的门。
避坑提醒：我曾经见过一个团队，为了赶工期跳过了固件签名。结果产品上市后，被黑客利用固件漏洞远程控制了整批设备。最后召回损失超过200万。签名这一步，省不得。
签名与加密的区别
很多初学者会把签名和加密搞混。我刚开始做嵌入式时也犯过这个错。
| 对比项 | 固件签名 | 固件加密 |
|---|---|---|
| 目的 | 验证身份和完整性 | 保护内容不被泄露 |
| 使用密钥 | 私钥签名，公钥验证 | 公钥加密，私钥解密 |
| 输出结果 | 签名值（可公开） | 密文（不可公开） |
| 能否防篡改 | 能 | 不能（加密≠防篡改） |
| 典型场景 | 固件升级、启动验证 | 固件传输、存储保护 |
简单总结：签名解决的是「谁写的、改没改」的问题，加密解决的是「别人能不能看」的问题。两者可以结合使用，但不要混为一谈。
我的建议：实际项目中，我通常先签名再加密。这样既保证固件来源可信，又防止传输过程中被窃取。当然，如果设备性能有限，至少也要做签名。
固件签名的应用场景
固件签名不是理论概念，它在实际开发中随处可见。我列几个最常见的场景：
- 安全启动（Secure Boot）
设备上电后，Bootloader验证固件签名。签名不对，直接拒绝启动。这是最基础的安全防线。 - OTA升级
云端下发升级包时，附带签名值。设备下载后先验签，通过才执行升级。防止升级包被篡改。 - 外设固件更新
比如Wi-Fi模块、蓝牙芯片的固件。通过主控MCU验证签名后，再烧录到外设。 - 工厂烧录
生产线上批量烧录固件时，签名可以防止烧录了错误或未授权的固件版本。 - 第三方固件管理
如果你的设备支持用户自定义固件（比如路由器刷机），签名可以限制只有经过认证的固件才能运行。
为什么会这样？因为这些场景都有一个共同点——固件从「生产方」到「设备端」的路径上，存在被篡改的风险。签名就是给这条路径加一把锁。
一句话总结：只要固件会离开你的控制范围（传输、存储、分发），就需要签名。
知识体系结构图
下面这张图展示了固件签名在整个嵌入式安全体系中的位置：
这张图把固件签名的核心脉络梳理清楚了。从上到下，先理解「是什么」，再深入「为什么需要」和「怎么用」。后面的章节我们会逐一展开每个细节。
个人经验：我建议初学者先把这张图记在脑子里。遇到具体问题时，往这个框架里套，思路会清晰很多。我自己带团队时，也是用这张图做培训的。
好了，第一章就到这里。固件签名这个概念，说白了就是给固件一个「身份证」。后面我们会聊具体的签名算法、密钥管理、烧录流程……嗯，一步步来。