!Y11Han!

核心机制#

AVB（Android Verified Boot）是 Google 强制推行的启动链完整性验证框架（Android 8.0+），用于验证从 BootROM 到 System 分区的每一级启动镜像是否被修改，包括 boot.img vendor_boot.img system/vendor/product vbmeta 本身

关键文件：vbmeta.img 存储所有以上受保护分区的哈希树、公钥和签名
验证失败：触发 verifiedbootstate=red，等死吧

verifiedbootstate btw

green：官方签名，完整信任链 -> 释放 FBE 密钥 / KDK
orange：用户解锁 bl -> 销毁 KDK，仅允许基础功能
red：监测到篡改 -> 永久禁用安全服务（包括 Widevine L1 密钥），机都别想开

AVB 根本就他吗不关心你能不能用 TEE 密钥，要么绿要么橘要么红，红灯直接死，就算绿灯也不代表你设备安全

AVB 与 TEE 的致命关联#

TEE（如 [[#^Keymaster TA]]）在初始化时会读取内核参数 androidboot.verifiedbootstate

核心概念#

TEE（Trust Execution Environment 可信执行环境），是 SoC 中独立于系统的硬件级安全隔离环境（如 ARM Trust Zone）。
保护：指纹支付，DRM 高清内容解密（如 Netflix），存储加密密钥。即便设备被 root 也无法读取 TEE 数据。

Root 会破坏 TEE 的完整性。
获取 Root 权限需解锁 Bootloader（触发 [[#^AVB 2.0]] 验证失败），导致：

• Verified Boot 失败：系统分区被修改，TEE 监测到非官方签名，拒绝提供安全服务（如指纹支付）
• 密钥吊销：部分厂商（如三星）在检测到 root 后永久熔断 e-fuse，使 TEE 拒绝生成新密钥

支付宝 / 微信指纹支付，银行 app，DRM L1 视频播放（如 4K Netflix）通常失效，根源在于 TEE 拒绝向被篡改的系统提供高密钥。

指纹支付依赖 TEE#

绕过尝试：伪装认证状态但无法恢复 TEE 内部数据

data 分区加密依赖 TEE#

FBE（File-Based-Encryption）的密钥由 TEE 保护。FBE 专门用于加密 /data 分区。FBE 并非全盘加密，不加密 /system、/vendor 等系统分区（这些分区通过 [[#^AVB 2.0]] 校验完整性，但不加密）
FBE 采用分层密钥结构，人话就是锁屏密码不直接作为加密密钥，而是作为密钥派生凭证

图看不懂？让我们说中文：

TEE 在解密 data 时干的活

1.密钥永不暴露：
KDK 在 TEE 内部生并永久存储，操作系统无法读取。锁屏密码只作为输入，在 TEE 内通过 KDF（如 script 或 SHA-256）派生临时密钥
2.解密流程：
用户输入密码 -> 密码哈希值传入 TEE -> TEE 用 KDK 验证哈希 -> 验证成功则释放解密 User Key 所需的密钥 -> User Key 解密 DEK -> DEK 解密文件
3.总结：
FBE 的加密密钥不是锁屏密码，厂商也不允许导出 KDK

TEE 硬件熔断#

WARNING

如果你去问 AI “关于硬件熔断各大手机厂商的做法”，你很有可能得不到正确的答案。
例如，解锁 bl = 熔断硬件保险丝（如高通 frp 分区），即使重锁也无法恢复 green 状态（e-fuse 物理熔断不可逆） 这句话中包含两个严重的错误！
TEE 熔断的具体机制远比想象中和 AIGC 回答的复杂得多！

具体请见 [[硬件熔断]]

Keymaster TA#

TA（Trusted Application，可信应用）运行在 TEE 内部，不在 Android/Linux 世界。

1
SoC
2
 └─ Secure World (TEE)
3
     ├─ TEE OS (QSEE / OP-TEE / Trustonic)
4
     │
5
     ├─ Keymaster TA        ← 现在正在谈的
6
     ├─ Gatekeeper TA       ← 生物识别
7
     ├─ Widevine TA         ← DRM L1（显存给大，上下文放长，一会儿会考）
8
     ├─ OEM Security TA     ← 厂商自定义（熔断逻辑常在这里）
9
     └─ Other Trusted Apps

TA 是他吗“硬件级验证”的执行者。

以下这些都是Ta干的活：

• 生成 RSA/ECC Attestation Key
• 保存密钥（TEE 内或 StrongBox）
• 校验启动状态（verifiedBootState）
• 决定是否允许 Hardware-backed Attestation
• 对 SafetyNet/Play Integrity 请求进行签名

TA 读取 verifiedBootState，一旦 orange/red，TA 降级 key 权限，禁用 Attestation Key，返回 non-hardware-backed 等一系列硬件不可信信息。

1
Keymaster API
2
 ├─ TEE-backed Keymaster
3
 └─ StrongBox-backed Keymaster
4
       └─ 独立安全芯片 / Secure Element

DRM 和 Widevine#

Widevine / DRM 与 Keymaster TA 并列，同属 TEE 内的 Trusted Application

1
TEE / Secure World
2
  ├─ Keymaster TA        ← 身份 / Attestation
3
  ├─ Widevine TA         ← DRM / 内容解密
4
  ├─ Gatekeeper TA       ← 生物识别
5
  └─ OEM Security TA     ← 熔断 / 状态机

QUESTION

猜猜 DRM 去哪里了？

钥匙盒子 Keybox#

Keybox 是一份设备出厂时注入的、与硬件绑定的 DRM 身份凭据。
它包含（概念层面）：

• 设备 DRM 私钥材料
• OEM / Google 签名
• 设备型号、厂商信息
• 绑定 SoC / TEE 的信息

它不在 system/vendor，不在 vbmeta，普通刷机永远接触不到。

谷歌吊销 Revoke 机制：

• 触发条件：
  • 设备密钥泄漏：如维修点非法提取 Keybox 并公开售卖
  • 安全漏洞利用：攻击者通过漏洞批量提取 Keybox（如旧版高通漏洞）
  • 谷歌检测异常：同一 Keybox 在多设备激活
• 吊销后果：
  • Widevine 等级降至 L3，视频 APP 限制分辨率
  • 谷歌通过 CRL（证书吊销列表）远程推送，设备联网后自动生效

1
<AndroidAttestation>
2
  <NumberOfKeyboxes>1</NumberOfKeyboxes>
3
  <Keybox DeviceID="Telegram @BDovo_Channel">
4
    <Key algorithm="ecdsa">
5
      <PrivateKey>-----BEGIN EC PRIVATE KEY-----</PrivateKey>
6
      <CertificateChain>
7
        <Certificate>-----BEGIN CERTIFICATE-----</Certificate>
8
        ...
9
      </CertificateChain>
10
    </Key>
11
  </Keybox>
12
</AndroidAttestation>

核心概念#

远程设备完整性与可信状态证明服务，不验证启动，只验证 TA 是否能给出硬件签名（已逐步被 Play Integrity API 取代）
Google 在 SafetyNet 中首次把 TEE/StrongBox 的 Attestation 能力强制暴露给 APP

他不是本地安全机制，而是：

• 设备向 Google 服务请求“证明”
• Google 返回一个签名的 Attestation 结果
• APP 验证结果，决定是否允许允许

SafetyNet 的两种验证模式#

Widevine 与 SafetyNet / Integrity 的关系#

Google Play Integrity API#

来都来了，再看看占上风的 Play Integrity API 吧

这是给开发者 / 服务器用的 设备与应用完整性证明接口，是 SafetyNet 的继任者。
（请区别于 Play Protect/Play 保护机制，那是给用户用的本地恶意软件防护与应用扫描机制）

它的作用是让 APP 判断：这个请求是不是来自一个“未被篡改、未被滥用、可信的 Android 设备与 APP 实例”
它检查的维度包括设备完整性、应用完整性和账号 / 环境。

为什么 Google 要换掉 SafetyNet？

• 返回字段太多、太透明
• 易被针对性绕过（Magisk 时代）
• 客户端可验证（被 Hook）
• OEM 策略暴露过多

改进方向：

• 强制服务端校验
• 策略黑盒化
• 与 Play 服务账号、分发强绑定
• 降低“字段级伪造”空间