固件加密基础：对称加密与非对称加密、哈希函数与消息认证码、密钥管理基础

加密这件事，说白了就是给固件穿上一件防弹衣。我在嵌入式安全这行干了十几年，见过太多因为加密没做好导致产品被抄、被篡改的案例。今天咱们就把这块地基打牢。

对称加密，就是加密和解密用同一把钥匙。你想想看，就像你家大门，进门出门都用同一把钥匙。常见的算法有 AES、DES、SM4。

我个人习惯在固件加密场景里首选 AES-128 或 AES-256。为什么？因为硬件加速器几乎都支持它，跑起来快，功耗也低。

注意：对称加密的密钥分发是个大坑。我曾经在一个 IoT 项目里，直接把 AES 密钥硬编码在固件里，结果产品上市第三天就被破解了。密钥一旦泄露，加密形同虚设。

非对称加密用一对钥匙：公钥公开，私钥保密。公钥加密的数据只能用私钥解密，反过来私钥签名可以用公钥验证。常用的有 RSA、ECC、SM2。

在固件启动校验里，我通常用非对称加密来做签名验证。比如，固件发布前用私钥签名，设备启动时用公钥验签。这样即使固件被替换，签名对不上，系统直接拒绝启动。

核心区别：

你可能会问，那能不能只用非对称加密？嗯，理论上可以，但实际中没人这么干。因为非对称加密太慢了，加密一个 1MB 的固件可能要好几秒。所以实际做法是：用非对称加密保护对称密钥，再用对称密钥加密固件。这叫混合加密。

哈希函数能把任意长度的数据，压缩成固定长度的摘要。常见的算法有 SHA-256、SHA-3、SM3。

哈希函数有个特点：不可逆。你没法从摘要反推出原始数据。而且，哪怕只改一个 bit，摘要都会完全不一样。

我在项目中常用哈希函数做完整性校验。比如，固件烧录前计算一次哈希值，烧录后再算一次，对比一下就知道固件有没有被篡改。

避坑指南：我曾经遇到过哈希碰撞攻击的案例。攻击者构造了两个不同的固件，但哈希值相同。所以现在我都推荐用 SHA-256 或更高强度的算法，别再碰 MD5 和 SHA-1 了。

哈希函数只能保证完整性，但没法验证消息来源。消息认证码（MAC）就是来解决这个问题的。它需要一个共享密钥，只有持有密钥的双方才能生成和验证 MAC。

常见的 MAC 算法有 HMAC-SHA256、CMAC。

举个例子：设备收到 OTA 固件包后，用预置的密钥计算 MAC，和固件包里带的 MAC 对比。如果一致，说明固件既没被篡改，也确实来自合法的服务器。

注意：MAC 和数字签名不一样。MAC 用的是对称密钥，数字签名用的是非对称密钥。MAC 适合点对点通信，数字签名适合一对多的分发场景。

加密算法再强，密钥管理一塌糊涂，整个系统就是纸糊的。我见过太多项目，密钥直接明文存 Flash，或者用固定密钥加密密钥——这跟没加密一样。

密钥管理有几个基本原则：

我的经验：在量产时，每个设备都要有唯一的设备密钥。千万别所有设备用同一个密钥，否则一台被破解，全线崩溃。

下面这张图把本章的核心逻辑串起来了。你可以看到，对称加密、非对称加密、哈希函数、MAC 各自负责什么，以及它们如何协同工作。

说了这么多，到底怎么选？我根据项目经验整理了一个对照表：

个人建议：别自己造轮子。用成熟的加密库，比如 mbedTLS、OpenSSL、WolfSSL。这些库经过大量安全审计，比自己手写的靠谱得多。

好了，这一章的内容就到这里。加密基础打牢了，后面讲启动校验和固件保护时，你就能理解为什么每一步都要这么设计了。