密码学基础：对称加密与非对称加密、哈希函数与数字签名、公钥基础设施(PKI)概念
各位同学，欢迎来到第二章。这一章咱们要啃的，是OTA安全升级的“地基”——密码学基础。
说实话，我见过不少工程师，上来就撸代码，把签名验证、加密传输写得飞起。结果呢？密钥硬编码在固件里，哈希算法用了过时的MD5，签名验证逻辑有漏洞。嗯，这些坑我年轻时都踩过。所以这一章，咱们把底层的概念彻底捋清楚。
你想想看，OTA升级说白了就是“把新固件从云端安全地送到设备里”。这中间要解决三个核心问题：
- 机密性：固件内容不能被别人偷看。
- 完整性：固件在传输中不能被篡改。
- 身份认证：确保固件确实来自合法的厂商，而不是黑客。
这三个问题，正好对应我们今天要讲的三大块：对称/非对称加密、哈希函数与数字签名、以及PKI。
核心观点：没有密码学，OTA安全就是空中楼阁。这一章的内容，会贯穿整个课程的所有实战环节。
对称加密与非对称加密：一把钥匙 vs 两把钥匙
先聊加密。加密的目的很简单——让数据变得“不可读”。但用什么方式加密，差别很大。
对称加密：快，但钥匙怎么给？
对称加密，说白了就是“一把钥匙开一把锁”。加密和解密用的是同一个密钥。
- 优点：速度快，适合加密大量数据。比如固件包本身，通常用对称加密。
- 缺点：密钥分发是个大难题。你想想，如果我要给一万台设备发固件，我怎么安全地把这把“钥匙”交给每一台设备？
常见的对称加密算法有：
| 算法 | 密钥长度 | 我的评价 |
|---|---|---|
| AES | 128/192/256位 | 目前最主流，硬件加速支持好，推荐使用AES-128或AES-256 |
| ChaCha20 | 256位 | 软件实现效率高，适合没有AES硬件加速的MCU |
| DES/3DES | 56/112位 | 过时了，别用。我在一个老旧项目里见过，直接建议客户换掉。 |
我的习惯：在资源受限的IoT设备上，我优先用AES-128-GCM模式。它不仅能加密，还能提供完整性校验，一举两得。
非对称加密：慢，但钥匙好管
非对称加密，用的是“一对钥匙”：公钥和私钥。公钥可以公开，私钥必须保密。
- 公钥加密，私钥解密：任何人都可以用你的公钥加密一段消息，但只有你能用私钥解密。这解决了密钥分发问题。
- 私钥签名，公钥验签：你用私钥给数据“盖章”，别人用你的公钥来验证这个章是真的。这就是数字签名的核心。
非对称加密的缺点是慢。所以实际中，我们不会用它加密整个固件，而是用它来加密“对称密钥”，或者做数字签名。
常见算法：
| 算法 | 典型密钥长度 | 适用场景 |
|---|---|---|
| RSA | 2048/4096位 | 签名、密钥交换。老牌算法，兼容性好。 |
| ECC (椭圆曲线) | 256位 (相当于RSA 3072位) | 签名、密钥交换。密钥短，性能好，非常适合IoT设备。 |
| Ed25519 | 256位 | 现代签名算法，速度快，安全性高，我最近的项目都在用。 |
避坑指南：我曾经在一个项目里看到有人用RSA-1024，觉得够用了。但现在的算力，1024位已经不再安全。我的建议是，新项目至少用RSA-2048或ECC-256。别给未来留隐患。
哈希函数与数字签名：防篡改的“指纹”
加密解决了“偷看”的问题，但怎么保证固件没被改过？这就需要哈希函数了。
哈希函数：数据的“数字指纹”
哈希函数，能把任意长度的数据，映射成一个固定长度的“摘要”。这个摘要就像指纹一样，只要原始数据变了哪怕一个比特，摘要就会完全不一样。
- 特性：不可逆（不能从摘要反推出原文）、抗碰撞（很难找到两个不同数据有相同摘要）。
- 用途：验证数据完整性。你下载完固件后，算一下它的哈希值，跟官方公布的对比一下，就知道有没有被篡改。
常见哈希算法：
| 算法 | 摘要长度 | 安全性 |
|---|---|---|
| MD5 | 128位 | 已破解，绝对不要用 |
| SHA-1 | 160位 | 已破解，不要用 |
| SHA-256 | 256位 | 目前安全，推荐使用 |
| SHA-3 | 可变 | 新一代标准，未来趋势 |
我的经验：在OTA升级中，我们通常先对固件包做SHA-256哈希，得到一个摘要。然后对这个摘要做数字签名。设备端收到固件后，先验签，再算哈希对比。这样既验证了身份，又保证了完整性。
数字签名：给固件“盖个章”
数字签名，是哈希函数和非对称加密的完美结合。流程是这样的：
- 签名方（厂商）：对固件包做哈希，然后用私钥加密这个哈希，得到“签名”。把固件包和签名一起发出去。
- 验证方（设备）：收到固件和签名后，用公钥解密签名，得到原始的哈希值。然后自己再算一遍固件的哈希。两个哈希一对比，一样就说明固件是厂商签发的，且没被改过。
这就是OTA防篡改的核心机制。你想想看，黑客就算截获了固件，改了内容，但他没有私钥，无法生成新的有效签名。设备验签时就会失败，拒绝升级。
公钥基础设施(PKI)：谁来证明这把公钥是真的？
到这里，你可能有个疑问：设备上存储的公钥，怎么保证它真的是厂商的公钥？万一被换掉了呢？
这就是PKI要解决的问题。PKI是一套完整的体系，用来管理公钥的生成、分发、使用和撤销。
核心角色有三个：
- CA (证书颁发机构)：权威的第三方，负责签发数字证书。它用自己的私钥，给厂商的公钥“背书”。
- 数字证书：包含厂商的公钥、身份信息、有效期，以及CA的签名。说白了，就是一张“公钥身份证”。
- 设备：设备上预置了CA的根证书（也就是CA自己的公钥）。当收到厂商的证书时，设备用CA的公钥验证证书上的签名，确认这个证书是真的，然后从中取出厂商的公钥。
这样，就形成了一个信任链：设备信任CA，CA信任厂商，所以设备信任厂商。
关键点：在OTA场景中，我们通常不会部署完整的PKI（太复杂了）。更常见的做法是，在设备出厂时，直接烧录厂商的公钥或自签名的根证书。这叫“预置信任锚点”。简单、高效，但需要保护好这个信任锚点不被篡改。
下面这张图，展示了OTA升级中，密码学组件是如何协同工作的：
总结一下
这一章的内容，是OTA安全的“内功”。你不需要记住所有算法的细节，但必须理解它们各自解决什么问题：
- 对称加密：加密数据，快。密钥分发是难题。
- 非对称加密：解决密钥分发，做数字签名。慢。
- 哈希函数：生成数据指纹，验证完整性。
- 数字签名：哈希 + 非对称加密，防篡改 + 身份认证。
- PKI：管理公钥的信任体系。在IoT中常简化为“预置信任锚点”。