Modern Security in Android (part 2)
A fast guide to be safe
This post is related to my lastest talk about “Modern Security for Android Developers”.
Here is the list of the blogs in this series:
- Part 1 — Encryption Vol 1
- Part 2 — Encryption Vol 2
- Part 3 — Encryption Vol 3
- Part 4 — Biometric as Local Auth
- Part 5 — Native Code Modules
- Part 6 — SSL, TLS, Secure Data layer
In the last post of this serial we talk about Google working on a new library that will be delivered on Android Jetpack: androidx.security:security-crypto
Well, the time has passed and finally, security-crypto is now in a release candidate phase!
So now is: androidx.security:security-crypto:1.0.0-rc01
You may ask, why we need to have a new library for encryption if we already have android.security.keystore, which gives us the chance to create a key of two types, an asymmetric key pair or symmetric keys, this new library uses the builder pattern provided by Keystore but in a different style, to provide safe settings for the creation of keys, taking in consideration that we need good encryption with good performance.
So in iOS, there is something called KeyChain, it stores keys and values for the users, in Android, we have KeyStore, and one of the things you need to know is that you need to create a Provider for this. The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device. Once keys are in the Keystore, they can be used for cryptographic operations with the key material remaining non-exportable. Moreover, it offers facilities to restrict when and how keys can be used, such as requiring user authentication for key use or restricting keys to be used only in certain cryptographic modes.
How does it work?
The KeyStore has two things to protect, the key itself and the “key” that is referable to the value. Using KeyStore means you will not leak any information in your app, because the Key material never enters the application process. When your application wants to perform some crypto operation, behind the cipher are fed to a system process that carries out the cryptographic operations.
What is a hardware-backed system?
Using KeyStore you can bound this process to secure hardware, there’s so many of this but pretty much is a TEE (Trusted execution environment), that is an isolated execution domain that provides security features when this feature is enabled for a key the material is never exposed outside of secure hardware. If the Android OS is compromised or an attacker can read the device’s internal storage, the attacker may be able to use any app’s Android Keystore keys on the Android device, but not extract them from the device.
The problem of encryption in Android
Somehow, the clarity of encryption and decryption process was not clear enough, the amount of an algorithm supported for different SDK versions of android and the number of bytes supported by these algorithms were too much information. For example, the use of Keychain API is about system-wide credentials. When an app requests the use of any credential, users get to choose, which credentials an app can access. But the Keystore provider lets an individual app store the credentials that only the app itself can access.
KeyStore was introduced in the API 1 of Android, but the Android KeyStore Provider was introduced until API 18, later on with API 28 Google introduced StrongBox for devices with a Secure Chip, even though the TEE mentioned solution is good enough, this mechanism of using a Secure Element (SE) is the most secure one since it is based on a different chip (CPU, memory, storage) designed for security purposes, this will increase the time of the operations but is probably the most secure way to do it.
In the next gist, you can see how to create a self-signed certificate and a key to start using it
What makes androidx.security different?
It is not that KeyStore and Jetpack Security are different they are a complement of each other, the new library uses KeyStore to implement a two steps operation system of Keys and Master keys with the addition that you can use it to encrypt easily a file or a shared-preference.
- The first step is the blue part that represents the key we are going to create to encrypt data, and the data we want to encrypt (could be a file or Shared Preference [Key-Value Map]) this information will be rounded to a keyset (the green part) that contains one or more keys to encrypt data. The keyset is stored in shared preferences
- The second step of this system is the yellow one, rounded every keyset, we have a master key that encrypts all keysets. This master key is stored using the Key Store
To start using Jetpack security you can check the next gist:
This creates the master key that you need for the keysets, MasterKeys is a helper class that allows the developer to create a master key and then gets an alias for it, the recommendation is to use the algorithm AES256-GCM that generates a symmetric key, but you can define your own key generation parameter specification, exactly like the KeyStore API in the top, including time outs, strongbox, and biometric prompts that will be discussed later on in this serial.
For the next part, we will discuss the Files and Shared Preferences you can use in Jetpack Security
This is all for this part of the post, If you need help:
I’m always happy to help, you can find me here:
Medium: https://medium.com/@dinorahto
StackOverflow: https://stackoverflow.com/users/4613259/dinorah-tovar
Happy Coding! 👩🏻💻
