4. 签名与验签机制：代码签名流程、证书链管理、验签失败处理策略
好，咱们接着聊OTA升级里最核心的一环——签名与验签。
说白了，这就是给升级包上一把「数字锁」。没有这把锁，谁都能往你设备里塞代码，那还得了？我早年做嵌入式时，见过一个产品因为没做签名校验，被黑客远程刷了个恶意固件，整批设备直接变砖。嗯，从那以后，我对签名机制就特别较真。
4.1 代码签名流程：从编译到打包
签名不是最后才做的事。它贯穿了整个发布流程。我个人习惯把它分成三步：
- 摘要计算：对固件包做哈希，生成一个固定长度的摘要。鸿蒙用的是SHA-256或SHA-512。
- 私钥加密：用发布者的私钥对这个摘要进行加密，生成签名。
- 打包：把原始固件、签名、以及发布者的证书一起打包成升级文件。
你想想看，这个流程保证了什么？保证了固件内容只要被改过一个比特，验签时哈希就对不上。保证了签名只有持有私钥的人才能生成，别人伪造不了。
核心原则：私钥永远不出服务器，公钥才分发到设备端。
我在项目中遇到过有人把私钥直接放在CI流水线里，结果被泄露了。那真是灾难性的——所有已出货的设备都得召回重新烧录公钥。所以，私钥管理一定要用HSM（硬件安全模块）或者专门的密钥管理服务。
4.2 证书链管理：信任的传递
单靠一个公钥验签，其实不够安全。为什么？因为公钥本身也可能被替换。所以我们需要证书链。
证书链说白了就是「我信他，他信你」的链条。鸿蒙系统里通常有三层：
- 根证书：预置在设备ROM里，不可更改。这是信任的锚点。
- 中间证书：由根证书签发，用于签发最终的代码签名证书。这样做的好处是，即使中间证书泄露，根证书还在，可以吊销它。
- 代码签名证书：真正用来签固件的证书。有效期短，方便轮换。
| 证书层级 | 存储位置 | 有效期 | 泄露影响 |
|---|---|---|---|
| 根证书 | 设备ROM（只读） | 10年+ | 灾难性，需硬件召回 |
| 中间证书 | 升级包中携带 | 3-5年 | 可吊销，影响范围可控 |
| 代码签名证书 | 升级包中携带 | 1-2年 | 影响最小，快速轮换 |
验签时，设备会做两件事：第一，用根证书的公钥验证中间证书的合法性；第二，用中间证书的公钥验证代码签名证书的合法性。全部通过，才用代码签名证书的公钥去验固件签名。
避坑指南：我曾经见过一个团队，把根证书的有效期设成了100年。结果发现根证书的哈希算法（SHA-1）已经过时了，新设备不支持。嗯，最后只能改ROM。所以，根证书的算法和有效期一定要有前瞻性。
4.3 验签失败处理策略：不能直接变砖
验签失败怎么办？直接拒绝升级？还是回滚？这里面的门道很多。
我建议把失败场景分成几类：
- 证书链验证失败：说明证书本身有问题，可能是被篡改或过期。这时候应该直接拒绝，并记录错误日志。
- 签名验证失败：说明固件内容被修改过。这时候要小心——可能是传输错误，也可能是恶意攻击。
- 时间戳验证失败：证书过期了。如果设备没有实时时钟，这个很容易踩坑。
处理策略上，我一般这么设计：
- 重试机制：如果是网络传输导致的包损坏，允许重新下载一次。但重试次数要有限制，比如3次。
- 回滚到上一版本：如果验签失败，设备应该能启动上一个正常版本。鸿蒙的AB分区机制就是干这个的。
- 进入恢复模式：如果连回滚都失败了，那就进入恢复模式，等待用户通过USB或SD卡手动刷机。
- 记录失败信息：把失败原因、证书指纹、时间戳等信息写到日志分区。方便后续排查。
警告：千万不要在验签失败时直接擦除当前系统！我曾经见过一个产品，验签失败后执行了format操作，结果设备彻底变砖，连恢复模式都进不去。那真是叫天天不应。
还有一个细节：验签的时机。是在下载完成后验？还是边下载边验？我个人推荐边下载边验。这样可以提前发现恶意包，不用等下载完才拒绝。鸿蒙的升级框架支持流式验签，就是每收到一个数据块，就计算部分哈希，最后合并验证。效率高很多。
4.4 代码示例：鸿蒙验签核心逻辑
下面是一个简化的验签流程，用C语言风格写的。实际鸿蒙源码里会更复杂，但核心逻辑就是这样：
// 伪代码：鸿蒙OTA验签流程
int verify_ota_package(const char* package_path) {
// 1. 读取根证书（从ROM）
cert_t root_cert = read_root_cert_from_rom();
// 2. 从升级包中提取证书链
cert_chain_t chain = extract_cert_chain(package_path);
// 3. 验证证书链
if (!verify_cert_chain(root_cert, chain)) {
log_error("证书链验证失败");
return -1;
}
// 4. 获取代码签名证书的公钥
public_key_t pub_key = chain.leaf_cert.public_key;
// 5. 读取固件和签名
firmware_t fw = extract_firmware(package_path);
signature_t sig = extract_signature(package_path);
// 6. 计算固件哈希
hash_t hash = sha256(fw.data, fw.size);
// 7. 用公钥验签
if (!rsa_verify(pub_key, hash, sig)) {
log_error("固件签名验证失败");
return -2;
}
log_info("验签通过，可以升级");
return 0;
}你看，代码不长，但每一步都不能省。尤其是第3步的证书链验证，很多人会漏掉，直接拿叶子证书的公钥去验签。那样的话，攻击者只要替换整个证书链，就能绕过验签。
小技巧：验签时最好加上防重放攻击。比如在固件包里嵌入一个单调递增的版本号，设备端记录上次升级的版本号，拒绝比当前版本低的包。这样能防止攻击者拿一个旧版本的合法固件来降级攻击。
好了，签名与验签这块就聊到这儿。记住一句话：信任不能传递，必须验证。证书链就是信任的传递机制，而验签就是最后的把关人。把这两块做好了，你的OTA升级才算真正安全。