In security, the classic quote “Trust, but verify” (Russian proverb) has almost become a cliché, but it’s still a phrase to live by. To mistrust everything is no way to live, but it’s sensible to be cautious. What about Android applications and the cryptographic keys they use? How does the developer verify their trustworthiness? It used to be sufficient to check the key’s certificate, but is that still enough? The certificate alone doesn’t tell us how the key came to be or how it’s protected.
To help with all this, Google has added key attestation into Android 7 (Nougat) (see link). This feature gives Android developers more confidence about whether application keys are stored in a device’s hardware-backed keystore. A developer can now obtain the certificate chain for an application key and then verify the properties of that key. For example, “Was the key created and managed by a Trusted Execution Environment (TEE)?” or “Is the key rollback resistant?”
This is undoubtedly good news for Android developers wanting to know the trustworthiness of their keys. This is, however, early days though for this feature and Google state that “Only a small number of devices running Android 7.0 (API level 24) support hardware-level key attestation; all other devices running Android 7.0 use software-level key attestation instead”. Android devices with Nougat only account for 17.8% of Android devices (source: link)
Not all TEEs (the solutions that provide hardware protection) are equal. Android 7’s key attestation will tell you that the key is TEE-backed, but nothing about the TEE that protects it. Is it FIPS certified (link)? Does it have a Common Criteria certificate (link)?
Who should you trust?
Root of trust and attestation have been central to the Trustonic Secure Platform (TSP) since the outset and go well beyond the features offered in Android 7. All the 1.7 billion+ devices with TSP have a root of trust injected in the factory, meaning that the device’s identity can be trusted. Security-critical parts of an application secured using the Trustonic Application Protection (TAP) SDK can be set to only allow installation on devices that can prove their identity. Furthermore, both keys and secure application logic can be attested to. Android developers may even decide to simply not trust the device at all to generate application keys, in which case Trustonic’s TAP solution can deliver keys to the secured application running in the TEE.
Certainly, you should trust, but you should also verify as much as you can, using all the practical facilities available. Perhaps the proverb should be “Trust, but the more vigorously you verify something, the more you can trust it” (Rob Dyke).
