Breaking Chains: Hacking Android Key Attestation

Breaking Chains: Hacking Android Key Attestation

Speaker: Alex — Senior Red Team Engineer, Amazon

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=RUHDSokGhLE

Reading Time: ~9 minutes

Type: Briefing

TL;DR

Android Key Attestation, intended to guarantee that cryptographic keys live inside tamper-resistant hardware, contains a cluster of PKI implementation flaws — many rooted in a Google-vended reference library that went without a formal CVE for years. Researcher Alex discovered that the library's certificate extension validation is broken in ways that allow a software key stored in plain memory to be falsely presented as hardware-backed, effectively defeating bot-fraud countermeasures. A real-world deployment saw bot traffic fall from 30% to 2% once the library was fixed.

Introduction

Bot fraud thrives on scale: automated clients impersonating real users cost companies revenue and degrade service quality for legitimate customers. One increasingly popular countermeasure is Android Key Attestation — a hardware-rooted mechanism that proves a cryptographic key was generated and stored inside a device's Trusted Execution Environment (TEE) or Secure Element (SE). If attestation works correctly, a bot running in a cloud VM cannot forge the signature that proves it is a genuine Android device.

Amazon red team engineer Alex came to Black Hat with the opposing finding: attestation is frequently misconfigured, and the official Google library that developers are directed to use contains fundamental flaws that allow that guarantee to be bypassed entirely — without breaking into the hardware at all.

What Android Key Attestation Actually Does

Android Key Attestation is often confused with app attestation (the SafetyNet or Play Integrity API path), but the two are distinct. App attestation asks Google's servers whether the installed APK is the genuine Play Store version; key attestation asks the device's secure hardware whether a specific cryptographic key pair was created and stored there.

▶ Watch: How Android Key Attestation Works (04:00)

The process works through an X.509 certificate chain. Google distributes signing key pairs to manufacturers (Samsung, etc.) at factory time; those keys are injected into the device's key box. When a developer calls the KeyStore API, the device generates a key pair inside the TEE or SE and produces a certificate chain rooted in a Google-signed certificate. The leaf certificate carries a custom OID extension that encodes attestation data: whether the key lives in the TEE or SE, whether the bootloader is locked, patch level, and so on. A back-end server validates this chain and parses the attestation extension.

A compelling fraud signal also lives in the intermediate certificate: a counter that increments every time a device mints a new certificate chain, letting defenders detect a single device issuing thousands of chains for bot accounts.

Three Common PKI Failure Modes

Alex identifies three classes of PKI implementation failures that allow attestation bypass, two familiar to anyone who has audited HTTPS PKI and one unique to the Android ecosystem.

▶ Watch: PKI Failure Modes Overview (14:01)

1. Missing chain-of-trust validation. If the back-end does not verify that the chain is signed all the way back to a Google root, an attacker can generate an EC key pair using OpenSSL, embed the public key in a forged leaf certificate, craft a fake attestation OID extension claiming secure-element storage, and send it. No hardware required.

2. Certificate revocation list (CRL) not checked. When a manufacturer's key box leaks — an event Alex notes "happens way more than you would hope" — Google adds those keys to a CRL. Developers must fetch and check this list. The compromised key boxes are publicly available in Telegram channels and custom-ROM communities; using one against an unprotected endpoint is trivial.

3. Hard-coded test certificates in production. Because testing key attestation end-to-end requires a physical attested device, developers frequently allow-list synthetic certificates in pre-production environments. When those configurations bleed into production, the attestation check becomes trivially bypassable with a statically known certificate.

The Certificate Extension Attack: A Library-Level Bug

The most technically interesting finding centers on the basic constraints extension — specifically, the cA boolean flag that determines whether a certificate may sign child certificates.

▶ Watch: Certificate Extension Attack Explained (20:02)

The attack exploits a certificate chain extension technique: an attacker uses the legitimate TEE-backed key pair on the device to sign a new leaf certificate whose public key corresponds to an off-device EC key pair under attacker control. The forged leaf certificate is appended to the real chain and sent to the back-end. If the validator parses the attestation extension from the last certificate in the chain rather than enforcing that the legitimate leaf cannot act as a CA, the forged certificate's attestation data — claiming anything the attacker wants — is accepted.

Alex demonstrates the exploit using a debug APK from the Android custom-ROM community, which allows calling the KeyStore API programmatically to build and export modified chains. With the extension attack working, the researcher could interact with sensitive back-end APIs from a plain Python script running on a laptop, with no physical Android device involved.

Root Cause: The Official Google Library Is Broken

When Alex examined why this attack worked against a patched target, the answer pointed at the Android Key Attestation reference library published to GitHub by Google in December 2016 and linked from official developer documentation.

▶ Watch: Root Cause Analysis — the Google Library (26:03)

A diff between an older version of the library and a 2023 update revealed a partial patch: the library moved from accepting just the leaf certificate to accepting the whole chain, then parsing from root to leaf to grab the first attestation. This ordering trick was intended to prevent tacked-on forged leaves from being read — but it does not actually check the cA extension flag.

More critically, the library assumes the chain will always arrive in leaf-first order, but this is never enforced. Implementations that store or pass the chain in root-first order — a completely reasonable choice, given that root-first is a common convention — will hand the attacker control. Because the client sends the chain, the attacker controls the ordering. Flipping the chain is enough to bypass the library's heuristic protection.

The library was never published to a central package repository (Maven, etc.), making it impossible to track through standard dependency management. There are no formal releases and no CVE was ever assigned, despite Alex's three separate disclosure attempts to Google. Google's response was that this is not an Android issue because it is not Android source code. After escalation to the open-source VRP and eventual deprecation notice, the library now carries a README warning — but Google's own developer documentation still links to the deprecated path. Developers following the official guide encounter a deprecated library, must find a buried link to a replacement, and discover that the replacement is still actively being developed.

Disclosure Timeline and Current State

| Date | Event |

|---|---|

| December 2016 | Key Attestation library published to GitHub, marked production-ready |

| 2023 | Partial certificate extension attack patch committed — no CVE |

| September 2024 | Alex reports three issues to Google |

| November 2024 | Google declines to fix; announces deprecation instead |

| April 2025 | New replacement library released |

| June 2025 | Deprecated library README updated; repository locked to read-only |

Any application that implemented Android Key Attestation using the official library between 2016 and 2023 is implicitly vulnerable to the certificate extension attack. Post-2023 implementations may or may not be protected, depending on whether developers kept up with uncommitted GitHub changes.

Key Attester: New Open-Source Testing Tool

Alex released Key Attester at the time of the talk — a library that programmatically constructs the various forged X.509 certificate chains described in the research and submits them against a target implementation. It is designed so that developers can validate their own attestation logic against all three PKI failure modes. Alex recommends the WebAuthn4J library as a well-maintained alternative for developers who want a production-quality attestation parser supporting all attestation types including FIDO2 and WebAuthn.

▶ Watch: Results and Recommendations (36:04)

The research target that prompted the investigation saw bot traffic drop from 30% to 2% after remediating the identified issues — evidence that properly implemented key attestation is a meaningful anti-fraud control, even if the current library ecosystem is fragmented.

Notable Quotes

"If you implemented Android Key Attestation from 2016 to 2023, you are implicitly vulnerable to a certificate extension attack if you use the library that the developer guidance tells you to."

— Alex [34:04]

"Google, join a few Telegram channels and get into the custom ROM hacking community to find the latest leaked key box."

— Alex, on how trivially attackers can find CRL-revoked keys [18:02]

"We actually saw bot traffic drop from thirty percent to two percent, and it's been holding pretty solid right at that level since then."

— Alex [36:04]

"There is no way to keep up with main unless you are manually going to GitHub every day and checking to see if someone's pushed a new commit."

— Alex on the library's lack of versioned releases [30:03]

Key Takeaways

• Validate the full X.509 chain properly. Check the cA basic constraints flag and key usage extensions. Do not rely on certificate ordering as a security control — clients control the ordering.
• Enforce certificate revocation. Google maintains a CRL of leaked manufacturer key boxes. Failing to check it turns a well-known public dataset of compromised keys into a bypass.
• Do not allow-list test certificates in production. Hard-coded certificates designed for integration testing regularly escape into production environments.
• Audit your dependency versions. The official Google attestation library has no versioned releases and no package registry presence. Only manual GitHub tracking reveals security-relevant commits.
• Consider WebAuthn4J or a roll-your-own PKIX approach. The current state of available Android Key Attestation libraries is fragmented. WebAuthn4J is a battle-tested open-source alternative supporting multiple attestation types.
• Use Key Attester. Alex's new open-source tool automates testing all three PKI failure classes against your implementation.

Slides were not listed as available for this talk.