What is Android Keystore?
Android provides a number of mechanisms to protect user data.Data is almost always encrypted at rest through schemes such as Full disk or File-based encryption.Features like user lock screens and app sandboxing also serve to protect user data contained in apps from unauthorized access or extraction.However, all of these protections can be defeated in certain circ*mstances and app developers may choose to add a layer of security at the application layer.
Table of Contents
- Android encryption challenges
- Finding Keystore keys
- Keystore extraction with Oxygen Forensic® Detective
- How to perform a Keystore extraction
- Summary
Android encryption challenges
An example of this is when developers choose to implement encryption of their apps data.This encryption can protect a range of data types stored on the device such as messages, media or other sensitive data such as credentials. The challenge for developers is in how to implement this extra layer of encryption.
Implementing an encryption scheme which stores encryption keys in the Android filesystem, uses hardcoded values to derive keys, or even derive keys from user input is still somewhat insecure:
- If the keys, or values used to derive them can be extracted from the Android filesystem, then it is trivial to reverse engineer the application and use these values to decrypt the data.
- Even if keys are derived from a user input such as a password or PIN code, schemes are still vulnerable to password recovery methods like dictionary or brute-force attacks.
To solve this problem, Android makes available an API that allows app developers to store encryption keys in a secure area which is not part of the Android filesystem and is not accessible to Android even if the Android operating system is compromised.This offers a similar degree of protection as the Android device-level encryption used for protection of the user data partition can be “hardware backed” if the device supports it; which most modern devices do.The Android subsystem used for this is called Keystore and is used by a number of popular applications such as Briar, Wickr, Signal, and the Element app to name a few.
Finding Keystore keys
Keystore keys are stored in the user data partition in the following location: /misc/keystore/ but are usually stored in an encrypted format.
- Up to Android 11, each Android user on the device has a separate sub-directory and Keystore entries are stored in a dedicated file per entry, along with an associated file containing just the “characteristics” (associated metadata) of the Keystore entry.
- In Android 12 and above, the Keystore entries and associated metadata for all users are stored in an SQLite database located at: /misc/keystore/persistent.sql.
Key Encryption Key (KEK)
Although applications can request the use of their associated keys via the Keystore subsystem and receive the results, Android prevents their direct access. In order to prevent an attacker who has compromised the Android Operating System from extracting these keys, the keys themselves are usually encrypted with a further Key Encryption Key (KEK).
This KEK is generally hardware backed; that is to say, it is derived from some fixed values held in secure hardware.Android should not have access to these secure hardware held values and, once a device is booted, they should only be accessible to a Trusted Operating System (TOS) running in parallel to Android.It is the TOS which uses the values held in secure hardware to derive at each boot the KEK used to decrypt Keystore entries.
It is important to note that the TOS is a self-contained operating system and Android does not have access to the decrypted Keystore keys which are only decrypted by the TOS inside a “secure world.” Although there is effectively a “firewall” between the secure world and the normal world (in which Android runs), there are communication mechanisms that allow Android to request cryptographic operations using Keystore keys performed by the TOS and then to receive the results of those operations.
Common developer use of Android Keystore
A common way app developers make use of the Android Keystore is not necessarily to use it for direct encryption/decryption of their app data, but rather to use it to protect other keys generated within the app itself and stored in the Android filesystem, usually in the apps dedicated data directory. A simplified diagram of this kind of implementation is shown below:
Keystore extraction with Oxygen Forensic® Detective
Oxygen Forensic® Detective can extract Keystore keys in decrypted form using one of two methodologies. The first is via the Android Debug Bridge (ADB), Full File System Extraction (FFS) or ADB physical methods and is specific to particular applications for which we support Keystore extraction. This method does not actually extract the decrypted Keystore keys themselves, but rather requests via the Android OS that the TOS uses those keys to decrypt the app specific keys used for things such as database encryption. Once decrypted, these are the keys we extract using this method in order to decrypt the app data.
Second Keystore extraction method
The second method is to perform offline decryption of the Keystore keys themselves and is possible via the MTK, Unisoc, Qualcomm, Huawei Qualcomm, and Huawei Kirin methods.
This approach is made possible because through these methods we can extract the values held in secure hardware and use them to decrypt those “raw” Keystore keys.
An advantage to using this method is that all the Keystore keys should be decrypted and we can use them to decrypt data from apps which aren’t specifically supported by our software yet, or those which may be supported in the future without needing to perform another extraction.
Advantage: Oxygen automatically decrypts and parses apps
For those apps which are explicitly supported such as Wickr, Signal, and Briar (to name a few), Oxygen will take care of the decryption and parsing automatically.
A further advantage is that some apps may further secure the use of Keystore keys by adding a biometric or PIN/password based authentication step before the app can make use of the keys (removal of which may permanently invalidate the keys).
This process isn’t directly tied to encryption and offline decryption bypasses this security mechanism which may present a problem if extracting Keystore keys at the Operating System level via a “live” method.
Some apps, such as Briar, may choose to implement their own password input screen which allows them to tie the decryption of the app data to a user password as well as the Keystore key, but these apps seem to be in the minority.Password recovery for Briar via methods such as brute-force or dictionary attacks is possible within Oxygen Forensic® Detective.
How to perform a Keystore extraction
The Android version of the Element app is one which we don’t (yet – but watch this space) support for parsing, although we do currently support the desktop versions. With access to the Keystore keys, it is possible to decrypt it manually.
Element is an open source messaging application with a focus on security.It stores on-device data such as messages in an encrypted Realm database. It uses a fairly standard model in order to store and protect the database encryption key with a Keystore key, and it is the same model as the one shown in the earlier diagram in this post.
- The database encryption key is stored in an XML file called “im.vector.matrix.android.keys.xml” located in the shared preferences directory of the app (/data/data/im.vector.app/shared_prefs) and is encrypted with a Keystore key.
- The database is also stored in the apps data directory and is called “disk_store.realm.” This app is open source so we can more easily read through the relevant parts of the source code to understand how the encryption scheme has been implemented; the details are as follows:
- vector.matrix.android.keys.xml contains more than one key but the relevant one will start with “REALM_ENCRYPTED_KEY_session_db”.It is Base64 encoded and when decoded and converted to hex, it follows the below format:
- Byte 0 – Format version used to determine encryption type
- Byte 1 – IV (Initialisation Vector) length
- Bytes [2 – IV length] – IV
- Bytes from end of IV to start of GCM tag – encrypted database Key, Base64 encoded
- Final 16 bytes – GCM tag
The file viewer in Oxygen Forensic® Detective includes a number of useful viewers to be able to view data formats such as XML in a de-serialized view.The in-built data conversion tool is also extremely convenient for automatic conversion of selected data from formats such as Base64 encoding.
The hex values as shown in Oxygen Forensic® Detective data viewer are shown below:
In this example the format version (highlighted in yellow) is 0, this governs the type of Keystore key generated and encryption used when the app is first installed. It is decided based on Android version.
- The IV length (highlighted in purple) is 0x0C which is 0d12 so the IV is the next 12 bytes.
- The final 16 bytes are the GCM tag (highlighted in grey) and everything between the IV and the GCM tag is the Base64 encoded, encrypted, database encryption key (highlighted in green).
Selecting the right key
Next we require the relevant Keystore key in order to decrypt the database encryption key. Keystore keys, which have been decrypted offline, are available to view in Oxygen Forensic® Detective under the “Keystore” section of the “Accounts and Passwords” data category. We can select the right key by looking at the “Label” column which relates to the “alias” used by the application to access its Keystore entries. The alias is chosen by the app developer and can be any value.For Element the correct key has an alias which starts “session_db.”
How to solve alias naming conflicts
In the event that there is an alias naming conflict between apps, or multiple instances of the same app on a device, we can make sure we choose the correct one by also paying attention to the “Account” and “Service” fields in the details pane. These relate to the Android user ID and the application user ID respectively.We can find the app user ID (10283 in this example) by searching inside the “packages.xml” file located at: /data/system for the im.vector.app package name and check that it matches our decrypted Keystore key entry.
Decrypting the database encryption key
Now that we have the relevant Keystore key and know the structure of the database key entry stored in “im.vector.matrix.android.keys.xml”, we can use a tool such as Python or the ever useful, free, and open-source Cyberchef tool (see: https://github.com/gchq/CyberChef for more info) to try and decrypt the database encryption key.
For this task I used Cyberchef. The first stage in the recipe I used is an AES decrypt operation, populated with the relevant Keystore key, as well as the IV and GCM tags taken from the XML file. The operation is then run on the encrypted database encryption key segment (also taken from the XML file).Remember that this key is also stored in Base64 format, so after decryption we run a Base64 decode operation. Finally, as Realm database encryption keys are in hexadecimal format, we use a final operation to convert the output to hex.
The operation was successful and we now have a 128-character hexadecimal string as our output, which is promising.We can use this to try and decrypt the Element database within Oxygen Forensic® Detective.
After applying the key we can see that the database has been successfully decrypted and opened in Oxygen Forensic® Detective native database viewer. Now we can start manually investigating it for useful data.
Keystore decryption summary
Offline Keystore decryption is an extremely powerful capability. In an ideal world, a digital forensics tool would support parsing of every application but in reality this will never be the case, and manual analysis is sometimes required.
Although we always welcome requests for new app support and strive to add them, it may be that an investigation is too time-critical to wait.In these instances, having access to all of the Keystore keys in decrypted form ensures examiners will always have what they need to decrypt as much data as possible, even if they no longer have access to the physical device.
