固件加密基础：对称加密与非对称加密、哈希函数与消息认证码、数字签名原理
各位好，欢迎来到第二章。这一章我们聊聊固件加密的四大基石——对称加密、非对称加密、哈希函数、数字签名。说实话，很多做嵌入式开发的工程师，对这几个概念的理解停留在「知道名字」的层面。但真正做固件保护时，选错一个算法，整个安全体系就可能形同虚设。
我在项目中见过太多次这样的场景：工程师觉得「反正加了密」，结果用的是已经过时的 DES，或者把密钥硬编码在代码里。嗯，这些坑我们一个一个来填。
2.1 对称加密：又快又简单，但密钥怎么传？
对称加密，说白了就是加密和解密用同一把钥匙。你想想看，就像你家里的大门，用一把钥匙锁上，也用同一把钥匙打开。
常见的对称加密算法有：
| 算法 | 密钥长度 | 分组大小 | 安全性评价 |
|---|---|---|---|
| AES | 128/192/256 bit | 128 bit | 目前最推荐，硬件加速普遍 |
| DES | 56 bit | 64 bit | 已废弃，暴力破解只需几天 |
| 3DES | 112/168 bit | 64 bit | 性能差，不推荐新项目使用 |
| SM4 | 128 bit | 128 bit | 国标，国内项目必须考虑 |
我个人习惯在固件加密场景中优先选 AES-256-GCM。为什么？因为 GCM 模式自带认证标签，能同时检测数据是否被篡改。我曾经在一个 IoT 项目里，团队用了 AES-ECB 模式加密固件升级包，结果攻击者通过重放攻击直接刷入了旧版本固件——ECB 模式不抗重放，这是个血的教训。
核心要点：对称加密速度快，适合大批量数据加密。但密钥分发是最大痛点——发送方和接收方怎么安全地共享同一把密钥？在固件场景中，密钥通常预置在芯片的 OTP 或安全元件中，但这就引出了下一个问题：密钥本身怎么保护？
2.2 非对称加密：密钥分发的救星
非对称加密解决了对称加密的密钥分发难题。它用一对密钥：公钥公开，私钥保密。你用公钥加密，只有持有私钥的人能解密。
常见的非对称算法：
- RSA：最经典，2048 bit 以上才安全。但计算量大，不适合资源受限的 MCU。
- ECC（椭圆曲线）：同等安全强度下，密钥更短，计算更快。比如 256 bit 的 ECC 相当于 3072 bit 的 RSA。
- SM2：国标椭圆曲线算法，国内项目必备。
你可能会问：「那为什么不全用非对称加密？」原因很简单——慢。非对称加密比对称加密慢几百到几千倍。所以实际项目中，我们通常用非对称加密来传输对称密钥，然后用对称加密来加密实际数据。这叫「混合加密」。
实战建议：在固件签名验证场景中，公钥通常烧录在芯片的 eFuse 或一次性可编程存储器中。私钥则保存在安全的 HSM（硬件安全模块）或离线服务器上。我曾经见过一个团队把私钥放在 Git 仓库里——嗯，那基本等于把家门钥匙贴在门上。
2.3 哈希函数：数据的「指纹」
哈希函数能把任意长度的数据，压缩成固定长度的摘要。而且它有个重要特性：不可逆。你无法从摘要反推出原始数据。
常见的哈希算法：
| 算法 | 摘要长度 | 安全性 |
|---|---|---|
| MD5 | 128 bit | 已破解，不要用 |
| SHA-1 | 160 bit | 已发现碰撞攻击，逐步淘汰 |
| SHA-256 | 256 bit | 目前安全，推荐使用 |
| SM3 | 256 bit | 国标，国内项目推荐 |
哈希函数在固件保护中有两个典型用途：
- 完整性校验：计算固件的哈希值，与官方发布的哈希值对比，看固件是否被篡改。
- 密码存储：存储密码的哈希值，而不是明文。即使数据库泄露，攻击者也拿不到原始密码。
注意：单纯的哈希函数无法防止「中间人攻击」。攻击者可以同时篡改固件和哈希值。所以我们需要消息认证码（MAC）或数字签名来提供「认证」能力。
2.4 消息认证码（MAC）：给数据加个「防伪标签」
消息认证码（MAC）结合了哈希函数和对称密钥。只有持有相同密钥的双方，才能验证消息的完整性。
常见的 MAC 算法：
- HMAC：基于哈希的 MAC，如 HMAC-SHA256。最常用，标准成熟。
- CMAC：基于分组密码的 MAC，如 AES-CMAC。
- GMAC：GCM 模式中的认证标签部分。
MAC 的工作流程：
发送方：
1. 计算 MAC = HMAC-SHA256(密钥, 消息)
2. 发送 (消息 || MAC)
接收方：
1. 用相同密钥计算 MAC' = HMAC-SHA256(密钥, 消息)
2. 比较 MAC' 与收到的 MAC
3. 如果一致，消息未被篡改且来源可信我在一个车联网项目中用过 HMAC 来保护 OTA 升级包的完整性。当时有个细节差点翻车——密钥的更新机制。如果密钥长期不变，攻击者可以通过分析多个升级包来破解密钥。所以我们设计了一套密钥轮换策略，每次升级都使用派生密钥。
2.5 数字签名：非对称版的「防伪标签」
数字签名解决了 MAC 的一个根本问题：MAC 需要双方共享密钥，而数字签名只需要公钥公开。私钥签名，公钥验签。
数字签名流程：
签名方（私钥）：
1. 计算消息的哈希值 H = SHA256(消息)
2. 用私钥加密 H，得到签名 S
3. 发送 (消息 || S)
验证方（公钥）：
1. 计算消息的哈希值 H' = SHA256(消息)
2. 用公钥解密签名 S，得到 H
3. 比较 H' 与 H
4. 如果一致，消息未被篡改且来源可信常见的数字签名算法：
- RSA-PSS：RSA 的概率签名方案，比传统 PKCS#1 v1.5 更安全。
- ECDSA：基于椭圆曲线的签名算法，密钥短，适合嵌入式。
- Ed25519：基于 Edwards 曲线的签名算法，性能极佳，抗侧信道攻击。
- SM2：国标签名算法。
关键区别：MAC 提供「对称认证」，数字签名提供「非对称认证」。在固件签名场景中，我们通常用数字签名——因为公钥可以公开存储在芯片中，私钥由厂商严格保管。这样即使攻击者拿到了芯片，也无法伪造签名。
2.6 知识体系总览
下面这张图总结了本章的核心逻辑。我建议你把它保存下来，以后做方案设计时对照着看。
2.7 避坑指南：我踩过的那些坑
做了这么多年固件安全，我总结了几条血泪教训：
- 别自己造轮子：我曾经见过一个团队自己实现了一个「加密算法」，结果三天就被破解了。用标准库，用经过验证的实现。
- 密钥管理比算法更重要：算法再强，密钥泄露就全完了。密钥要存储在安全硬件中，比如 TPM、Secure Element 或芯片的 OTP 区域。
- 注意侧信道攻击：在嵌入式设备上，攻击者可以通过功耗分析、电磁辐射等方式窃取密钥。使用恒定时间比较、随机延时等防护措施。
- 更新机制要留后路：如果算法被攻破，你的设备能远程更新密钥和算法吗？我在一个项目中没考虑这点，结果产品上市两年后 SHA-1 被攻破，所有设备都得召回。