4、数字签名与哈希校验：ECDSA签名算法、SHA-384哈希、公钥基础设施（PKI）部署
好，我们接着聊固件防护的核心环节。前面讲了启动链的信任根，那怎么证明固件没被篡改？怎么证明它确实来自我们？这就得靠数字签名和哈希校验了。
我个人习惯把这一套组合拳叫做「三件套」：ECDSA签名算法负责身份认证，SHA-384哈希负责完整性校验，公钥基础设施（PKI）负责密钥管理。缺一个，整个安全体系就漏风。
4.1 为什么是ECDSA？不是RSA？
你可能会问，RSA不是用得挺好吗？嗯，这里要注意：导弹制导系统的芯片资源极其有限。RSA的密钥长度动辄2048位、4096位，签名验证的计算量也大。ECDSA（椭圆曲线数字签名算法）在同等安全强度下，密钥长度短得多。
举个例子：
| 安全等级 | RSA密钥长度 | ECDSA密钥长度 |
|---|---|---|
| 128位 | 3072位 | 256位 |
| 192位 | 7680位 | 384位 |
| 256位 | 15360位 | 521位 |
看到没？ECDSA的密钥长度只有RSA的十分之一左右。我在项目中遇到过，某型飞控芯片的Flash空间就剩那么几KB，用RSA根本塞不下公钥。换成ECDSA后，问题迎刃而解。
4.2 SHA-384：不多不少，刚刚好
哈希算法选型也是个讲究活。SHA-1已经被攻破，SHA-256虽然够用，但考虑到抗量子计算的远期需求，我个人更倾向于SHA-384。
为什么不是SHA-512？说白了，SHA-512在32位嵌入式处理器上跑起来太慢。SHA-384是SHA-512的截断版本，安全强度一样，但计算效率更高。你想想看，导弹在飞行过程中，Bootloader每毫秒都很宝贵，不能把时间都耗在哈希计算上。
SHA-384的输出是384位（48字节），刚好可以跟ECDSA的384位曲线配合使用。这叫「门当户对」。
核心原则：哈希算法和签名算法的安全等级必须匹配。用SHA-256配ECDSA-384，或者用SHA-384配ECDSA-256，都是不合理的。前者浪费了签名算法的强度，后者浪费了哈希算法的强度。
4.3 签名与验证流程
好，我们来看具体怎么操作。假设你是一个固件开发者，你要发布一个新版本的制导算法固件。
签名过程（在安全编译服务器上执行）：
- 计算固件镜像的SHA-384哈希值
- 用私钥对哈希值进行ECDSA签名
- 将签名附加到固件镜像尾部
- 将固件镜像 + 签名一起发布
验证过程（在导弹的Bootloader中执行）：
- 从固件尾部提取签名
- 计算固件镜像的SHA-384哈希值
- 用公钥验证签名是否匹配
- 匹配则启动，不匹配则拒绝执行
代码示例（伪代码，实际项目中我会用C语言实现）：
// 签名验证伪代码
bool verify_firmware(uint8_t* firmware, uint32_t size) {
// 提取签名（假设签名在固件末尾48字节）
uint8_t* signature = firmware + size - ECDSA_SIG_SIZE;
uint32_t fw_size = size - ECDSA_SIG_SIZE;
// 计算哈希
uint8_t hash[48]; // SHA-384输出48字节
sha384_calculate(firmware, fw_size, hash);
// 验证签名
if (ecdsa_verify(public_key, hash, signature) == SUCCESS) {
return TRUE; // 验证通过
} else {
return FALSE; // 验证失败
}
}警告：千万不要把私钥放在编译服务器上！我曾经见过一个团队，把私钥直接硬编码在构建脚本里，结果整个密钥库被一锅端。正确的做法是使用硬件安全模块（HSM）来存储私钥，签名操作在HSM内部完成，私钥永远不离开硬件。
4.4 公钥基础设施（PKI）部署
单个密钥对不够用。你想想看，一个导弹可能有多个子系统：导航系统、控制系统、引信系统...每个系统都需要独立的密钥。而且密钥需要定期轮换，万一某个密钥泄露了，还得能撤销。
这就是PKI的用武之地。在军工项目中，我建议采用三级PKI架构：
- 根CA（离线）：只用于签发中间CA证书，平时断网保存，放在保险柜里
- 中间CA（在线）：负责签发各个子系统的签名证书
- 终端证书：每个子系统或每个固件版本使用独立的签名证书
部署时要注意几个坑：
- 证书链验证：Bootloader里要内置根CA的公钥，验证时逐级向上追溯，直到根证书
- 证书撤销列表（CRL）：如果某个证书泄露了，要能及时撤销。我建议在固件更新时附带最新的CRL
- 密钥生成：所有密钥对必须在安全环境中生成，最好使用真随机数发生器（TRNG）
个人经验：我曾经在某个项目中，把根CA的私钥放在一个U盘里，结果U盘坏了...从那以后，我坚持使用智能卡或HSM来存储根密钥，而且至少做三个物理备份，分别存放在不同地点的保险柜里。
4.5 避坑指南
最后，分享几个我踩过的坑：
- 哈希值比较要用恒定时间比较函数：不能用memcmp，否则可能被时序攻击破解。要用专门的secure_memcmp函数
- 签名验证失败后的处理：不要只是打印错误日志就继续执行。我建议直接进入安全模式，或者触发看门狗复位
- 公钥的存储位置：公钥要放在Bootloader的只读区域，并且用硬件写保护。如果公钥被篡改，整个签名验证体系就形同虚设
- 算法实现要使用经过认证的库：不要自己写ECDSA实现。军工项目通常要求使用FIPS 140-2或140-3认证的密码库
嗯，这一章的内容就到这里。ECDSA + SHA-384 + PKI这套组合拳，是导弹制导系统固件防护的基石。下一章我们会讲如何把这些技术整合到安全启动链中，实现从复位到操作系统加载的完整信任链。