8、OTA升级安全机制：签名验证流程、公钥证书管理、dm-verity与AVB校验、防回滚保护
OTA升级，说白了就是把新系统送到用户手里。但你想过没有——如果这个“送”的过程被坏人截胡了，怎么办？
我早年做第一版OTA方案时，就踩过这个坑。当时只想着怎么把包传得快、装得稳，结果安全方面几乎裸奔。后来被安全团队怼了一顿，才老老实实把签名、校验、防回滚这些机制补上。嗯，今天咱们就把这块彻底讲透。
8.1 签名验证流程：从源头保证包的合法性
OTA升级包不是随便谁都能发的。你得证明“这个包是我官方出的”。怎么证明？用数字签名。
流程其实不复杂，我拆成三步讲：
- 签名阶段（服务端）：用私钥对升级包的哈希值加密，生成签名文件。
- 打包阶段：把升级包 + 签名文件 + 公钥证书一起塞进OTA包。
- 验证阶段（设备端）：用公钥解密签名，比对哈希值。一致就通过，不一致就拒绝。
这里有个关键点——设备端必须信任那个公钥。如果公钥本身是假的，那签名验证就形同虚设了。
核心原则：签名验证不是防破解，而是防篡改。它保证的是“包在传输过程中没被人动过”，而不是“包本身没有漏洞”。
我在项目中遇到过一件事：某次升级包签名验证一直失败，查了半天发现是设备端的公钥证书过期了。嗯，证书管理也是个坑，咱们接着聊。
8.2 公钥证书管理：信任链怎么搭
公钥不能裸奔。你得把它包在一个证书里，证书里还有有效期、颁发者、用途等信息。Android系统用的是X.509证书标准。
信任链长这样：
- 根证书：预置在设备ROM里，不可更改。这是信任的起点。
- 中间证书：由根证书签发，用于日常签名。
- 终端证书：真正用来签OTA包的证书，由中间证书签发。
为什么要搞这么复杂？说白了就是安全隔离。如果终端证书泄露了，你只需要吊销它，重新签发一个就行。根证书不用动。如果根证书泄露了……嗯，那整个设备都得召回。
我的习惯：根证书用硬件安全模块（HSM）存储，私钥永远不离开HSM。中间证书和终端证书可以放在普通服务器上，但私钥必须加密存储。
我曾经见过一个厂商，把所有证书的私钥都放在同一个Git仓库里。结果代码泄露，所有设备一夜之间变砖。你说惨不惨？
8.3 dm-verity与AVB校验：运行时保护
签名验证只保证升级包在安装前是好的。但装完之后呢？如果有人通过漏洞拿到了root权限，改了系统分区里的文件，怎么办？
这时候就需要dm-verity和AVB（Android Verified Boot）出场了。
8.3.1 dm-verity：块设备级别的完整性校验
dm-verity是Linux内核的一个特性。它把系统分区划分成一个个块，每个块都有一个哈希值。这些哈希值组成一棵Merkle树，根哈希值存储在设备的安全区域。
每次读取文件时，内核都会校验这个块对应的哈希值。如果发现不匹配，直接返回I/O错误。你想想看，就算攻击者改了系统文件，只要一读就报错，根本跑不起来。
注意：dm-verity只校验读取的块，不是全盘扫描。所以如果攻击者改了文件但没人读它，系统不会报错。但大多数情况下，系统启动和运行时会读取大量文件，所以效果还是很好的。
8.3.2 AVB：从bootloader到系统的完整信任链
AVB是Google在Android 8.0之后推的校验方案。它比dm-verity更进一步——把校验从系统分区扩展到了整个启动链。
AVB的流程是这样的：
- Bootloader校验boot分区（内核和ramdisk）。
- Boot分区校验system分区。
- System分区校验vendor分区。
- ……以此类推，直到所有分区都校验通过。
每个分区都有一个vbmeta结构体，里面存了该分区的哈希值和签名。Bootloader用预置的公钥验证vbmeta的签名，然后逐级往下校验。
我画了一张图，帮你理解这个信任链：
你看，这个信任链是从硬件（Bootloader）开始的，一直延伸到系统分区。只要Bootloader没被攻破，整个链就是安全的。
8.4 防回滚保护：为什么不能降级
你可能觉得奇怪——降级有什么问题？我装回旧版本不行吗？
嗯，问题大了。旧版本可能有已知漏洞。攻击者可以刷回旧版本，然后用已知漏洞提权。这就是所谓的回滚攻击。
Android的防回滚机制是这样的：
- 每个系统分区都有一个回滚索引（rollback index）。
- 每次升级时，回滚索引递增。
- 设备启动时，Bootloader会检查当前分区的回滚索引是否大于等于安全存储区里记录的值。
- 如果小于，说明是降级，直接拒绝启动。
这个安全存储区通常是RPMB（Replay Protected Memory Block），在eMMC或UFS芯片里。它硬件上就防篡改，软件根本改不了。
我曾经踩过的坑：有一次升级后回滚索引没更新，导致所有设备都无法启动。后来发现是升级脚本里忘了调用更新回滚索引的API。从那以后，我每次做OTA都会在测试用例里专门加一条——降级测试。确保降级确实被阻止，而不是因为bug导致无法启动。
8.5 综合安全架构：四层防护
把上面这些机制串起来，就是一套完整的OTA安全体系：
| 防护层 | 机制 | 防护目标 | 我的建议 |
|---|---|---|---|
| 传输层 | HTTPS + 签名验证 | 防止包在传输中被篡改 | 必须用HTTPS，别用HTTP |
| 安装层 | 签名验证 + 证书链校验 | 防止伪造包被安装 | 证书有效期别设太长，1-2年最佳 |
| 运行时 | dm-verity + AVB | 防止系统分区被篡改 | 建议开启强制校验，别留后门 |
| 版本控制 | 防回滚保护 | 防止降级到有漏洞的版本 | 回滚索引要跟版本号绑定 |
这四层缺一不可。你想想看，如果只做了签名验证，没做防回滚，攻击者可以刷回旧版本用漏洞提权。如果只做了防回滚，没做dm-verity，攻击者可以改了系统文件后直接启动。所以，每一层都得守住。
个人经验：我建议在开发阶段就开启AVB和dm-verity，别等到发布前才加。因为这两个机制会影响启动速度和调试方式。早点适配，早点发现问题。我曾经见过一个团队，发布前一周才开AVB，结果发现某些分区校验失败，加班改了一周才搞定。
好了，OTA安全这块就讲到这里。记住一句话：安全不是功能，是习惯。每次做OTA，都把这四层过一遍，养成肌肉记忆，就不会出大问题。