Verify hardware-backed key pairs with key attestation
Stay organized with collections
Save and categorize content based on your preferences.
Key attestation gives you more confidence that the keys you use in your app
are stored in a device's hardware-backed keystore. The following sections
describe how to verify the properties of hardware-backed keys and how to
interpret the attestation certificates' extension data.
Before you begin: ensure your device supports hardware-level key attestation
Before you verify the properties of a device's hardware-backed keys in a
production-level environment, make sure that the device supports
hardware-level key attestation. To do so, check that the attestation certificate
chain contains a root certificate that is signed with the Google attestation root
key and that the attestationSecurityLevel element within the
key description
data structure is set to the TrustedEnvironment security level or
to the StrongBox security level.
In addition, it's important to verify the signatures in the certificate chain
and to confirm that none of the keys in the chain have been revoked by checking
the certificate revocation status list.
Unless all are valid and the root is the Google root key, don't
fully trust the attestation.
Retrieve and verify a hardware-backed key pair
During key attestation, you specify the alias of a key pair and retrieve its
certificate chain, which you can use to verify the properties of that key pair.
If the device supports hardware-level key attestation, the root certificate
within this chain is signed using an attestation root key that is securely
provisioned to the device's hardware-backed keystore.
To implement key attestation, complete the following steps:
Use a KeyStore object's
getCertificateChain()
method to get a reference to the chain of X.509 certificates associated with
the hardware-backed keystore.
Send the certificates to a separate server that you trust for validation.
Caution: Don't complete the following validation process
on the same device. If the Android system on that device
is compromised, that could cause the validation process to
trust something that is untrustworthy.
Obtain a reference to the X.509 certificate chain parsing and validation
library that is most appropriate for your toolset. Verify that the root
public certificate is trustworthy and that each certificate signs
the next certificate in the chain.
Check each certificate's revocation status
to ensure that none of the certificates have been revoked.
Optionally, inspect the provisioning information certificate extension that
is only present in newer certificate chains.
Obtain a reference to the CBOR parser library that is most appropriate for
your toolset. Find the nearest certificate to the root that contains the
provisioning information certificate extension. Use the parser to extract the provisioning
information certificate extension data from that certificate.
Obtain a reference to the ASN.1 parser library that is most appropriate
for your toolset. Find the nearest certificate to the root that contains
the
key attestation certificate extension. If the provisioning information
certificate extension was present, the key attestation certificate
extension must be in the immediately subsequent certificate. Use the
parser to extract the key attestation certificate extension data from
that certificate.
Caution: Don't assume that the key attestation
certificate extension is in the leaf certificate of the chain. Only the
first occurrence of the extension in the chain can be trusted. Any further
instances of the extension have not been issued by the secure hardware and
might have been issued by an attacker extending the chain while attempting
to create fake attestations for untrusted keys.
The Key
Attestation sample uses the ASN.1 parser from Bouncy Castle to extract an
attestation certificate's extension data. You can use this sample as a
reference for creating your own parser.
Check the extension data that you've retrieved in the previous steps for
consistency and compare with the set of values that you expect the
hardware-backed key to contain.
Root certificates
The trustworthiness of the attestation depends on the root certificate of the chain. Android
devices that have passed the testing required to have the Google suite of apps, including
Google Play, and which launched with Android 7.0 (API level 24) or higher should use attestation
keys signed by the Google Hardware Attestation Root certificate. Note that attestation was not
required until Android 8.0 (API level 26).
The set of valid root certificates may be downloaded as a
JSON-formatted array.
Root Certificates
The following two root certificates should be used as trust anchors when verifying a key
attestation certificate chain.
If the root certificate in the attestation chain you receive contains this public key and
none of the certificates in the chain have been revoked, you
know that:
Your key is in hardware that Google believes to be secure; and
It has the properties described in the attestation certificate.
If the attestation chain has any other root public key, then Google does not make any claims
about the security of the hardware. This doesn't mean that your key is compromised, only that the
attestation doesn't prove that the key is in secure hardware. Adjust your
security assumptions accordingly.
If the root certificate doesn't contain the public key on this page, there are two likely reasons:
Most likely, the device launched with an Android version less than 7.0 and it doesn't support
hardware attestation. In this case, Android has a software implementation of attestation that
produces the same sort of attestation certificate, but signed with a key
hardcoded in Android source code. Because this signing key isn't a secret, the
attestation might have been created by an attacker pretending to provide secure hardware.
The other likely reason is that the device isn't a Google Play device. In that case, the device
maker is free to create their own root certificate and to define the meaning of their
attestation data. Refer to the device maker's documentation. Note that Google isn't aware of
any device makers who have done this.
Hardware attestation root certificate rotation
Google is introducing a new root certificate for Android Key Attestation. This change
enhances the security and reliability of the attestation process for sensitive applications.
A new root key has been generated for Android Key Attestation (KeyMint). The new root is an ECDSA
P-384 key.
What you need to do
If your app relies on Android Key Attestation, add the new root certificate to your trust
stores by March 31, 2026. Download both the new and old certificates from
https://android.googleapis.com/attestation/root
Devices that use Remote Key Provisioning (RKP)
will begin receiving certificates rooted in this new certificate in February 2026.
RKP-enabled devices will exclusively use the new root by April 10, 2026.
Update your attestation processes to trust both the new and existing root certificates.
Older devices with factory-provisioned keys don't support key rotation and continue to use the
old root.
The certificate extension schema itself will remain unchanged; only the root is changing.
Both human-readable and machine-readable forms of the new root will be publicly available.
Verify compatibility with the new root
To verify your application is compatible with the new root certificate, you can register
a test device with the Google RKP backend so that it receives certificates signed by the new root.
Follow these steps to test your application with the new root:
Prerequisites
Make sure you have the following requirements in place:
The device supports RKP. Most devices sold in 2025 and later support RKP. You can verify RKP support
by using adb shell cmd remote_provisioning dump. The output should
contain the following:
Run the registration tool: python3 google_root_register.py
Factory reset the device. This step is required to clear all previously-provisioned
certificates.
Verify the device is receiving certificates signed by the new root by running adb shell
cmd remote_provisioning certify default. The output is an X.509 certificate chain in
PEM format. The last certificate is the root, which should match the following:
Don't query an endpoint for trusted roots at runtime, as this action creates security risks.
Handle changes to roots of trust through a formal process.
Phase out factory keys: Remote Key Provisioning (RKP)
For devices that launch with Android 16, the system supports only RKP. This policy phases out
factory keys. It improves how you provision and manage attestation keys, expanding on the Android
15 policy where RKP support was optional.
RKP prevents key leakage because the system does not program keys directly onto the device.
You cannot delete these keys from the device. If you must revoke a key, you can target the
revocation to a single device.
Attestation verification libraries
Use the attestation verification Kotlin
library to verify Key Attestation certificate chains. Moreover, this library already integrates
the new root certificates.
If you are using a different verifier, we recommend moving to the Kotlin library instead.
It is well-tested, and covers edge cases that are often missed by custom verifiers.
Certificate revocation status list
Attestation keys can be revoked for a number of reasons, including mishandling or suspected
extraction by an attacker. Therefore, it's critical that the status of each certificate in
an attestation chain be checked against the official certificate revocation status list (CRL).
This list is maintained by Google and published at:
https://android.googleapis.com/attestation/status. The Cache-Control header in
the HTTP response determines how often to check for updates so a network request is not required
for every certificate being verified.
This URL returns a JSON file containing the revocation status for any certificates that don't
have a normal valid status. The format of the JSON file adheres to the following JSON Schema
(draft 07) definition:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"entries": {
"description" : "Each entry represents the status of an attestation key. The dictionary-key is the certificate serial number in lowercase hex.",
"type": "object",
"propertyNames": {
"pattern": "^[a-f1-9][a-f0-9]*$"
},
"additionalProperties": {
"type": "object",
"properties": {
"status": {
"description": "[REQUIRED] Current status of the key.",
"type": "string",
"enum": ["REVOKED", "SUSPENDED"]
},
"expires": {
"description": "[OPTIONAL] UTC date when certificate expires in ISO8601 format (YYYY-MM-DD). Can be used to clear expired certificates from the status list.",
"type": "string",
"format": "date"
},
"reason": {
"description": "[OPTIONAL] Reason for the current status.",
"type": "string",
"enum": ["UNSPECIFIED", "KEY_COMPROMISE", "CA_COMPROMISE", "SUPERSEDED", "SOFTWARE_FLAW"]
},
"comment": {
"description": "[OPTIONAL] Free form comment about the key status.",
"type": "string",
"maxLength": 140
}
},
"required": ["status"],
"additionalProperties": false
}
}
},
"required": ["entries"],
"additionalProperties": false
}
Attestation forms the backbone of counterabuse and trust in the Android ecosystem. It provides a
cryptographically verifiable statement to off-device parties about the booted state of the device.
The certificates for Android attestation keys will be revoked when the keys are compromised, due
to the critical nature of attestation validity. This section outlines a policy for when
certificates are revoked. This policy is likely to evolve and enumerate additional cases over
time.
What qualifies for revocation?
Attestation keys that have been leaked are always eligible to have their certificates revoked.
Leaks are discoverable in a number of ways, including:
Analysis of attestation data in the wild.
Discovery of attestation keys on social media or other public sites.
Reports directly from security researchers.
Upon discovery, attestation certificates will be revoked by having their serial numbers added to
the revocation list. Typically
this will happen within several days of discovery, but may take longer in rare cases. For example,
the revocation of certificates for leaked attestation keys is usually delayed if the devices
affected by the revocation can be securely re-provisioned. Scale of the impact of the revocation
is also an important factor in revocation timelines.
Key attestation extension data schema
Provisioning information extension data schema
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
