TEE(Trusted Execution Environment)技术详解

木由里予2026-08-06 9:18

TEE(Trusted Execution Environment)技术详解

文档版本:1.0

适用读者:Android 系统工程师、安全工程师、ROM 开发者、售后/失效分析工程师

目录

  1. [TEE 概念与定位](#TEE 概念与定位)
  2. [REE 与 TEE 的关系](#REE 与 TEE 的关系)
  3. 硬件基础
  4. [TEE 软件架构](#TEE 软件架构)
  5. [主流 TEE 实现对比](#主流 TEE 实现对比)
  6. [TEE 核心服务](#TEE 核心服务)
  7. [TEE 与 RPMB 的关系](#TEE 与 RPMB 的关系)
  8. [TEE Provisioning 流程](#TEE Provisioning 流程)
  9. [TEE 通信机制](#TEE 通信机制)
  10. [安全启动链与 TEE](#安全启动链与 TEE)
  11. 调试与日志
  12. 常见故障排查
  13. 附录:术语表

1. TEE 概念与定位

1.1 什么是 TEE

TEE(Trusted Execution Environment,可信执行环境) 是与主操作系统(Rich OS,如 Android/Linux)隔离的、独立运行的 secure world。它拥有自己的 CPU 执行态、内存、存储、外设访问能力,运行经过签名的可信应用(Trusted Application, TA)。

TEE 的核心价值:

  • 隔离性:即使 Rich OS(REEmain Android/Linux)被完全攻破,TEE 中的代码和数据仍然安全
  • 可度量:TEE 启动经过链式校验,状态可远程证明(Attestation)
  • 密钥保护:硬件根密钥、用户生物特征模板、支付密钥等敏感数据只能存于 TEE
  • 抗回滚:配合 RPMB 实现版本/状态回滚保护

1.2 为什么需要 TEE

Android 主系统(REEmain OS)极其复杂,内核漏洞、驱动漏洞层出不穷,一旦被攻破,存储在主系统的任何"密钥"都可被提取。TEE 通过硬件隔离把"最敏感的操作"放到一个攻击面小得多的环境里。

典型必须放在 TEE 的功能:

  • 屏幕指纹/人脸模板比对
  • 支付宝/微信支付的根密钥
  • DRM 内容密钥(Widevine L1)
  • Android Keystore 中 authBound 类型的密钥
  • 设备身份认证(Play Integrity / Hardware Attestation)
  • FBE 文件加密的派生密钥

1.3 GP 规范

GlobalPlatform(GP)是 TEE 标准的主要制定者,定义了:

  • TEE Internal Core API(TA 开发接口)
  • TEE Client API(REE 侧 CA 调用 TA 的接口)
  • TEE 与 Rich OS 通信协议
  • Trusted UI 规范(TEE 渲染到屏幕的安全通道)

各家厂商实现并不完全兼容,但都遵循 GP API 规范。

2. REE 与 TEE 的关系

2.1 双世界架构

复制代码 
┌─────────────────────────────────────────────┐
│               Normal World (REE)             │
│  ┌──────────────────────────────────────┐   │
│  │  Android/Linux 用户空间              │   │
│  │  - 普通 App                          │   │
│  │  - 系统服务 (Keystore2, Gatekeeper)  │   │
│  │  - CA (Client App, 调用 TA)         │   │
│  └──────────────────────────────────────┘   │
│  ┌──────────────────────────────────────┐   │
│  │  内核驱动                            │   │
│  │  - trusty-ipc / qseecom / mtk-te    │   │
│  └──────────────────────────────────────┘   │
└──────────────────┬──────────────────────────┘
                   │ SMC / HVC (secure monitor call)
┌──────────────────┴──────────────────────────┐
│              Secure World (TEE)              │
│  ┌──────────────────────────────────────┐   │
│  │  TEE OS (Trusty / QSEE / MTK TEE)   │   │
│  └──────────────────────────────────────┘   │
│  ┌──────────────────────────────────────┐   │
│  │  Trusted Applications (TA)            │   │
│  │  - KeyMint TA                        │   │
│  │  - Gatekeeper TA                     │   │
│  │  - Fingerprint TA                    │   │
│  │  - Widevine TA                       │   │
│  └──────────────────────────────────────┘   │
└─────────────────────────────────────────────┘
                   │
                   ▼
        ┌────────────────────┐
        │  Hardware Root of  │
        │  Trust (Efuse/ROM) │
        └────────────────────┘

2.2 CPU 执行态

ARMv8 起,异常等级(Exception Level, EL)分四级:

EL 名称 用途
EL0 User 应用(REE 的 App,TEE 的 TA)
EL1 Kernel 操作系统内核(REE Linux,TEE OS 内核)
EL2 Hypervisor 虚拟化(可选)
EL3 Secure Monitor 切换 REE/TEE 的唯一入口

ARMv9 引入了 Realm 概念(Confidential Compute Architecture, CCA),扩展为四个世界:Normal / Secure / Realm / Root,这是 TEE 的演进方向。

2.3 切换机制

REE 调用 TEE 的唯一通道是 SMC(Secure Monitor Call)或 HVC(Hypervisor Call)。流程:

  1. REE 用户态 CA 调用 TEE Client API(libteec)
  2. libteec 进入内核驱动(trusty-ipc / qseecom)
  3. 内核驱动构造请求,执行 SMC #0
  4. CPU 跳到 EL3 Secure Monitor
  5. Secure Monitor 切换到 TEE OS(寄存器上下文切换、内存隔离切换)
  6. TEE OS 分发到对应 TA
  7. TA 处理后返回结果,反向回 REE

单次调用开销:通常几十微秒,通信成本不可忽略。

2.4 内存隔离

  • TF-A(Trusted Firmware-A):在 EL3 负责 REE/TEE 切换、SMC 路由、电源管理
  • MMU/SMMU:TEE 内存被映射为 secure-only,REE 内核也无法访问
  • TZASC / SMMU:硬件级别拦截非 secure 总线对 secure 内存的访问
  • XPU:总线上拦截非 secure master 访问 secure 外设

即使 REE 内核被攻破,也无法直接读 TEE 内存。

3. 硬件基础

3.1 Hardware Root of Trust (HRoT)

SoC 内部的不可篡改信任根:

组件 作用
Boot ROM 芯片出厂烧录,首次启动执行的代码,校验 SPL/bootloader
Efuse (eFUSE) 一次性可编程熔丝,烧入后不可改;存 hash key、RPMB key、SoC serial、boot lock 状态
Secure JTAG 默认禁用,需要 efuse 授权码才能开
Unique Device Key (UDK) 每颗芯片唯一,用于派生设备绑定密钥

3.2 关键安全外设

外设 用途
RPMB partition eMMC/UFS 上的安全存储分区,带认证和回滚保护
Crypto engine 硬件加速 AES/RSA/ECDSA/SHA
True RNG (TRNG) 硬件真随机数源
PUF 物理不可克隆函数,部分芯片用作密钥派生
Secure timer / watchdog TEE 独立的时间源和看门狗
Secure interrupt controller (GIC) 部分 IRQ 路由到 secure world

3.3 TrustZone

ARM TrustZone 是 TEE 的硬件基础,把每个物理 CPU 核分为两个虚拟核:

  • NS bit = 0:Secure 状态,可访问所有内存和外设
  • NS bit = 1:Non-secure 状态,只能访问 non-secure 资源

NS 位在总线事务上传输,硬件外设和内存控制器(TZASC)根据 NS bit 决定是否允许访问。

3.4 StrongBox vs TEE Backed

Android Keystore 中有两种 KeyMint 实现:

类型 硬件 安全等级
TEE Backed 在主 TEE 中跑 KeyMint TA 高,但若 TEE 被攻破则失效
StrongBox 独立安全芯片(SE)或独立 TEE 实例 更高,与主 TEE 进一步隔离

StrongBox 是 Android 14+ 推荐用于最高敏感密钥的方案,典型实现:

  • 高通:SUI(Secure User Interface) + 独立 KeyMint TA 实例
  • 谷歌 Pixel:Titan M 独立芯片
  • 三星:Knox Vault 独立子系

4. TEE 软件架构

4.1 分层结构

复制代码 
┌─────────────────────────────────────────────┐
│  Trusted Applications (TA)                   │
│  KeyMint TA | Gatekeeper TA | Fido TA | ...  │
├─────────────────────────────────────────────┤
│  TEE Client API / Internal API               │
├─────────────────────────────────────────────┤
│  TEE OS Kernel                              │
│  - Scheduler                                │
│  - Memory Management                        │
│  - IPC                                      │
│  - Driver Framework                         │
├─────────────────────────────────────────────┤
│  HAL Driver                                 │
│  - RPMB driver                              │
│  - Crypto engine driver                     │
│  - HWRNG driver                             │
│  - Interrupt driver                         │
├─────────────────────────────────────────────┤
│  Hardware (SoC + Efuse + RPMB + Crypto)     │
└─────────────────────────────────────────────┘

4.2 TEE OS 类型

两类架构:

单体内核(Monolithic)
  • 所有 TEE 服务在单一地址空间
  • 性能高,但攻击面大
  • 早期高通 QSEE 接近这种模式
微内核(Microkernel)
  • TEE OS 只做最小调度/IPC/内存
  • 各 TA 独立地址空间,互相隔离
  • 安全性高,性能略低
  • Trusty(Google)、Open-TEE、QTEE-v2 接近这种模式

4.3 TA 加载与签名校验

  1. REE 通过 libteec 调用 TEEC_LoadTA
  2. TEE OS 检查 TA 文件签名(通常 RSA-PSS 或 ECDSA)
  3. 验签公钥来自 efuse 或 TEE 内嵌的 root key
  4. 校验 TA 完整性(SHA-256)
  5. 检查版本号防回滚(配合 RPMB)
  6. 加载到 secure 内存,启动 TA 进程

未签名或签名错误的 TA 拒绝加载,这是 TEE 安全的核心保证。

4.4 TA 生命周期

  • Load:文件载入内存
  • Open :CA 调用 TEEC_OpenSession 建立会话
  • Invoke:CA 调用命令,TA 处理
  • CloseSession:会话结束
  • Unload:无会话引用时卸载

TA 可以设计为单例(全局唯一)或多实例(每个 CA session 一个实例)。

5. 主流 TEE 实现对比

厂商 TEE 名称 应用平台 特点
Google Trusty Pixel、部分 Android One 开源、微内核、TEEC 标准
Qualcomm QSEE / QTEE 高通 SoC 商业闭源,生态成熟
Mediatek MTK TEE / Trusty-based MTK 平台 基于 Trusty 改造
Samsung TEEGRIS / Knox Vault Galaxy 系列 自研,与 Knox 深度整合
OP-TEE OP-TEE 开源,部分车载/IoT Linaro 维护,GP 兼容
Hisi TrustedCore 海思 华为自研
Microtrust TBase 第三方方案 商业方案,被部分 ROM 采用

5.1 高通 QSEE 特点

  • TA 格式:.so,需要高通签名工具
  • 通信:qseecom 驱动 / QSEECom_* API(老)→ IPCI / Trusty API(新)
  • 调试:/sys/kernel/debug/trusty-log/trusty.log
  • 老平台:/d/ipc_logging/dci_ctrl/log_cont
  • 关键 TA:keymaster、gatekeeper、securekey、fpc/goodix(指纹)

5.2 Trusty 特点

  • TA 用 C/C++ + Trusty SDK 编写
  • IPC 通过 trusty-ipc 内核驱动
  • 用户态库 libtrusty(com.android.trusty.*)
  • 支持 Rust(近期版本)
  • 调试:/sys/kernel/debug/trusty-log/trusty.log

5.3 MTK TEE 特点

  • 基于 Trusty 改造,API 类似
  • 调试:/proc/tee_log、/proc/tz_log
  • 关键 TA:keymaster、gatekeeper、microtrust_finger

6. TEE 核心服务

6.1 KeyMint / Keymaster

作用:在 TEE 中生成、存储、使用加密密钥。

Android 版本演进:

  • Android 6-:Keymaster 1.0
  • Android 9:Keymaster 4.1
  • Android 11:Keymint 1.0(AIDL,替代 HIDL)
  • Android 13:KeyMint 2.0
  • Android 14:KeyMint 3.0
  • Android 15+:KeyMint 3.0 + StrongBox 默认开启

核心能力:

能力 说明
generateKey 在 TEE 内生成密钥,私钥永不导出
importKey 导入密钥(secure import,wrapped)
exportKey 导出公钥(私钥不可导出)
attestKey 对密钥做证书签名(设备身份证明)
begin/update/finish 在 TEE 内完成签名/加解密
upgradeKey 提升密钥版本(系统升级后)
rootOfTrust 绑定启动状态

关键属性:

  • authBound:必须用户解锁后才能用(绑定 Gatekeeper)
  • userSecureId:绑定具体用户(多用户场景)
  • userAuthType:绑定指纹/人脸/PIN
  • rollbackResistant:抗回滚(配合 RPMB)
    | noAuthRequired:任何启动状态可用
    | unlockDeviceRequired:必须解锁后才能用

6.2 Gatekeeper

作用:校验用户 PIN/密码/Pattern,通过则给 Keymaster 发解锁 token。

工作流程:

  1. 用户输入密码
  2. Android LockSettingsService → IGatekeeper.verify
  3. Gatekeeper TA 比对密码哈希(slow hash,scrypt-like)
  4. 通过则生成 HW Auth Token(包含 userSid、timestamp、HMAC)
  5. Token 传给 KeyMint TA
  6. KeyMint TA 校验 Token 的 HMAC,允许使用 authBound 密钥

Token 关键字段:

  • userSecureId(每次添加密码生成新的)
  • authenticatorId(指纹/人脸 ID)
  • timestamp(TEE 时间戳)
  • HMAC(用 TEE 内的 auth key 签名,KeyMint 验证)

6.3 Fingerprint / Face TA

职责分离:

  • 指纹/人脸采集:enroll 时把模板存到 TEE 内
  • 比对:TEE 内完成,只返回"通过/不通过 + auth token"
  • 可信 UI:比对成功后,TEE 直接通过 Trusted UI 渲染解锁图标到屏幕,REE 不可伪造

关键安全设计:

  • 模板永不导出 TEE
  • 比对结果通过 HMAC token 形式给 Framework
  • Trusted UI 防钓鱼(REE 应用无法截屏 TEE UI)

6.4 Widevine DRM

作用:DRM 内容密钥解密。

等级:

等级 安全性 适用
L3 软件级 TEE 跑
L1 硬件级 视频解码也在 TEE/SE 内,REE 拿不到明文
L2 (历史) 已基本不用

L1 关键:

  • 视频流密钥在 TEE 解密
  • 视频解码在 secure video path(独立硬件管线)
  • 显示走 secure display path

6.5 Storage(TEE 安全存储)

TEE 持久化数据通常两个来源:

  • RPMB:小数据、敏感数据(根密钥、attestation key、provisioning state)
  • /persist 或 secure storage partition:大数据、相对不那么敏感(指纹模板)

存储路径形如 /persist/data/<ta_uuid>/<file>,TEE 内部加密后写入。

6.6 Secure UI (Trusted UI)

作用:让 TEE 直接渲染 UI 到屏幕,REE 不可拦截或截屏。

典型场景:

  • 指纹解锁动画
  • 支付密码输入界面
  • StrongBox 交易确认

实现:

  • TEE 控制显示控制器(overlay)优先级最高
  • 输入事件路由到 TEE
  • REE 显示被屏蔽

6.7 Attestation(身份证明)

作用:向远程服务器证明"我是在某个具体设备上、未 root、TEE 完好"。

流程:

  1. App 调用 KeyProperties.ATTESTATION_CHALLENGE 生成密钥
  2. KeyMint TA 生成证书链:leaf → device CA → Google root CA
  3. 设备 CA 由 TEE 内的 attestation root key 签名
  4. 证书返回 App,App 上传服务器
  5. 服务器验证证书链 + 校验启动状态字段

证书关键字段:

  • attestationApplicationId
  • attestationChallenge
  • rootOfTrust(verifiedBootKey、deviceLocked、bootloaderStatus)
  • osVersion、osPatchLevel、vendorPatchLevel、bootPatchLevel

用法:Play Integrity API、银行类 App、企业 MDM。

6.8 Keymaster SUI / Confirmation UI

类似 Secure UI 但更标准化,用于"用户确认交易"。

7. TEE 与 RPMB 的关系

7.1 RPMB 是什么

RPMB(Replay Protected Memory Block) 是 eMMC/UFS 协议规定的特殊分区:

  • 写入需要 HMAC-SHA256 认证
  • 写计数器单调递增,不可回退
  • 需要预先在 eMMC/UFS 内烧入 32 字节 RPMB key
  • SoC efuse 中也保存同一 RPMB key,TEE 用它签名写请求

7.2 TEE 如何用 RPMB

复制代码 
┌───────────┐    HMAC-signed     ┌────────────┐
│   TEE     │ ──────────────▶   │  RPMB       │
│  (RPMB    │                    │ partition  │
│   key in  │ ◀──────────────   │ (eMMC/UFS)  │
│   efuse)  │    read counter    └────────────┘
└───────────┘

典型用途:

  • TEE 内 wrapping key 的派生种子
  • Attestation root key
  • Shared Secret(KeyMint 与 Keymaster 共享)
  • Rollback counter
  • Provisioning state

7.3 为什么 RPMB 失败 → TEE 报 SECURE_HW_COMMUNICATION_FAILED

当 TEE 试图读 RPMB:

  1. TEE 构造请求 + HMAC
  2. 通过 SMC 通知 eMMC driver
  3. eMMC 内部校验 HMAC 和计数器
  4. 写入或返回数据

任何环节出错:

  • RPMB key 不匹配 → eMMC 拒绝 → TEE 等超时 → -50 SECURE_HW_COMMUNICATION_FAILED
  • RPMB 分区损坏 → I/O error → 同上
  • eMMC/UFS 物理故障 → 同上
  • TEE 自身 key 派生错误 → HMAC 错 → eMMC 拒绝

而 -49 INVALID_MAC 多发生在 Shared Secret 协商,因为 Shared Secret 依赖 RPMB 中的派生材料,RPM 数据丢失或不匹配 → HMAC 对不上。

7.4 persist 分区 vs RPMB

项 /persist RPMB
容量 大(MB 级) 小(4MB-16MB)
认证 无 HMAC 认证
回滚保护 无 硬件级计数器
谁写 REE + TEE 都可 TEE only
用途 较大但不太敏感的数据 根密钥、provisioning

TEE 通常加密后写到 persist,而把"解开这些数据"的 wrapping key 存到 RPMB。persist 损坏可能不影响 TEE;RPMB 损坏会让 TEE 直接起不来或大量功能失效。

8. TEE Provisioning 流程

8.1 什么是 Provisioning

新芯片出厂时,TEE 内的根密钥、attestation key 等都未生成,首次开机或工厂阶段完成这些密钥的注入过程叫 Provisioning。

8.2 工厂 Provisioning 流程

复制代码 
工厂产线
    │
    ▼
┌─────────────────┐
│ 1. SoC 上电      │
│  boot ROM → SPL  │
│  → bootloader    │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 2. 工厂工具写入  │
│  - RPMB key      │
│  - Attestation   │
│    root key     │
│  - Device ID     │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 3. TEE 首次启动  │
│  - 派生 wrapping │
│  - 写入 RPMB     │
│  - 标记 provisioned│
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 4. 远程 attestation │
│  向 Google 注册  │
│  设备证书        │
└─────────────────┘

8.3 Google 远程 Provisioning

Android 13+ 起,设备 attestation 证书不再出厂预置,而是远程下发:

  1. 设备首次启动,TEE 内生成 device-unique key
  2. 向 Google 后端请求 attestation 证书
  3. Google 后端验证设备身份,签发证书
  4. 证书存入 TEE(实际是 RPMB)
  5. 之后 attestation 用此证书链

好处:

  • 节省工厂成本(无需 per-device 烧证书)
  • 支持证书吊销
  • 设备身份更灵活

8.4 没有 Provisioning 的后果

如果 RPMB key 未烧、attestation root key 未生成:

  • TEE 启动后 Shared Secret 协商失败(-49 INVALID_MAC)
  • 部分 TA 无法初始化(-50 SECURE_HW_COMMUNICATION_FAILED)
  • Keystore2 报 NOT PROVISIONED CORRECTLY
  • 指纹/人脸/wallet/Play Integrity 全部受影响

这正是上次 log 里看到的现象。

9. TEE 通信机制

9.1 应用层调用链

复制代码 
Android App
    │
    ▼
Android Framework (Keystore2, FingerprintService, ...)
    │
    ▼
HAL: IKeyMintDevice / IGatekeeper / IFingerprint
    │   (AIDL)
    ▼
TEE Vendor HAL (libkeymint.trusty.so, libgatekeeper.qsee.so, ...)
    │
    ▼
Kernel Driver (trusty-ipc, qseecom, mtk_tee)
    │
    ▼  SMC call
Secure Monitor (EL3)
    │
    ▼
TEE OS
    │
    ▼
TA (KeyMint TA, Gatekeeper TA, ...)

9.2 TEE Client API 标准接口

c 复制代码 
TEEC_Context context;
TEEC_Session session;
TEEC_Operation op;

TEEC_InitializeContext(NULL, &context);
TEEC_OpenSession(&context, &session, &uuid, ...);

// 调用 TA 命令
op.paramTypes = TEEC_PARAM_TYPES(...);
TEEC_InvokeCommand(&session, CMD_XXX, &op, &origin);

TEEC_CloseSession(&session);
TEEC_FinalizeContext(&context);

9.3 共享内存

REE 和 TEE 通过共享内存传递大量数据,避免每次拷贝:

c 复制代码 
TEEC_SharedMemory shm;
shm.size = 4096;
TEEC_RegisterSharedMemory(&context, &shm);

共享内存被映射为 non-secure,TEE 可以访问但 REE 也能读写,所以敏感数据进入共享内存前要加密或本身就是要送进 TEE 的明文。

9.4 Trusty IPC

Trusty 使用类 Unix 的 IPC:

  • /dev/trusty-ipc-vsockXX 设备
  • TA 注册 service name,CA 连接 service
  • 类 socket 通信模型

10. 安全启动链与 TEE

10.1 Verified Boot 链

复制代码 
Boot ROM (efuse root key 校验)
    ▼
SPL / XBL (bootloader)
    ▼
TEE OS (bootloader 校验后加载)
    ▼
Linux Kernel
    ▼
initramfs / system
    ▼
Android Framework

每一步校验下一步签名,失败则进入 recovery 或警告。

10.2 TEE 启动顺序

  1. Boot ROM 加载并校验 TEE firmware
  2. TEE OS 启动,初始化内存、驱动
  3. TEE OS 加载内置 TA(KeyMint、Gatekeeper 等)
  4. TEE OS 校验每个 TA 签名
  5. TEE 完成 provisioning 状态检查
  6. TEE 通知 REE 启动(通过 shared memory flag)
  7. REE 内核启动,TEE 服务可用

10.3 Verified Boot 状态传递

TEE 启动时把以下信息记录为 RootOfTrust:

  • verifiedBootKey(bootloader 的 hash)
  • deviceLocked(bootloader 是否锁定)
  • bootloaderStatus(ORANGE/YELLOW/GREEN/RED)

这些信息会被 KeyMint 写入 attestation 证书,服务器可据此判断设备是否 root。

11. 调试与日志

11.1 抓取 TEE 日志

高通平台
bash 复制代码 
# Trusty 日志(新平台)
adb shell cat /sys/kernel/debug/trusty-log/trusty.log

# 老平台 IPC 日志
adb shell cat /d/ipc_logging/dci_ctrl/log_cont
adb shell cat /d/ipc_logging/dci_smc_ctrl/log_cont

# QSEE 日志
adb shell cat /d/qseecom_log
adb shell cat /d/qsee_log
MTK 平台
bash 复制代码 
adb shell cat /proc/tee_log
adb shell cat /proc/tz_log
adb shell cat /sys/kernel/debug/tee_log
Trusty(通用)
bash 复制代码 
adb shell cat /sys/kernel/debug/trusty-log/trusty.log

11.2 检查 TEE 服务状态

bash 复制代码 
# KeyMint
adb shell dumpsys keystore2
adb shell dumpsys android.hardware.security.keymint.IKeyMintDevice/default
adb shell dumpsys android.hardware.security.keymint.IKeyMintDevice/strongbox

# Gatekeeper
adb shell dumpsys android.hardware.gatekeeper.IGatekeeper/default

# Fingerprint
adb shell dumpsys fingerprint

11.3 测试 TEE 功能

bash 复制代码 
# 验证 Keystore
adb shell vts -m VtsHalKeyMint_TargetTest

# 测试 attest
adb shell cmd keystore attest ...

# 测试指纹
adb shell cmd fingerprint ...

11.4 RPMB 状态检查

bash 复制代码 
# 找 RPMB 块设备
adb shell ls -l /dev/block/by-name/rpmb
adb shell ls -l /dev/block/*rpmb*

# 看是否能访问
adb shell dd if=/dev/block/mmcblk0rpmb of=/dev/null bs=512 count=1

# 看 dmesg 中 RPMB 报错
adb shell dmesg | grep -iE 'rpmb|emmc.*err|ufs.*err'

# 看分区表
adb shell cat /proc/partitions

11.5 检查 Provisioning 状态

bash 复制代码 
# TEE provisioning 状态(部分平台)
adb shell getprop persist.vendor.rpmb.state
adb shell getprop vendor.sys.rpmb.key.provisioned
adb shell getprop ro.vendor.keymaster.version

# Remote provisioning 状态(Android 13+)
adb shell dumpsys keystore2 | grep -i remprov

11.6 启用 verbose TEE 日志

eng/userdebug 版本:

bash 复制代码 
adb shell setprop persist.vendor.trusty.log.level 5
adb shell setprop persist.vendor.qsee.log.level 5
adb shell setprop vendor.trusty.log.enable 1
adb shell setprop persist.vendor.tee.log.enable 1

部分平台需要重启生效。

12. 常见故障排查

12.1 故障分类

故障 典型日志 影响
TEE 启动失败 Boot 卡在 TEE 阶段 设备无法开机
RPMB key 不匹配 INVALID_MAC (-49) Keystore、指纹、Play Integrity 失效
RPMB 读写失败 SECURE_HW_COMMUNICATION_FAILED (-50) 同上
TA 加载失败 classForName failed / TA not found 对应功能失效
Attestation 失败 attestation challenge failed Play Integrity 不通过
Provisioning 缺失 NOT PROVISIONED CORRECTLY 同 RPMB key 不匹配

12.2 Keystore 报 NOT PROVISIONED CORRECTLY

根本原因:TEE 内 Shared Secret 协商失败,通常是 RPMB 派生材料缺失或不匹配。

排查步骤:

  1. 抓 TEE 日志(见 §11.1)
  2. 看 dmesg 是否有 RPMB 错误(见 §11.4)
  3. 检查设备来源 :
    • 二手 / 维修过 → 极可能换过主板或 eMMC,RPMB key 不匹配
    • 工程机 / 裸板 → 未 provision,正常现象
    • 用户机突然出问题 → persist/RPMB 数据损坏
  4. 尝试重新 provision(需要工厂工具,普通用户不可用)

12.3 TA 加载失败

典型日志:

复制代码 
Failed to create service com.android.server.location.LocationPolicyManagerService$Lifecycle
java.lang.ClassNotFoundException

但这是 REE 端类找不到,不是 TEE TA。TEE TA 失败的日志形如:

复制代码 
TEEC_OpenSession failed: 0xffff0006
TA '<uuid>' not found

排查:

bash 复制代码 
# 列出已加载 TA(部分平台)
adb shell ls /vendor/lib64/tzapps/
adb shell ls /system/etc/tzapps/

# 看 TEE 日志中 TA 加载情况
adb shell cat /sys/kernel/debug/trusty-log/trusty.log | grep -i 'load.*TA'

12.4 指纹/人脸失效

排查:

  1. 是否 TEE 启动失败:dumpsys fingerprint 看 service 状态
  2. 模板是否丢失:/persist/data/fingerprint/ 是否存在
  3. TEE 日志看 fingerprint TA 是否报错
  4. 检查 gatekeeper 状态:dumpsys gatekeeper

12.5 Widevine L1 降级到 L3

排查:

bash 复制代码 
adb shell dumpsys media.drm
adb shell cmd media.drm provision

常见原因:

  • TEE 中 Widevine TA 损坏
  • Provisioning 数据丢失
  • 系统签名校验失败(ROM 被改)

12.6 Play Integrity 失败

典型现象:银行 App 提示设备不安全

排查:

bash 复制代码 
# 检查 attestation
adb shell cmd keystore attestation-challenge test123

# 看 bootloader 状态
adb shell getprop ro.boot.flash.locked
adb shell getprop ro.boot.verifiedbootstate
adb shell getprop ro.boot.vbmeta.device_state

如果 flash.locked=0 或 verifiedbootstate=orange,attestation 会失败,这是设计如此,解锁 BL 后无法恢复 attestation(除非 OEM 重新锁 BL,但这会 wipe 数据)。

12.7 性能问题

TEE 调用开销大,异常情况:

  • 一次 keymaster_op 应 <10ms,超过 100ms 多为 RPMB 慢
  • 指纹比对应 <500ms,超过多为 TEE 调度问题
  • Keystore 频繁访问可能 RPMB 限流
bash 复制代码 
# 看调用耗时
adb shell dumpsys keystore2 | grep -i duration

13. 附录:术语表

缩写 全称 说明
TEE Trusted Execution Environment 可信执行环境,secure world
REE Rich Execution Environment 富执行环境,主 OS
TA Trusted Application TEE 中的可信应用
CA Client Application REE 中调用 TA 的应用
GP GlobalPlatform TEE 标准组织
RoT Root of Trust 信任根
HRoT Hardware Root of Trust 硬件信任根(efuse/boot ROM)
SMC Secure Monitor Call 进入 TEE 的指令
HVC Hypervisor Call 进入 Hypervisor 的指令
EL Exception Level ARMv8 异常等级 EL0-EL3
TF-A Trusted Firmware-A ARM 维护的 EL3 固件
RPMB Replay Protected Memory Block eMMC/UFS 的安全分区
KeyMint (Android 11+) 替代 Keymaster 的 AIDL HAL
Keymaster (Android 6-10) 老的 HIDL 密钥 HAL
Gatekeeper (Android) PIN/密码校验
StrongBox (Android 14+) 独立安全芯片/独立 TEE 实例
Attestation 远程身份证明
Verified Boot 安全启动链
DRM Digital Rights Management 数字版权
Widevine Google DRM 方案 分 L1/L3
Play Integrity Google 完整性 API 替代 SafetyNet
SUI Secure User Interface TEE 直接渲染 UI
PUF Physically Unclonable Function 物理不可克隆函数
TRNG True Random Number Generator 真随机数发生器
TZASC TrustZone Address Space Controller 拦截总线对 secure 内存的访问
SMMU System Memory Management Unit 系统级 MMU
XPU (总线) 拦截对 secure 外设的访问
QSEE Qualcomm Secure Execution Environment 高通 TEE
Trusty Google TEE 开源
TEEGRIS Samsung TEE 三星自研
OP-TEE Linaro 开源 TEE 常用于 IoT

参考文档

文档结束。如需深入某一节(如 KeyMint 内部协议、TA 开发、RPMB 通信细节等),可基于此文档继续展开。

相关推荐
lemon_sjdk1 小时前
Spring 容器与 Bean 深度解析：从概念到实践
java·网络·spring·webflux
JckOLF04Z1 小时前
C#客户端的异步操作
开发语言·c#
过往的时光1 小时前
Spring Boot、Spring Cloud 与 Spring Cloud Alibaba 版本对照终极指南
java·spring boot·spring cloud
小比特-combat1 小时前
FreeRTOS任务通知
java·服务器·前端
曹牧1 小时前
C#：注释嵌套
开发语言·c#
snow@li1 小时前
SpringBoot：Payload统一响应包装/全景深入梳理
java·spring boot·后端
中国搜索直付通1 小时前
游戏车机端支付通道，会是下一个被低估的合规战场吗？
java·大数据·开发语言·人工智能·游戏
LccKyI1 小时前
C# 零基础学习 Day01｜基础概念梳理 + 思维导图总结
开发语言·笔记·学习·c#
开开心心_Every1 小时前
电脑文件搜索软件支持内容和拼音搜索
linux·服务器·人工智能·r语言·pdf·音视频·symfony
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02GitHub 镜像站点03国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）04AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路05Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费06微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？082026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片09历年考研数学一、数学二、数学三真题试卷及答案PDF102026 年 AI 大模型 & AI 编程工具实战全总结