Are you still unsure regarding the security of your user’s device?
Android Key Attestation
Friend of Security Engineers and Architects!
Android 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.
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:
- Root certification in the certificate chain is Google Hardware Attestation Root certificate.
- 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:
- 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.
- The client should call the
setAttestationChallenge()API with the challenge received from the server and should then retrieve the attestation certificate chain using the
- 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:
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
sig is generated by concatenating
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.