Verify hardware-backed key pairs with key attestation

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.

Note: 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. Note, however, that devices containing revoked certificates are still at least as trustworthy as devices that only support software attestation. Having a fully valid attestation is a strong positive indicator. Not having one is a neutral—not negative—indicator.

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.

Note: On devices that ship with hardware-level key attestation, Android 7.0 (API level 24) or higher, and Google Play services, the root certificate is signed with the Google attestation root key. Verify that this root certificate is among those listed in the section on root certificates.

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 as the KeyStore. 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.

See the section about the provisioning information extension data schema for more details.
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.

See the section about the key attestation extension data schema for more details.
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 root public key is as follows:

Previously Issued Root Certificates

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 and to make whatever claims they like about what the attestation means. Refer to the device maker's documentation. Note that Google isn't aware of any device makers who have done this.

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
}

Example CRL:

{
  "entries": {
    "2c8cdddfd5e03bfc": {
      "status": "REVOKED",
      "expires": "2020-11-13",
      "reason": "KEY_COMPROMISE",
      "comment": "Key stored on unsecure system"
    },
    "c8966fcb2fbb0d7a": {
      "status": "SUSPENDED",
      "reason": "SOFTWARE_FLAW",
      "comment": "Bug in keystore causes this key malfunction b/555555"
    }
  }
}

Key attestation extension data schema

Provisioning information extension data schema

The provisioning information extension has OID 1.3.6.1.4.1.11129.2.1.30. The extension provides information that's known about the device by the provisioning server. This extension follows a CDDL schema.

  {
        1 : int,   ; certificates issued
  }

The map is unversioned and new optional fields may be added.

certs_issued: An approximate number of certificates issued to the device in the last 30 days. This value can be used as a signal for potential abuse if the value is greater than average by some orders of magnitude.