1. Attestation 是什么

Android attestation 本质上是由安全硬件为某个对象签发“证明材料”，让远端服务器判断：

这个 key 是不是在安全硬件里生成的；
设备启动状态是否可信；
系统版本、补丁级别是否符合要求；
该 key 是否需要用户认证；
证书链是否能追溯到 Google/厂商可信根。

Android 中最常见的是 Key Attestation，即对 Keystore/KeyMint 生成的密钥进行证明。Android 8.0 及以上设备支持 Key Attestation，服务器可以通过它验证密钥属性、密钥保护位置以及设备状态等信息。

2. 相关组件

典型链路如下：

App
 └─ Android Keystore API / KeyPairGenerator / KeyGenParameterSpec
     └─ Keystore2
         └─ KeyMint HAL / Keymaster HAL
             └─ TEE / StrongBox / Secure Element
                 └─ Attestation Key 签发证书链

关键组件：

组件	作用
App	请求生成 key，并设置 attestation challenge
Android Keystore / Keystore2	管理密钥、调用 KeyMint
KeyMint / Keymaster	硬件密钥管理 HAL
TEE / StrongBox	保护密钥和执行签名
Attestation Key	用来签发“被证明 key”的证书
服务器	验证证书链、扩展字段、challenge、设备状态

3. 基本流程

典型 Key Attestation 流程：

1. App 向服务器请求 challenge
2. 服务器生成随机 nonce/challenge
3. App 调用 Keystore 生成密钥，并把 challenge 放入 KeyGenParameterSpec
4. Keystore2 调用 KeyMint/TEE 生成密钥
5. 安全硬件生成 attestation certificate chain
6. App 把证书链发给服务器
7. 服务器验证：
   • 证书链是否合法
   • 根证书是否可信
   • challenge 是否匹配
   • key 是否 hardware-backed
   • verified boot 状态是否可信
   • OS/security patch 是否符合要求

challenge 很重要。它用于防止重放攻击。如果服务端不检查 challenge，攻击者可以拿旧证书链伪造当前设备状态。

4. 证书链结构

一般证书链类似：

Leaf Certificate：被证明的应用密钥
Intermediate Certificate：中间 CA
Root Certificate：Google/厂商可信根

Leaf certificate 中有 Android attestation extension，里面包含 Android 特有字段。服务器真正关心的不是普通 X.509 字段，而是这个扩展中的 attestation 信息。

5. Attestation 扩展字段重点

常见字段可以分为几类。

5.1 密钥属性

例如：

purpose
algorithm
keySize
digest
padding
ecCurve
origin
rollbackResistance

它们用于说明这个 key 是干什么用的、算法是什么、是否由硬件生成、是否支持回滚保护等。

重点看：

origin = generated

如果 key 是在安全硬件中生成的，可信度更高。

5.2 安全等级

常见字段：

attestationSecurityLevel
keymasterSecurityLevel

可能值包括：

Software
TrustedEnvironment
StrongBox

含义：

值	含义
Software	软件实现，可信度较低
TrustedEnvironment	TEE 中实现
StrongBox	独立安全芯片/安全模块中实现，安全级别更高

工程上经常会判断：

keymasterSecurityLevel == TrustedEnvironment
或
keymasterSecurityLevel == StrongBox

如果测试要求 StrongBox，但设备不支持，就可能出现类似：

HARDWARE_TYPE_UNAVAILABLE
StrongBox unavailable

5.3 用户认证相关字段

例如：

userAuthType
authTimeout
noAuthRequired
userSecureId

这些字段说明这个 key 是否必须在用户解锁、指纹、人脸、密码验证后才能使用。

例如：

setUserAuthenticationRequired(true)
setUserAuthenticationValidityDurationSeconds(30)

对应到 attestation 中，服务器可以检查 key 是否真的绑定了用户认证条件。

5.4 设备状态字段

重点字段包括：

verifiedBootState
verifiedBootKey
deviceLocked
verifiedBootHash
osVersion
osPatchLevel
vendorPatchLevel
bootPatchLevel

这些字段用于判断设备启动链是否可信。

常见 verified boot 状态：

状态	含义
Verified	启动链完整，设备处于绿色状态
SelfSigned	使用自签名 boot key
Unverified	未验证启动
Failed	验证失败

服务器一般会拒绝：

deviceLocked = false
verifiedBootState != Verified
patchLevel 过低

6. Factory Provisioning 与 RKP

早期 Android 设备通常在工厂阶段预置 attestation key。设备出厂时，安全硬件中已经有 Google/厂商签发的 attestation key 和证书链。

后来 Android 引入 Remote Key Provisioning，RKP。RKP 从 Android 12 开始进入 AOSP，Android 14 又把相关能力做成 com.android.rkpd Mainline APEX，以便通过模块更新改进服务。

RKP 的目的：

减少长期固定 attestation key 的隐私风险
降低密钥泄露后的影响
让设备在出厂后也能获取新的 attestation 证书
提供更短生命周期的 per-app ECDSA P-256 attestation certificate

官方文档说明，RKP 会为现场设备提供 per-app、ECDSA P-256 的 attestation certificates，并且这些证书比工厂预置证书生命周期更短。Android 15 要求所有设备实现 RKP。

7. RKP 大致流程

简化理解：

1. 设备安全硬件生成 BCC / DICE 相关证明材料
2. rkpd 向 Google RKP backend 请求证书
3. 后端验证设备身份和硬件证明
4. 后端下发短期 attestation certificate
5. Keystore2 / KeyMint 使用这些证书给应用 key 做 attestation

Android 14 后，RKP 相关逻辑主要在：

com.android.rkpd APEX
Remote Key Provisioning Daemon
Keystore2
KeyMint HAL

8. DICE 与 Attestation

DICE 是 Android 中用于增强设备身份和完整性证明的安全机制。官方说明 DICE 可以为每台设备创建唯一的加密身份，用于强设备证明和安全通信场景。

可以简化理解为：

Boot ROM / Bootloader / Firmware / OS
       ↓
每一层测量下一层
       ↓
派生出设备身份和证明链
       ↓
供 RKP / attestation 使用

DICE 更偏底层启动链身份，Key Attestation 更偏应用密钥证明。

9. 服务器验证时应该检查什么

服务端不能只看“证书链 valid”。至少要检查：

1. 证书链是否能追溯到可信 root
2. root 是否在当前可信根列表中
3. challenge 是否等于服务器刚下发的 nonce
4. attestationSecurityLevel 是否符合要求
5. keymasterSecurityLevel 是否符合要求
6. verifiedBootState 是否为 Verified
7. deviceLocked 是否为 true
8. osPatchLevel / vendorPatchLevel 是否满足最低要求
9. key purpose / algorithm / digest / padding 是否符合业务预期
10. applicationId / package 信息是否符合预期

尤其注意：证书链合法不等于设备可信。证书链合法只能说明这个证明材料确实由某个可信 attestation key 签出，仍然要继续检查 extension 里的设备状态和 key 属性。

10. 和 Play Integrity API 的关系

Play Integrity API 是更上层的完整性判断接口。Google 官方建议应用优先使用 Play Integrity API 来获得硬件支持的 Android platform key attestation 能力；如果开发者直接实现 Key Attestation，则需要自己处理底层证书链、root 轮换、兼容性问题等。

简单区分：

功能	面向对象	典型用途
Key Attestation	密钥证明	证明某个 key 来自安全硬件
Device Attestation	设备完整性	判断设备是否可信
Play Integrity API	应用/设备/账号风险判断	反作弊、反篡改、风控
RKP	attestation key 供应机制	给设备动态下发短期证明证书

11. 常见问题

11.1 Certificate chain is valid, but does not have production root

这类问题通常表示：

证书链本身能验证
但 root 不在测试期望的 production root 列表中

可能原因：

使用了测试 root
使用了非 Google production root
设备 attestation key 配置错误
CTS/GTS 期望 root 未更新
RKP root 轮换导致服务端/测试端未适配

11.2 StrongBox unavailable

常见原因：

设备本身没有 StrongBox
VINTF manifest 未声明 StrongBox KeyMint
feature flag 未配置
HAL 返回 HARDWARE_TYPE_UNAVAILABLE
测试误以为设备支持 StrongBox

判断方向：

adb shell pm list features | grep strongbox
adb shell getprop | grep strongbox
adb shell lshal | grep keymint
adb shell dumpsys keystore2

11.3 Attestation challenge mismatch

一般是：

服务端 nonce 没有正确传入 KeyGenParameterSpec
App 复用了旧证书链
服务端验证错了请求上下文
Base64/编码处理有问题

12. 一句话总结

Android attestation 是 Android 安全体系中用于“远程证明”的核心能力：它通过 Keystore/KeyMint/TEE/StrongBox/RKP 等组件，把设备启动状态、密钥来源、系统补丁、安全等级等信息封装进证书链，让服务器可以判断“这个 key 和这台设备是否可信”。