1

I am currently working through the Android tutorial about implementing Key Attestation. The tutorial can be found here: https://developer.android.com/training/articles/security-key-attestation
In the tutorial, under the implementation steps, there is a warning under the certificate's validity step: "Caution: Although you can complete this process within your app directly, it's safer to check the certificates' revocation status on a separate server that you trust."

Similar warning under the "Compare the extension data that you've retrieved from your ASN.1 parser with the set of values that you expect the hardware-backed key to contain." step: "Caution: Although you can complete this process within your app directly, it's safer to check the certificate's extension data on a separate server that you trust."

Question: Why is it safer to check the certificates' revocation status and extension data on a separate server versus within the app directly? What are the security implications of not using the separate server?

3

The certificate extension data is certified by hardware-backed keystore/strongbox (TEE) using its private key. The corresponding public key of TEE is certified by Google that acts as root of trust which is a mandatory requirement for all GMS licensed android 7+ devices. Device manufacturer injects certificate chain into the device's TEE at the factory.

The intent of key attestation is that apps can ensure that whether the provisioned secure environment is not emulated by the user by root access on the device. An emulated TEE cannot extract private key of real TEE so its chain of trust has to be fraudulent. To verify the chain of trust, the querying app needs to acquire Google root certificate and match it with the attestation data.

Local verification of attestation data can be manipulated by code injection by an app with root access. Code injection can feed fraudulent Google root certificate to the querying app to pass verification. Whereas forwarding the attestation to the web service can verify chain of trust externally and the client is let known about the attestation result. Online verification also allows web service to refuse service to the client if valid secure environment is not provisioned.

Certificate revocation can also be manipulated by the user. E.g. An emulated TEE can use compromised but valid chain of trust whose revocation status has been manipulated to pass local verification. Web service can verify certificate revocation status externally and discard attestation data if the certificate is found to be revoked.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.