Android KeyStore: what is the difference between “StrongBox” and “hardware-backed” keys?
Together with the announcement of the Pixel 3 and 3 XL phones came a bunch of other announcements, one of them being the “Titan” security chips. It turns out that the new phones from Google are equipped with a security-dedicated chip, called Titan M, which is used by the OS (and lower level components) to e.g. verify the integrity of the images that are loaded at system’s boot or to verify your lock screen passcode. You can read more about the Titan M chips in this blog post by Google.
An interesting bit of information that can be read in there is the following:
With Android 9, apps can now take advantage of StrongBox KeyStore APIs to generate and store their private keys in Titan M.
Okay, so… “StrongBox Keystore APIs”, huh? The provided link brings you to the Android KeyStore documentation, with a section that reads as follows:
Supported devices running Android 9 (API level 28) or higher installed can have a StrongBox Keymaster, an implementation of the Keymaster HAL that resides in a hardware security module. The module contains the following:
- Its own CPU.
- Secure storage.
- A true random-number generator.
- Additional mechanisms to resist package tampering and unauthorized sideloading of apps.
The Question
But… haven’t we had the “hardware-backed” KeyStore implementation for a several Android releases already? Looking into the docs, we see that KeyInfo.isInsideSecureHardware() has been around since API level 23 (that is, Marshmallow — or, for what it’s worth, 3 major releases of Android ago).
So… what is the difference between a key generated using the new StrongBox API (more precisely, by calling KeyGenParameterSpec.Builder.setIsStrongBoxBacked(true)) and a key generated with the “old” API but that is still “hardware-backed” (i.e., which returns truewhenKeyInfo.isInsideSecureHardware() is called)?
The Answer
Reading through the officials docs did not answer the question, so I decided to ask directly to the people at Google responsible for Android Security. It turns out, I was lucky enough to get an answer:
Long story short: “StrongBox” means that the keys are stored in a Secure Element (“Titan M” chip in the Pixel 3 phones), whereas “hardware-backed” means something more generic like “somewhere outside of the Android OS” (the standard implementation of it being in a TEE).
Ok, but… What is a TEE? And a Secure Element?
Note: short detour to explain the concepts of SE and TEE. If you already know them, you can skip it and go directly to the “conclusion”.
A trusted execution environment (TEE) is a secure area of a main processor.
More precisely, a TEE runs its own OS, and communicates with the “main” OS only through a “restricted” interface (generally a shared memory region which both OS’s use to exchange data). In the case of Android, this means that compromising the Android OS (or its kernel) would not result in compromising the processes running in the TEE.
Android phones have been equipped with TEEs for some time now, and it is common that the biometric sensors of the phone (e.g. the fingerprint scanner) are directly connected to the TEE, meaning that the end user’s biometric data lives only within the TEE and never in the Android OS.
A Secure Element (SE) goes one step further: it is a separate microchip, with its own CPU, storage, RAM, etc. which is designed specifically for security-relevant purposes. SEs are resistant to a wider variety of attacks, both logical and physical, such as side-channel attacks. Interestingly enough, you are probably using SEs in your daily life without knowing it: your SIM card’s chip is a SE, and also is your credit card’s.
The Conclusion
SEs provide the strongest security level available in the industry as of today, so you should use the new “StrongBox” API for generating your cryptographic material whenever it is available. If it is not, but your key info’s isInsideSecureHardware() returns true (which would mean that your keys are protected -at least- by a TEE), then you can also rest assured that your keys are protected by a “good enough” combination of software and hardware.
Unfortunately, there will be lots of devices where neither StrongBox nor hardware-backed keys will be available (do I hear fragmentation?), so… what is the solution for those devices? The answer is: it depends. In such devices, the security of the key material relies solely on software measures, which means that a compromise of the Android OS (such as a root exploit) might end up revealing you user’s keys. What are the implications that this would have on you and your users? Is it acceptable from a business perspective? You’ll first need to answer those questions before making any decision.
If this is acceptable for you, then great! You can stop reading. If not, you still have a few options left. The easiest and cheapest one is to leave the users of such devices behind, disabling the feature that requires the crypto material if the required protection level is not available. In cases were this is not possible, WhiteBox Cryptography (WBC) libraries offer a good compromise between security and device support.
The Summary
