The Android Keystore

Posted by chris on 2020-12-26, Category: Android

A copy of this article is also available here

While full-disk and file-based encryption goes a long way to protecting the data stored on an Android device, for some especially sensitive data like passwords etc., this may not be enough.

The problem is that if an attacker is able to compromise the Linux kernel or gain root access via some other means, then since the kernel is able to read the unencrypted contents of any files stored on the device (once the user has entered their password), the attacker can gain access to any sensitive data. Also, even if an attacker is not able to gain root access, if they can nonetheless compromise your app, then they can gain access to your app’s data.

The solution is to directly encrypt the most sensitive data before storing it.

This approach works for data stored on both internal and external storage (or sent over the network for that matter). In the case of internal storage, the data will be doubly encrypted on a device that supports full-disk or file-based encryption. The data itself will be encrypted, and then the file it is stored in (possibly along with unencrypted data) will also be encrypted.

Getting this right though is hard, and we strongly recommend you speak to a security expert before attempting this.

Protecting your keys

There are several issues that need to be addressed, including very technical ones regarding which encryption ciphers to use, and their various modes.

But there is also another issue, one that everyone can understand. Put simply, if you encrypt something then you want to be able to decrypt it again at some later date. To do so you will need a decryption key. The problem is how do you protect the key?

If an attacker can get hold of the decryption key they can read your data, so we have simply transferred the problem of protecting the data, to the problem of protecting the key. You might at this stage ask if we have gained anything?

Well think about protecting all the nice shiny things in your house. You do that by locking the door. And then you put the key in your pocket. The key is with you at all times and you are able to guard it. This is possible because the key is small. You could try carrying your TV with you at all times, but it will probably soon get rather annoying!

The same principle applies to cryptographic keys. They are much smaller (usually) than the data that they are used to protect. We just need to find the electronic equivalent of your pocket. The answer to that is the Android Keystore.

Secure hardware and the Android Keystore

The Android Keystore provides access to special secure hardware for storing cryptographic keys.

The Android Keystore was significantly enhanced in Android 6.0 (API level 23) to provide more capabilities on those devices with the hardware to support them. On devices with the appropriate hardware support, keys can be generated within the secure hardware, and then used to perform cryptographic operations on user data, without the keys ever leaving the secure hardware. It is simply not possible to extract (at least through software means) the keys stored in the secure hardware.

When a key (or key pair) is generated in the secure hardware it is also possible to specify access controls that must be enforced to protect use of the key. This can include the option of requiring the user to input their device password every time the key is used (or provide their fingerprint on devices with a fingerprint reader).

More details about the Android Keystore can be found here.

Notes for Nerds: impressive as this undoubtedly is, it still may not be completely secure. But then nothing ever is. The point is that even though malware can never extract a key from the secure hardware, it may still be able to use it. Use of keys may be subject to access controls like requiring the user to enter their device password, but if an attacker is able to gain root access then they may be able to install a keylogger (software that records everything the user types – including their password!), and that may then allow the attacker to use any keys stored in the secure hardware. If one of those keys has been used to encrypt data also stored on the device, then the attacker may be able to decrypt the data. Whether such an attack is possible may depend upon the specifics of the device.

结束!

chris

January 22, 2021, 6:00 am

You can use a normal KeyStore file or the Android KeyStore Provider.

KeyStore (API 1)

You will have to create a KeyStore file and you will also have to manage the secret to access to it. This secret is very sensitive and difficult to hide from attackers. Personally I prefer to delegate that responsibility on the Android system, and this is why I don’t choose this solution over the next one.

Android KeyStore Provider (API 18)

Using this API’s you will delegate all the heavy lifting of managing the file and secret on Android. You will not need to use any password since the OS itself will store it deriving from your lock screen PIN code, password, pattern and other variables.

If the device contains an embedded secure hardware, the key will be stored there (e.g., Trusted Execution Environment (TEE)). You can check KeyInfo#isInsideSecureHardware() method to see whether the key is saved there or not. This hardware mechanism provide us an extra protection in case of our app is running into a compromised Linux kernel.

Moreover, beginning with Android 9 (API level 28), StrongBox Keymaster API was introduced for those devices which include a secure chip (like Titan M on Google Pixel 3). If you’re running on Android 28 or above, you just need to invoke the setIsStrongBoxBacked(boolean) method to let Android know you want to use it if it’s available on the device. Even though the aforementioned TEE solution is acceptable, this mechanism of using a Secure Element (SE) is the most secure one, since it is based on a different hardware (CPU, memory, storage, etc) designed for security purposes.

Here we would have a quick example of how to create a self signed certificate and a key pair using StrongBox if supported:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_RSA, "AndroidKeyStore")
        .apply {
            val certBuilder = KeyGenParameterSpec.Builder(alias, KeyProperties.PURPOSE_ENCRYPT)
                .setKeyValidityStart(keyValidityStart)
                .setKeyValidityEnd(keyValidityEnd)
                .setCertificateSerialNumber(BigInteger.valueOf(1L))
                .setCertificateSubject(X500Principal("CN=MyCompany"))

            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
                initialize(
                    certBuilder
                        .setIsStrongBoxBacked(true) /* Enable StrongBox */
                        .build()
                )
            } else {
                initialize(certBuilder.build())
            }
        }
        .also {
            val keyPair = it.generateKeyPair()
            ...
        }
}

Regarding to your questions:

Can we extract the key from that KeyStore?

With both of them your app can get the PrivateKey and use it if this is what you mean.

Can another application (AppB) access the key generated by AppA?

With the KeyStore provider solution each app can only access to their KeyStore instances or aliases. Instead, using a normal KeyStore if another app has access to the file it could try to attack it.

In which case we may loose the key? Device Factory reset only?

Deleting the app will erase the KeyStore provider instance of your app. However, due to [a nasty bug](https://doridori.github.io/android-security-the forgetful-keystore/#sthash.iwA5YU1j.dpbs) of Android (more common before Android 5) if the user changes the lock screen pattern into a password or just deletes the pattern, the KeyStore will be fully corrupted. The same happens when the user performs a “Clear credentials” from the Android settings. With the classic KeyStore instead, you could store it in the external storage and keep it even after a device factory reset. However, as mentioned before, it is still less secure than the provider.

I may be wrong in some aspects, but this is what I learn and I just shared my experience. Hope this is helpful for you.