fbdata
HomeCartOrder QueryArticlesAPI Docs

返回文章
2026年7月22日

LDPlayer 14 TEE / AndroidKeyStore Attestation 测试报告

LDPlayer 14 TEE / AndroidKeyStore Attestation 测试报告

LDPlayer 14 TEE / AndroidKeyStore Attestation 测试报告

1. 结论

本次在雷电模拟器 LDPlayer 14 的 index3 实例上测试 AndroidKeyStore Key Attestation，结论如下：

  • 雷电14 可以创建 AndroidKeyStore 密钥。
  • 雷电14 可以对指定 challenge 生成 attestation 证书链。
  • 雷电14 可以用 AndroidKeyStore 私钥对业务 requestDataBytes 进行签名。
  • 但该密钥不是 TEE / StrongBox 硬件保护密钥。
  • 证书链明确指向 Android Keystore Software Attestation Root。
  • attestation 扩展字段显示：
    • attestation.securityLevel = Software
    • keymaster.securityLevel = Software
    • teeEnforced.length = 0

因此，雷电14上的 AndroidKeyStore 签名只能证明“某个软件级 AndroidKeyStore 私钥签了数据”，不能证明“该私钥位于真实 TEE/StrongBox 硬件中”。

2. 测试环境

| 项目 | 值 | |---|---| | 模拟器 | LDPlayer 14 / 雷电14 | | 实例 | index3 | | ADB 设备 | emulator-5560 | | Android SDK | 34 | | ABI | x86_64 | | Build fingerprint | OnePlus/graceltexx/graceltexx:14/UQ1A.240205.06291218/dengli.20260629.121859:userdebug/release-keys | | Manufacturer | XIAOMI | | Model | 2509FPN0BC |

3. 探针文件

| 文件 | 说明 | |---|---| | D:\LD14-2\tee_probe\TEEProbe.apk | APK 版 AndroidKeyStore attestation 探针 | | D:\LD14-2\tee_probe\certs\cert0.der | leaf attestation certificate | | D:\LD14-2\tee_probe\certs\cert1.der | software intermediate certificate | | D:\LD14-2\tee_probe\certs\cert2.der | software root certificate | | D:\LD14-2\tee_probe\parse_attestation.py | PC 侧 attestation 扩展解析脚本 |

4. 探针流程

探针执行了以下动作：

1. 在 App 进程中调用 AndroidKeyStore。
2. 使用 EC / secp256r1 生成临时密钥。
3. 设置 attestation challenge：
   codex-challenge-index3-20260711
4. 调用 generateKeyPair()。
5. 读取 getCertificateChain(alias)。
6. 导出 cert0/cert1/cert2。
7. 解析 leaf 证书中的 Android Key Attestation 扩展：
   OID = 1.3.6.1.4.1.11129.2.1.17

5. 原始运行结果摘要

探针在雷电14上成功生成 AndroidKeyStore key：

provider.AndroidKeyStore.present=true
provider=AndroidKeyStoreBCWorkaround
provider=AndroidKeyStore
step=generate_keypair_with_attestation_challenge
generateKeyPair=OK
certificateChain.length=3

证书链显示为软件 attestation 链：

cert[0].subject=CN=Android Keystore Key
cert[0].issuer=CN=Android Keystore Software Attestation Intermediate,OU=Android,O=Google\, Inc.,ST=California,C=US

cert[1].subject=CN=Android Keystore Software Attestation Intermediate,OU=Android,O=Google\, Inc.,ST=California,C=US
cert[1].issuer=CN=Android Keystore Software Attestation Root,OU=Android,O=Google\, Inc.,L=Mountain View,ST=California,C=US

cert[2].subject=CN=Android Keystore Software Attestation Root,OU=Android,O=Google\, Inc.,L=Mountain View,ST=California,C=US
cert[2].issuer=CN=Android Keystore Software Attestation Root,OU=Android,O=Google\, Inc.,L=Mountain View,ST=California,C=US

6. PC 侧解析结果

解析命令：

python D:\LD14-2\tee_probe\parse_attestation.py D:\LD14-2\tee_probe\certs\cert0.der --challenge codex-challenge-index3-20260711

输出摘要：

subject: CN=Android Keystore Key
issuer: CN=Android Keystore Software Attestation Intermediate,OU=Android,O=Google\, Inc.,ST=California,C=US
cert_sha256: aa2bbef5bf3627b69fe55b27eefb643f6008c435a77ecf028932812afe6f2c4e
attestation_version: 2
attestation_security_level: Software
keymaster_version: 3
keymaster_security_level: Software
challenge_sha256: 04bee829c9b0e35aa2fe597339ce1988a20b9f7cb3b0f728fefd38b1bca03cf1
challenge_matches_expected: True
unique_id_length: 0
software_enforced_length: 244
tee_enforced_length: 0

关键判断：

attestation_security_level = Software
keymaster_security_level   = Software
tee_enforced_length        = 0

这三个字段已经足以说明当前密钥不是 TEE / StrongBox 硬件密钥。

7. 对注册链路的含义

当前分析到的注册字段关系：

requestDataBytes = UTF8(
  {"username":"<contactpoint>","challenge_nonce":"<challenge_nonce>"}
)

attestation_result.data
= Base64(requestDataBytes)

attestation_result.signature
= Base64(AndroidKeyStore.sign(requestDataBytes))

attestation_result.keyHash
= lowercase_hex(SHA256(AndroidKeyStore certificate publicKey encoded bytes))

这组字段可以证明：

keyHash 对应的 AndroidKeyStore 私钥签过 data。

但不能单独证明：

该私钥位于真实 TEE / StrongBox 硬件中。

如果服务端只校验 keyHash + data + signature 的闭环，而不校验 keyHash 对应证书链的硬件 attestation 状态，则雷电14的软件级 AndroidKeyStore 也可以构造出格式正确的参数。

8. 风险判断

如果雷电14可以注册成功，常见原因包括：

  • 服务端只校验签名，没有校验 attestation 证书链。
  • 服务端接受 Android Keystore Software Attestation Root。
  • 服务端没有拒绝 attestationSecurityLevel = Software。
  • 服务端没有拒绝 keymasterSecurityLevel = Software。
  • 服务端没有校验 teeEnforced / hardwareEnforced。
  • 服务端把 Play Integrity / SafetyNet / TEE attestation 只作为风控参考，没有作为硬拦截条件。
  • challenge 缺失、unknown、空串或失败 fallback 仍允许注册。

9. 服务端应强制校验的条件

若业务要求必须是真实 TEE / StrongBox，应至少强制校验：

1. attestation certificate chain 必须可信。
2. challenge 必须等于服务端本次下发的 nonce。
3. attestationSecurityLevel 必须为 TrustedEnvironment 或 StrongBox。
4. keymasterSecurityLevel 必须为 TrustedEnvironment 或 StrongBox。
5. 必须拒绝 Software。
6. 必须拒绝 Android Keystore Software Attestation Root。
7. teeEnforced / hardwareEnforced 中必须包含关键授权字段。
8. keyHash 必须绑定到已验证通过的硬件 attestation 证书链。
9. 注册接口不得在 TEE/Play Integrity/SafetyNet 失败时 fallback 放行。

10. 最终结论

雷电14不具备真实手机 SoC 的 TEE / StrongBox 硬件环境。本次探针显示它返回的是 Software Attestation：

root = Android Keystore Software Attestation Root
attestation.securityLevel = Software
keymaster.securityLevel = Software
teeEnforced.length = 0

因此，雷电14上的 AndroidKeyStore 可以完成软件级签名，但不能提供真实 TEE 硬件签名证明。

如果业务声称“开启 TEE 硬件签名校验”后雷电14仍可注册，则优先排查服务端是否真正强制校验硬件 attestation，而不是只校验 signature/data/keyHash。