2. 安全启动基础

安全启动（Secure Boot）是一套由硬件信任根逐级验证、逐级传递信任的启动机制。它的核心目标不是“让系统启动得更快”，而是确保设备从上电到操作系统运行之间，每一段被执行的代码都经过密码学验证，未被篡改、未被替换、未被降级。在 Android 设备中，安全启动通常与 Verified Boot、dm-verity、AVB（Android Verified Boot）等机制协同工作，形成一条从 BootROM 到 system 分区的可信链。

一句话理解：安全启动把“设备启动”从“默认信任所有代码”变成“逐级验证后才允许执行”，从而把攻击者最常利用的启动早期阶段纳入可信控制。

一、安全启动的核心原理与信任链

安全启动依赖一个不可变的硬件信任根（Root of Trust, RoT）。在 Android 设备中，这个信任根通常固化在 BootROM 或硬件熔丝中，负责验证第一阶段引导程序（如 Primary Bootloader / SPL）的数字签名。验证通过后，控制权才交给下一阶段；下一阶段再验证再下一阶段，依次类推，直到 boot、dtbo、vbmeta、system、vendor 等分区。

这条链的关键在于“信任传递”：每一级只信任由上一级验证通过的下一级。如果某一级签名不匹配、哈希不一致或版本被回滚，启动流程会拒绝继续，或进入恢复模式、显示警告、甚至触发硬件熔断。Android 的 AVB 还引入了 vbmeta 结构，把多个分区的哈希和签名集中管理，使验证更高效、更易扩展。

Android 安全启动信任链：逐级验证，逐级传递 每一级只信任上一级验证通过的下一级；任一环节失败即中断或降级 硬件信任根 BootROM / 熔丝 不可修改 · 上电即执行 一级引导 SPL / PBL 验证签名与哈希 二级引导 U-Boot / LK 加载并验证 vbmeta Android 系统 boot / system dm-verity 持续校验 验证对象与关键数据 boot / init_boot 内核与 ramdisk vbmeta / dtbo 哈希与签名集合 system / vendor 只读分区完整性 回滚索引 Rollback Index 防止降级到旧漏洞版本 验证失败时的典型行为 • 红色警告屏 / 无法进入系统 • 进入 recovery 或 fastboot 模式 • 触发熔丝、清除用户数据或拒绝启动 安全启动带来的核心收益 • 阻止未签名内核与恶意 ramdisk 加载 • 保护 system/vendor 分区不被静默篡改 • 为 KeyStore、DRM、支付等提供可信基础

二、威胁模型：安全启动到底防什么

安全启动的威胁模型主要针对“启动早期代码被篡改”这一类攻击。攻击者可能通过物理接触、fastboot 刷机、OTA 劫持、恶意固件替换、降级攻击等方式，试图让设备运行未授权代码。安全启动要防的不是所有攻击，而是把信任边界前移到硬件，使攻击者无法轻易绕过验证。

  • 未签名代码执行：攻击者替换 boot 分区，植入自定义内核或 rootkit，安全启动会因签名不匹配而拒绝。
  • 分区篡改：直接修改 system/vendor 分区内容，dm-verity 与 AVB 会在块级别发现哈希不一致。
  • 降级攻击：把系统回滚到存在已知漏洞的旧版本，Rollback Index 会阻止版本号低于当前熔丝值的镜像启动。
  • 持久化植入：在引导链中插入恶意阶段，逐级验证会因上一级签名不匹配而中断。
  • OTA 中间人：篡改 OTA 包，签名验证与元数据校验会拒绝安装或启动。
注意：安全启动并不等于“设备绝对安全”。它主要保护启动链和只读分区；对已解锁 Bootloader 的设备，攻击者可以关闭验证或刷入自定义镜像。因此，生产设备通常要求锁定 Bootloader，并配合硬件密钥、TEE 与远程证明。

三、与普通启动的区别

普通启动的目标是“尽快把系统跑起来”，通常默认信任 Flash 中的内容；安全启动的目标是“只运行被授权的代码”，在每一步增加密码学验证。两者在流程、失败行为、性能开销和可调试性上都有明显差异。

对比维度 普通启动 安全启动
信任假设 默认信任 Flash 内容 只信任硬件信任根与已验证镜像
验证方式 无签名或哈希校验 逐级签名验证 + 哈希校验
失败行为 继续启动或随机崩溃 中断启动、警告、恢复模式或熔断
性能开销 较低 增加验证时间，但可并行与缓存优化
可调试性 可自由刷机、改内核 需解锁或使用签名镜像，调试受限
典型场景 开发板、工程机 量产手机、支付终端、车机、IoT

四、在 Android 中的重要性

Android 生态高度依赖“设备可信”这一前提。支付、DRM、企业 MDM、生物识别、密钥存储等能力，都要求系统在启动时没有被篡改。安全启动是这些能力的底座：只有启动链可信，TEE 才能安全地保存密钥，KeyStore 才能证明应用运行在可信环境，远程证明才能向服务器报告设备完整性。

从 Android 7 开始，Verified Boot 逐步强制化；Android 10 以后，AVB 与 dm-verity 成为量产设备的基本要求。Google 的 CDD/GMS 认证也把安全启动与 Bootloader 锁定列为关键项。对开发者而言，理解安全启动有助于排查“刷机后无法开机”“OTA 失败”“dm-verity 报错”等问题；对安全工程师而言，它是分析启动链攻击面和设计可信执行环境的基础。

实践提示：调试安全启动问题时，优先确认 Bootloader 锁定状态、vbmeta 是否禁用验证、Rollback Index 是否匹配、以及分区哈希是否与签名元数据一致。常见命令包括 fastboot getvar all、avbtool verify_image 与 adb shell dmesg | grep -i verity。 
# 查看设备启动状态与验证信息（示例）
fastboot getvar unlocked
fastboot getvar secure
fastboot getvar current-slot

# 校验 vbmeta 与 boot 镜像（主机侧）
avbtool verify_image --image vbmeta.img
avbtool verify_image --image boot.img

# 设备侧查看 dm-verity 状态
adb shell dmesg | grep -i "dm-verity"
adb shell getprop ro.boot.veritymode

总结来看，安全启动是 Android 可信链的起点。它通过硬件信任根、逐级签名验证、回滚保护和只读分区完整性校验，把攻击者挡在启动早期之外。理解其定义、作用、威胁模型与普通启动的差异，是后续学习 AVB、dm-verity、TEE 与远程证明的必要基础。

← 上一章 📖 返回目录 下一章 →