Are you still unsure regarding the security of your user’s device?

Android Key Attestation

Friend of Security Engineers and Architects!

Shiv Sahni
Jul 14, 2019 · 5 min read
Image for post
Image for post
Android Leading Market Share

ndroid is leading the current era of mobility with more than 75% of the market share. Nowadays, mobile applications are not only used leisure purposes but are also used for the business critical operations wherein there is a huge flow of sensitive data.

Although, Android supports the beautiful concept of sandboxing which disallows an application to access the data of any other application in the normal scenario. It is still suggested that the applications dealing with sensitive data should consider the edge cases to securely handle sensitive data.

Android Keystore released in API level 18 came out to be as friends of security architect and developers. The keystore is still growing and has grown significantly since its release. Without spending much time let’s discuss another gem added to Android security crown called Android Key Attestation.

Key Attestation is a feature which allows developers to analyze the security of the cryptographic material managed by Android Keystore. For an instance, from the application server, we can initiate the key attestation process to check if the device used by the user is capable of storing the cryptographic material securely and thus take the data-driven decision.

From Android 8.0, the key attestation was made mandatory. For all the new devices that needs to have device certification(CTS) for Google suite of apps, such devices use attestation keys signed by the Google hardware attestation root certificate and the same can be verified while key attestation process.

Before we deep dive into the key attestation process, let’s briefly talk about some widely used jargons.

Tame The Jargons

For a better understanding of the concept of key attestation, let’s get the understanding of some key concepts pertaining to key attestation.

Trusted Execution Environment

TEE(Trusted Execution Environment) is a secure region of the main processor which is meant for handling critical data. It ensures that sensitive data is stored, processed and protected in an isolated and trusted environment.

ARM(Advanced RISC(Reduced Instruction Set Computing) Machine) implements the concept of TEE through ARM Trustzone. This technology provides hardware features to create a secure environment separated from the normal execution environment.

Source: Analysis of Secure Key Storage Solutions on Android
Source: Analysis of Secure Key Storage Solutions on Android
ARM Trustzone

As shown above, there is a separation of the hardware in two worlds namely secure world and normal world. Two isolated virtual environments are created that includes virtual processors and virtual resources such that the processes running in the normal world cannot access the secure resources directly.


Keymaster TA (trusted application) is a software that runs in a secure context such as TrustZone on ARM-based devices. The keymaster has access to original cryptographic material managed through keystore and performs all the keystore operations.


StrongBox is a stricter implementation of hardware backed keystore as Keymaster HAL(Hardware Abstraction Layer) is implemented as a Hardware Security Module(HSM). The module contains its own CPU, secure storage, true random number generator, etc. It was introduced in Android Pie, devices supporting Android 9 and above can have TrustZone implementation, StrongBox implementation or both.

Key Attestation Process

During key attestation, we can specify the alias of a key pair and in return, get a certificate chain, which is later used to verify the properties of the keypair. The following API can be used to retrieve the certificate chain:

public final Certificate[] getCertificateChain (String alias)

While attestation process if the following conditions are met it implies that the underlying device supports hardware-level key attestation and the key material is managed by hardware-backed Keystore:

  1. Root certification in the certificate chain is Google Hardware Attestation Root certificate.
  2. The security level of the Keymaster is TrustedEnvironment or StrongBox.

Alternatively, if the first condition fails i.e. attestation chain has any other root certificate, then Google does not make any claims about the security of the hardware.

Key Attestation Implementation Guidelines

Key attestation process can be implemented within the application directly but it is recommended that it should be implemented at the server-side for security reasons explained in the latter section.

The following are the high-level guidelines for the secure implementation of Key Attestation:

  1. The server should initiate the key attestation process by creating a random number securely using CSPRNG(Cryptographically Secure Random Number Generator) and the same should be sent to the client as a challenge.
  2. The client should call the setAttestationChallenge() API with the challenge received from the server and should then retrieve the attestation certificate chain using the KeyStore.getCertificateChain() method.
  3. The attestation response should be sent to the server for the verification and following checks should be performed for the verification of the key attestation response:
  • Verify the certificate chain, up to the root and perform certificate sanity checks such as validity, integrity and trustworthiness.
  • Check if the root certificate is signed with the Google attestation root key which makes the attestation process trustworthy.
  • Extract the attestation certificate extension data, which appears within the first element of the certificate chain and perform the following checks:
a. Verify that the attestation challenge is having the same value which was generated at the server while initiating the attestation processb. Verify the signature in the key attestation response.c. Now check the security level of the Keymaster to determine if the device has a secure key storage mechanism. The security level will be one of Software, TrustedEnvironment or StrongBox.d. Additionally, you can check the attestation security level which will be one of Software, TrustedEnvironment or StrongBox to check how the attestation certificate was generated.e. Also, some other checks pertaining to keys can be made such as purpose, access time, authentication requirement, etc. to verify the key attributes.

Decoding Attestation Response

To better understand key attestation process, let’s learn about the attestation response. The typical Android Keystore attestation response looks like this:

Attestation Response

The keys in the attestation response JSON have the following meaning:

  • fmt: Attestation statement format identifier
  • authData: It denotes the authenticator data for the attestation
  • alg: The algorithm that is used to compute the signature for attestation response
  • sig: Signature of the attestation response
  • x5c: Attestation certificate chain

Signature Generation and Verification

The sig is generated by concatenating authData and clientDataHash(challenge sent by the server) and signing through the credential private key using the alg signing algorithm and the same is verified at the server-side by using the public key in the first certificate.

This implies that the challenge plays an important role in the security of key attestation implementation. While implementing key attestation it strongly recommended that the validations should be performed at the server-side, the challenge used should be generated at server-side using cryptographically secure random number generator and the same should be verified at the time attestation.

Sample Code snippets for Android Key Attestation are available on GoogleSamples repo.


InfoSec Write-ups

A collection of write-ups from the best hackers in the…

Sign up for Infosec Writeups

By InfoSec Write-ups

Newsletter from Infosec Writeups Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Shiv Sahni

Written by

Security Engineer |Security Consultant |Infosec Trainer | Author | Lecturer | Open Source Contributor | Learner

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Shiv Sahni

Written by

Security Engineer |Security Consultant |Infosec Trainer | Author | Lecturer | Open Source Contributor | Learner

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew