When your app generates a cryptographic key in the Android Keystore, how does your server know that key is really protected by hardware, and not sitting in software on a compromised device? Android key attestation answers that. It produces a certificate chain, rooted in a Google attestation authority, that proves a key was generated in the device's secure hardware and describes the key's properties and the device's state. Your server can verify that chain and decide whether to trust the key. It is the tool for high-assurance flows where you need cryptographic proof of hardware backing, not just a claim. Here is what key attestation is, what it proves, and how to use it.
Short answer
Android key attestation lets you prove that a cryptographic key was generated in and is protected by the device's secure hardware, and obtain verifiable details about the key and device. Per Android, when you generate a Keystore key with an attestation challenge, the system produces a certificate chain, rooted in a Google attestation root, whose attestation extension describes the key's properties, such as whether it lives in the Trusted Execution Environment or a StrongBox secure element, and device state like verified boot. Your server validates the chain against the root, checks the challenge to prevent replay, and inspects the properties to decide whether to trust the key. It gives cryptographic evidence of hardware backing rather than an unverifiable claim, for high-assurance use cases.
What you should know
- Attestation proves hardware backing: that a key lives in secure hardware.
- It produces a certificate chain: rooted in a Google attestation root.
- The challenge prevents replay: a server-supplied nonce ties it to a request.
- It describes key and device properties: purpose, hardware level, boot state.
- Validate it server-side: the server checks the chain, challenge, and properties.
What is key attestation?
It is a mechanism for getting verifiable proof of a Keystore key's hardware protection and properties. The Android Keystore can store keys in secure hardware, the Trusted Execution Environment or a dedicated StrongBox secure element, so the key material is not exposed to the app or the operating system. Key attestation lets you prove that this is genuinely the case for a given key: when you generate the key and supply an attestation challenge, the system issues a certificate chain that includes an attestation certificate, and that certificate's attestation extension records facts about the key, how it is protected, what it can be used for, and facts about the device, such as its verified boot state and patch level. Because the chain is rooted in a Google attestation root, a server can validate it cryptographically and trust the recorded facts, rather than relying on the app's word. So attestation turns "this key is hardware-protected" from an unverifiable claim into something your backend can check.
What does attestation prove?
A set of properties about the key and the device, verifiably. The table lists the main ones.
| Property | What it tells you |
|---|---|
| Hardware backing | Whether the key is in the TEE or a StrongBox secure element |
| Key characteristics | The key's purposes, algorithm, and constraints |
| Challenge | A server nonce binding the attestation to a request |
| Verified boot state | Whether the device booted a verified OS |
| Root of trust | Chain anchored in a Google attestation root |
The central thing attestation proves is where the key lives: whether it is held in the Trusted Execution Environment, or in a StrongBox secure element, which is a stronger, dedicated hardware module, so your server can require a level of protection. It also records the key's own characteristics, its permitted purposes and constraints, so you can confirm the key is restricted as you intended. The attestation challenge, a nonce your server supplies, is embedded so the attestation cannot be replayed from a previous request. And the extension reports device state, including verified boot, giving a signal about the integrity of the device the key sits on. All of this is trustworthy because the certificate chain is anchored in a Google attestation root that the server validates.
How do you use it?
Generate the key with a challenge, then validate everything server-side. Have your server generate a random challenge and send it to the app, then generate the Keystore key requesting attestation with that challenge, which produces the attestation certificate chain. Send the chain to your server, and on the server do the real work: validate the certificate chain up to the Google attestation root so you know it is genuine, confirm the embedded challenge matches the one you issued so the attestation is fresh and not replayed, check certificate revocation status, and then inspect the attestation extension to confirm the key's properties meet your requirements, hardware backing at the level you need, the right key purposes, and acceptable device state. Only then trust the key for your high-assurance flow. Treat attestation as one strong signal within your security design rather than the whole of it, and account for devices that do not support the highest protection levels like StrongBox. The principle is that the app produces the attestation but the server decides what it means, validating the chain, the challenge, and the properties before relying on the key.
What to watch out for
The first trap is doing the attestation but not validating it properly on the server, accepting the chain without checking the root, the challenge, and the properties, which defeats the purpose. The second is omitting the challenge or reusing one, allowing replay; always use a fresh server-supplied challenge. The third is assuming every device offers StrongBox-level protection, when support varies, so define your minimum and handle devices that fall short. Key attestation is a runtime protocol between app and server, while a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS, assesses how your app handles keys and uses the Keystore, the cryptographic surface attestation builds on, with the chain validation implemented on your backend.
What to take away
- Android key attestation proves a Keystore key was generated in and is protected by secure hardware, via a certificate chain rooted in a Google attestation root that describes the key and device.
- It records hardware backing (TEE or StrongBox), key characteristics, verified boot state, and an embedded challenge that prevents replay.
- Use it by generating the key with a server-supplied challenge, then validating the chain, challenge, revocation, and properties on the server before trusting the key.
- Treat attestation as one strong signal, handle varying hardware support, and use a pre-submission scan such as PTKD.com to assess your app's key and Keystore handling.
