LDPlayer 14 TEE / AndroidKeyStore Attestation Test Report

1. Executive Summary

We tested AndroidKeyStore Key Attestation on an LDPlayer 14 instance named index3.

The result is clear:

• LDPlayer 14 can create AndroidKeyStore keys.
• LDPlayer 14 can generate an attestation certificate chain with a challenge.
• LDPlayer 14 can use the AndroidKeyStore private key to sign application data.
• However, the generated key is not protected by real TEE or StrongBox hardware.
• The returned certificate chain is rooted at Android Keystore Software Attestation Root.
• The attestation extension reports:
  • attestation.securityLevel = Software
  • keymaster.securityLevel = Software
  • teeEnforced.length = 0

Therefore, AndroidKeyStore signatures generated on LDPlayer 14 only prove that a software-level AndroidKeyStore key signed the data. They do not prove that the private key is protected by a real hardware TEE or StrongBox.

2. Test Environment

| Item | Value | |---|---| | Emulator | LDPlayer 14 | | Instance | index3 | | ADB device | 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. Test Artifacts

| File | Description | |---|---| | D:\LD14-2\tee_probe\TEEProbe.apk | AndroidKeyStore attestation probe APK | | D:\LD14-2\tee_probe\certs\cert0.der | Leaf attestation certificate | | D:\LD14-2\tee_probe\certs\cert1.der | Software attestation intermediate certificate | | D:\LD14-2\tee_probe\certs\cert2.der | Software attestation root certificate | | D:\LD14-2\tee_probe\parse_attestation.py | PC-side parser for the Android Key Attestation extension |

4. Probe Flow

The probe performed the following steps inside an Android app process:

1. Use AndroidKeyStore from the app process.
2. Generate a temporary EC / secp256r1 key pair.
3. Set the attestation challenge:
   codex-challenge-index3-20260711
4. Call generateKeyPair().
5. Read getCertificateChain(alias).
6. Export cert0/cert1/cert2 as DER files.
7. Parse the Android Key Attestation extension in the leaf certificate:
   OID = 1.3.6.1.4.1.11129.2.1.17

5. Raw Probe Result Summary

The probe successfully generated an AndroidKeyStore key:

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

The returned certificate chain is a software attestation chain:

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. Parsed Attestation Result

Parser command:

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

Output summary:

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

The key indicators are:

attestation_security_level = Software
keymaster_security_level   = Software
tee_enforced_length        = 0

These values confirm that the key is not a TEE-backed or StrongBox-backed hardware key.

7. Impact on the Registration Flow

The observed registration fields appear to follow this structure:

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))

This proves only that:

The AndroidKeyStore private key corresponding to keyHash signed data.

It does not prove that:

The private key is protected by real TEE or StrongBox hardware.

If the server only validates the keyHash + data + signature relationship, but does not validate the hardware attestation state of the certificate chain associated with keyHash, LDPlayer 14 can produce a well-formed software-backed signature.

8. Risk Assessment

If registration succeeds on LDPlayer 14 despite a claimed hardware TEE requirement, common causes include:

• The server validates only the signature, not the attestation certificate chain.
• The server accepts Android Keystore Software Attestation Root.
• The server does not reject attestationSecurityLevel = Software.
• The server does not reject keymasterSecurityLevel = Software.
• The server does not inspect teeEnforced or hardwareEnforced.
• Play Integrity, SafetyNet, or TEE attestation results are used only as risk signals, not as hard registration blockers.
• Missing values such as unknown, empty strings, or fallback values are still accepted.

9. Recommended Server-Side Enforcement

If the business requirement is to allow only real hardware-backed TEE or StrongBox keys, the server should enforce at least the following checks:

1. The attestation certificate chain must be valid and trusted.
2. The attestation challenge must match the server-issued nonce for this registration session.
3. attestationSecurityLevel must be TrustedEnvironment or StrongBox.
4. keymasterSecurityLevel must be TrustedEnvironment or StrongBox.
5. Software security level must be rejected.
6. Android Keystore Software Attestation Root must be rejected.
7. Critical authorization fields must be present in teeEnforced / hardwareEnforced.
8. keyHash must be bound to a previously verified hardware attestation certificate chain.
9. The registration endpoint must not fall back to allow registration when TEE, Play Integrity, or SafetyNet checks fail.

10. Final Conclusion

LDPlayer 14 does not provide a real mobile SoC TEE or StrongBox environment. The tested instance returned Software Attestation:

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

LDPlayer 14 can perform AndroidKeyStore software signing, but it cannot provide a real TEE-backed hardware signature proof.

If registration still succeeds on LDPlayer 14 after enabling a claimed TEE hardware-signature check, the most likely issue is that the server does not enforce hardware attestation. It may only be validating the signature/data/keyHash relationship.