1. 签名流程概述：什么是代码签名、为什么需要签名、签名在安全升级中的角色
好，咱们直接进入正题。代码签名这东西，说白了就是给软件打个「数字封印」。你想想看，一个可执行文件从开发者手里传到用户设备上，中间要经过多少环节？CDN、下载服务器、本地存储……任何一个环节被篡改，用户拿到的可能就不是你写的那个程序了。
我刚开始做嵌入式安全那会儿，就吃过这个亏。有一次固件升级包没做签名校验，结果用户设备刷了个第三方修改版，直接变砖。嗯，从那以后，我对签名这件事就再也不敢马虎了。
1.1 什么是代码签名
代码签名，就是用私钥对代码的哈希值进行加密，生成一个数字签名。用户端用对应的公钥验证这个签名，就能确认两件事：
- 代码来源可信 —— 确实是某个特定开发者发布的
- 代码未被篡改 —— 从签名到安装，中间没人动过手脚
流程其实不复杂：
- 开发者计算代码文件的哈希值（比如 SHA-256）
- 用私钥加密这个哈希值，生成签名
- 把签名和代码一起打包分发
- 用户端用公钥解密签名，得到原始哈希值
- 重新计算代码哈希，对比两者是否一致
核心要点：签名不是加密代码本身，而是加密代码的「指纹」。代码本身可以公开，但指纹必须由私钥保护。
1.2 为什么需要签名
你可能觉得：「我直接走 HTTPS 下载不就行了？」嗯，HTTPS 确实能保证传输过程中的安全，但它解决不了两个问题：
| 威胁场景 | HTTPS 能否防御 | 签名能否防御 |
|---|---|---|
| 传输中被篡改 | ✅ 能 | ✅ 能 |
| 服务器被攻破，替换了下载文件 | ❌ 不能 | ✅ 能 |
| 本地存储被恶意软件篡改 | ❌ 不能 | ✅ 能 |
| 中间人伪造更新包 | ❌ 不能（如果证书被伪造） | ✅ 能 |
说白了，HTTPS 保护的是「路」，签名保护的是「货」。路再安全，货本身被调包了你也发现不了。
我曾经踩过的坑：有个项目只依赖 HTTPS 做升级，结果 CDN 被入侵，攻击者替换了固件包。因为 HTTPS 证书是合法的，客户端照单全收。后来加了签名校验，同样的攻击场景下，签名验证直接失败，升级流程被阻断。这就是签名存在的意义。
1.3 签名在安全升级中的角色
在安全升级流程里，签名不是可选项，而是基石。我习惯把整个升级安全体系比作一把锁，签名就是锁芯。没有锁芯，其他防护措施都是摆设。
具体来说，签名承担了三个关键角色：
- 身份认证 —— 确认升级包来自合法的发布方，不是第三方伪造的
- 完整性校验 —— 确保升级包从签名到安装，内容没有被修改过
- 不可抵赖性 —— 开发者不能否认自己发布了某个升级包（法律层面也有意义）
你想想看，一个典型的 OTA 升级流程：设备启动 → 下载升级包 → 验证签名 → 校验完整性 → 解压安装。签名验证是第二步，也是最关键的一步。如果签名不对，后面的步骤根本不用执行。
个人建议：签名验证一定要放在解压和安装之前。我见过有些方案先解压再验签，这等于把大门敞开了再检查有没有小偷进来——逻辑上就错了。
1.4 签名流程的核心逻辑
下面这张图，是我每次给团队做培训时必画的。它把整个签名流程的核心逻辑串起来了：
这张图左边是签名阶段，右边是验证阶段。注意看，私钥只在签名阶段出现，公钥则在验证阶段使用。这两个密钥从不交叉，这是整个体系的安全基础。
1.5 常见的误区
做签名这么多年，我见过不少团队犯同样的错误。这里列几个典型的：
- 把签名当加密用 —— 签名不保护代码内容不被看到，只保护内容不被篡改
- 私钥管理不当 —— 私钥泄露等于签名体系崩塌。我曾经见过有人把私钥放在 Git 仓库里……嗯，后果很严重
- 公钥硬编码但不可更新 —— 公钥一旦泄露，整个设备群都无法安全升级。一定要设计公钥更新机制
- 只验签不验证书链 —— 签名本身合法不代表证书没有被吊销。完整的验证应该包含证书链校验和吊销列表检查
避坑指南：我曾经接手过一个项目，他们的签名验证只检查了签名格式是否正确，根本没验证签名内容。攻击者随便伪造一个签名文件就能通过。所以记住：验证签名不是「有没有签名」，而是「签名对不对」。
1.6 小结
代码签名是安全升级的第一道防线，也是最重要的一道。它用密码学手段解决了「谁发布的」和「被改过没」这两个核心问题。后面的章节，我会带你一步步拆解签名的具体实现——从密钥生成、签名算法选择，到验证流程的工程落地。
嗯，先把基础打牢，后面的事就好办了。