Today, our mobile devices are practically a diary where we store everything: from intimate photos to our credit card details. That's why we can't leave security to chance. When it comes to protecting sensitive data on Android, the Android Keystore System becomes the key tool for preventing malicious actors from stealing our cryptographic keys, making it a fundamental pillar of Android security.
Basically, this system acts like a digital safe. Instead of storing keys as simple text files on the phone's storage (which would be a security disaster), it locks them in a secure container . Best of all, once the key is inside, you can use it to encrypt or sign things, but it can never be extracted from the device, not even if the operating system has been compromised.
How does security work at the heart of the system?
The Keystore doesn't mess around and protects the key data in two very clear ways. First, it prevents anyone from outside the device from stealing the key data, as it blocks extraction from application processes. Second, it ensures that even if someone manages to gain access to the system, they cannot use the key for whatever they want; apps must define authorized uses that the system strictly enforces.
To make this truly robust, Android relies on hardware. The key data doesn't pass through the app's processes; when you need to perform an operation, the data is sent to a specialized system process . Furthermore, if the phone is modern, the keys are linked to the Trusted Execution Environment (TEE) or the Secure Element (SE). If you have a device with StrongBox , security is taken to the next level, as this module has its own CPU, secure storage, and a real random number generator, making it resistant even to physical attacks.
To determine if a key is truly protected by hardware, developers can use `getSecurityLevel()` in Android 10 and higher. If the result is `TRUSTED_ENVIRONMENT` or `STRONGBOX` , we can rest assured that the key resides in an area isolated from the main processor.
Access control and usage authorizations
One of the best features of this system is that you can assign "rules" to each key when creating it. These rules are immutable; once set, they cannot be changed . For example, you can restrict a key to only working with specific algorithms , such as AES or RSA, or define a precise time frame during which the key is valid.
But the most powerful thing is the user authenticationYou can configure the key to only work if the user has recently authenticated using their PIN, pattern, or biometrics (fingerprint or face)), considering that the 2D vs 3D facial unlock It offers different levels of protection. There are two modes: one that authorizes all keys for a certain time after authentication, and another stricter one where every crypto operation must be authorized individually through a BiometricPrompt.
Keychain vs. Android Keystore Provider
Sometimes you might wonder which one to choose. The KeyChain API is the ideal option when you need system-wide credentials. Here, the user chooses, through a system interface, which credentials they want to share with the app. This is very useful for credentials shared between multiple applications with the explicit consent of the mobile device owner.
Furthermore, the Android Keystore Provider It's designed so that each application manages its own keys privately. It's the preferred option when you want to just your app have access to their secrets without the user needing to manually select keys from a list. To implement this, standard Java classes are used, such as KeyStore, KeyPairGenerator o KeyGenerator.
Technical Implementation: Encryption and Signatures
For symmetric data encryption, AES-GCM is the most recommended method . This method not only maintains secrecy but also guarantees data integrity by detecting if the encrypted bytes have been tampered with. It is crucial to remember that each operation generates a unique Initialization Vector (IV) that must be stored along with the encrypted data in order to reverse the operation.
If you need a digital signature, the way to go is to use RSA . A key pair (public and private) is generated within the keystore. The private key remains locked in secure hardware to sign the information , while the public key can be distributed to verify that the message has not been altered and that it comes from the original source.
Internal architecture and evolution of the system
Under the hood, the system is a complex machine. AndroidKeyStore It is the visible face of the app, but it communicates with the keystore daemon through Binder. This daemon manages the keyblobs (encrypted keys) and relies on the HAL of KeyMint (formerly Keymaster) to perform heavy lifting in the secure world.
The road has been long: from Android 6.0, which introduced access control and AES/HMAC primitives, through Android 7.0 with key certification and version linking (to prevent an attacker from downgrading the OS to a vulnerable version), to Android 12. In this latest version, the daemon was rewritten in Rust to gain security and KeyMint's HAL was introduced, which supports ECDH key agreements and key usage limits.
Forensic perspective and extraction risks
Although the keystore is very robust, in the world of computer forensics there are methods to try to extract the information. The keys are stored encrypted in /misc/keystore/ (or in an SQLite database since Android 12). To protect them, a Key Encryption Key (KEK) derived from fixed values ​​of the secure hardware.
Some digital forensics experts attempt offline decryption by extracting hardware values ​​through processor-specific vulnerabilities (such as MTK or Qualcomm). If they manage to obtain the KEK (Keystore Key), they can decrypt the keys in the keystore and subsequently access encrypted databases of applications like Signal or Element , which typically use the keystore to protect the master key of their Realm databases.
