Breaking Android’s Full Disk Encryption

July 15, 2016
What's Behind


Full disk encryption is the process of encrypting all of a user's data stored on their devices to prevent unauthorised access. Gal Beniamini, a security researcher, reported an attack on Android's full disk encryption scheme on devices using Qualcomm processors, running Android 5.0 (Lollipop) or later and managed to decrypt an encrypted file system. As proof-of-concept, the researcher also provided the full source of his exploit code as well as scripts that automate the attack on the vulnerable devices. The researcher warns that despite the exploits used in the attack have been patched by Google, a complete fix of the issue might require changes in the hardware implementation instead of a security patch solely.

Android's full disk encryption in a nutshell

Android's full disk encryption is based on dm-crypt, a well-known and well-established Linux kernel-level encryption mechanism, which provides transparent encryption of block devices using the kernel crypto API. The full disk encryption scheme works as follows:

  • Each device generates a random 128-bit master key (the Disk/Device Encryption Key - DEK), which is used to encrypt user's data, and a random 128-bit salt.
  • The user provides a PIN, password or pattern, which together with the generated salt is used by a key derivation function (scrypt) to derive a key.
  • The derived key (Key Encryption Key - KEK) is used to encrypt the DEK and then the encrypted DEK is stored in an unencrypted space of the device called "crypto footer".
  • Similarly the decryption process passes the user provided PIN, password or pattern with the salt through the key derivation function and uses the KEK to decrypt the DEK, which is then used to decrypt the encrypted file system.


Figure 1: Android's Full Disk Encryption/Decryption process

For enhanced security, the key derivation function is bound to the device's hardware. This is achieved by an additional field stored in the crypto footer that contains an encrypted RSA-2048 private key generated by Android's KeyMaster module. In an intermediate step of the key derivation process, the key derivation function uses this private key to sign the KEK. In order to decrypt the encrypted RSA-2048 private key and sign the KEK, the key derivation function uses the aforementioned KeyMaster module.

The KeyMaster module's purpose is to generate encryption keys and perform cryptographic operations. Due to the sensitive nature of these operations, the KeyMaster module runs in a secure environment separate from the Android system called the Trusted Execution Environment (TEE). When the KeyMaster module generates encryption keys it encrypts them using a hardware-backed encryption key, i.e. this is the key feature that bounds the RSA-2048 private key and consequently the key derivation function to the device's hardware. Then it returns the encrypted keys back to the Android system. Thus, when the Android system, e.g. an Android application, needs to perform certain cryptographic operations, it sends the previously encrypted keys to the KeyMaster module. The KeyMaster module decrypts the encrypted keys, performs the required cryptographic operations and returns the result to the Android system without ever revealing the encryption keys to the non-secure system. Similarly, the key derivation function sends the encrypted RSA-2048 private key to the KeyMaster module to decrypt it, sign the KEK and return the signature back to the key derivation function (to continue the key derivation process) without the key derivation function ever accessing the RSA-2048 private key encryption keys.

The issue

Google has described how the Trusted Execution Environment should work but it is each hardware manufacturer's responsibility on how to implement it. Thus, Qualcomm facilitates a Trusted Execution Environment called Qualcomm Secure Execution Environment (QSEE) in the hardware level through TrustZone allowing only certain applications, e.g. the KeyMaster module, called "trustlets" to execute on a dedicated and secure processor.

By reverse engineering Qualcomm's KeyMaster module, the researcher pointed out that the key derivation function used to generate the KEK is not truly hardware bound as expected, since the key needed to decrypt the encrypted RSA-2048 private key is derived from a hardware key (using an internal key derivation function and hard-coded strings) that in fact is available to the TrustZone software and is not a real hardware key, which would not be possible to extract using software. This means that a vulnerability in TrustZone kernel or the KeyMaster trustlet can lead to the extraction of the KeyMaster's encryption/decryption keys.

The vulnerabilities and attack

Based on two previously published vulnerabilities disclosed by the same researcher - a code-execution vulnerability within QSEE (CVE-2015-6639) and a privilege escalation vulnerability from QSEE to the TrustZone kernel (CVE-2016-2431) - along with the knowledge acquired from identifying these exploits, the researcher managed to extract the KeyMaster's keys directly from the KeyMaster trustlet's memory.

To achieve that the researcher discovered an unprotected region in TrustZone's kernel code segments (XPU-unprotected region), identified a small chunk of code that was harmless to overwrite with a custom-made TrustZone kernel system-call, and tricked the KeyMaster module to call and execute this system-call by hijacking a legitimate system-call, which essentially leaked the KeyMaster keys.

By extracting the KeyMaster keys, an attacker can then brute force the user's PIN, password or pattern to acquire the rest half missing piece required to decrypt DEK and consequently the encrypted file system. Purely because of convenience most people set a 4-5 digit PIN or simple pattern, as opposed to a complex password. This makes the brute forcing process very trivial.

The attack can be performed by an attacker with physical access to the vulnerable device (using the researchers proof-of-concept code). According to the researcher even if a device is patched an attacker could potentially acquire the encrypted disk image using forensic tools, downgrade to a vulnerable version (for devices that allow that), extract the KeyMaster keys, brute force the user's PIN, password, or pattern and decrypt the encrypted file system.

What can be done about it?

Since the attack relies on vulnerabilities that have been patched by Google's monthly security updates (in January and May 2016), as noted in a previous ENISA info note "the OEMs are responsible for the maintenance of the open source software they use and must ensure that the patch provided by Google reaches their customers". In that context, the OEMs must make sure they keep-up with Google's security and OS updates by establishing a regular updating and patching regime in an effort to also assist in mediating Android's fragmentation problem.

Unfortunately, applying the security updates does not guarantee a complete fix of the issue, since a newly discovered vulnerability in the TrustZone kernel or KeyMaster's trustlet would allow the attacker to perform the attack, underpinning that the issue might require the redesign of the key derivation function in order to make use of a hardware key that cannot be compromised using software. This might as well introduce the need for additional hardware changes something that Google and OEMs should take under consideration.

Users are urged to install security updates right after they become available. Additionally users should use a strong password to safeguard their devices in order to render a potential brute force attack more difficult to succeed since, apart from the attack, guessing the user's PIN, password or pattern is half part of the equation.


Full disk encryption is a widely used feature that is becoming more and more established in Android devices, with the latest Android versions enabling it by default. Full disk encryption ensures that people's personal data are kept safe from potential attackers and people rely on this assumption. This attack and its publicly available implementation suggests that such an instrumental security feature is far from bullet-proof underlining the need for a more robust full disk encryption implementation.

About "What's Behind" from ENISA

With the "What's Behind" series ENISA aims at giving the interested reader some in-depth background about NIS related topics. The background is derived from past experiences and common sense; in no way should "What's Behind" be understood as recommended course of action in a specific incident or investigation, or being a final conclusion. Feel free to get in touch with ENISA to discuss or inquire more information on the "What's Behind" series (

We use cookies to ensure we give you the best browsing experience on our website. Find out more on how we use cookies and how you can change your settings.

Ok, I understand No, tell me more