3、签名与验证机制：非对称加密基础(RSA/ECC)、哈希算法(SHA256)、数字签名生成与验证流程
各位同学，咱们今天聊点硬核的——签名与验证。说实话，这是整个安全启动体系的「灵魂」所在。你前面做的加密、哈希，最终都要落到签名验证这一步。我当年第一次接触这个，觉得不就是签个名嘛，后来踩了坑才知道，这里面的门道深着呢。
3.1 非对称加密：为什么需要两把钥匙？
先说说非对称加密。你想想看，对称加密就像一把钥匙开一把锁，加密解密都用同一个密钥。那问题来了——你怎么把密钥安全地传给对方？我早期做项目时，就因为这个密钥分发问题头疼了好久。
非对称加密就不一样了。它有两把钥匙：一把叫公钥，可以公开；一把叫私钥，必须保密。公钥加密的数据，只有私钥能解开；反过来，私钥签名的数据，公钥能验证。
目前主流的有两种算法：RSA 和 ECC。
| 特性 | RSA | ECC（椭圆曲线） |
|---|---|---|
| 密钥长度 | 2048位起步 | 256位就够用 |
| 计算速度 | 签名慢，验证快 | 签名快，验证稍慢 |
| 资源消耗 | 较大 | 较小 |
| 典型应用 | 传统固件签名 | IoT设备、嵌入式 |
我个人习惯在资源受限的嵌入式设备上用 ECC。为什么？256位的ECC，安全强度相当于3072位的RSA，但计算量小得多。我做过一个项目，MCU主频才100MHz，跑RSA 2048签名验证要好几秒，换成ECC P-256后，200毫秒就搞定了。
核心要点：非对称加密的核心价值在于「私钥不传递」。你只需要把公钥烧录到设备里，私钥留在服务器端。这样即使设备被破解，攻击者也拿不到私钥，无法伪造合法固件。
3.2 哈希算法：数据的「指纹」
哈希算法，说白了就是给数据算一个「指纹」。不管你的固件是1KB还是100MB，经过SHA256计算后，都会得到一个256位的固定长度摘要。
这里有几个关键特性：
- 单向性：从摘要反推原始数据，理论上不可能。嗯，至少目前是这样。
- 抗碰撞性：很难找到两个不同的数据，算出相同的哈希值。
- 雪崩效应：改一个比特，哈希值就面目全非。
我在项目中遇到过一个问题：有个同事用MD5做固件校验，结果被攻击者伪造了固件。从那以后，我坚持用SHA256。虽然计算量大了点，但安全等级完全不一样。
避坑指南：我曾经见过有人直接对固件做SHA256，然后签名这个哈希值。这种做法没问题，但要注意——哈希计算必须在设备端重新做一遍，不能直接信任固件里自带的哈希值。否则攻击者改了固件，顺手把哈希值也改了，你就傻眼了。
3.3 数字签名：到底是怎么签的？
好了，前面铺垫了这么多，现在说正题——数字签名。流程其实不复杂，我画个图给你看：
签名过程（服务器端）：
1. 计算固件的SHA256哈希值
2. 用私钥对哈希值进行加密（这就是签名）
3. 将签名附加到固件尾部
验证过程（设备端）：
1. 提取固件中的签名数据
2. 用公钥解密签名，得到哈希值A
3. 重新计算固件的SHA256哈希值B
4. 比较A和B，一致则通过你可能会问：为什么不直接签名整个固件？原因很简单——效率。固件可能几十MB，非对称加密处理大文件非常慢。先哈希再签名，相当于只给「指纹」签名，效率高得多。
注意：验证时一定要做「全量验证」。我见过一个案例，设备只验证了固件的前512字节，结果攻击者把恶意代码藏在后面，绕过了验证。嗯，这种低级错误，咱们可不能犯。
3.4 实战中的签名验证流程
在实际的音响系统里，签名验证通常分三个阶段：
- BootROM阶段：验证第一级Bootloader的签名。这是信任链的根，公钥直接固化在芯片内部。
- Bootloader阶段：验证操作系统内核的签名。公钥由上一级传递下来。
- 系统启动后：验证应用程序和固件更新的签名。公钥通常存储在安全区域。
我做过一个项目，客户要求从BootROM到应用层，一共五级验证。每一级只信任上一级传递的公钥，形成一条完整的信任链。说白了，只要第一级没被攻破，整个系统就是安全的。
关键点：信任链的根（Root of Trust）必须不可篡改。通常的做法是把公钥烧录到芯片的一次性可编程（OTP）区域，或者使用硬件安全模块（HSM）来存储。
3.5 常见攻击与防御
搞安全的，不能光知道怎么做，还得知道怎么被攻破。我总结了几种常见攻击手法：
| 攻击类型 | 攻击方式 | 防御措施 |
|---|---|---|
| 重放攻击 | 用旧版本的合法固件替换新固件 | 固件中包含版本号，验证时检查版本递增 |
| 侧信道攻击 | 通过功耗、电磁辐射分析私钥 | 使用恒定时间算法，加入随机延时 |
| 回滚攻击 | 降级到有漏洞的旧版本 | 硬件防回滚计数器（eFuse） |
我曾经遇到过一个很有意思的攻击案例：攻击者没有破解签名，而是直接绕过验证流程。他们把Bootloader里调用验证函数的指令给跳过了。所以，我建议你在代码里加入「验证失败必须死循环」的逻辑，别给攻击者留任何后路。
个人经验：签名验证的代码一定要用汇编或者C语言写，别用高级语言。为什么？因为编译器优化可能会把关键的验证步骤给优化掉。我吃过这个亏，后来学乖了，关键代码全部手写汇编，确保每个指令都在预期位置执行。
好了，这一章的内容就到这儿。签名验证是安全启动的基石，理解透了，后面的内容就水到渠成了。下一章咱们聊聊具体的固件升级协议设计，到时候会用到今天讲的所有知识。