Android’s full disk encryption can be broken with brute force and some patience — and there may not be a full fix available for today’s handsets.
This week, Security researcher Gal Beniamini revealed the method in a detailed step-by-step guide on how it is possible to strip away the encryption protections on smartphones powered by Qualcomm Snapdragon processors, which means potentially millions of mobile devices could be vulnerable to attack.
Android’s Full Disk Encryption (FDE), first implemented in Android 5.0, generates a randomly-chosen 128-bit master key and a 128-bit randomly-chosen salt to protect user data. The master key, also known as the Device Encryption Key (DEK), is then protected by encryption based on the user’s credentials, whether this is a PIN, password or touchscreen pattern.
The now-encrypted DEK is then stored on the device.
In order to prevent successful brute-force attacks against this process, Android introduced delays between decryption attempts and data wipes after a number of failed attempts — in the same way as Apple. To prevent off-device brute-force attacks, the key is bound to the device’s hardware — and this is where a security flaw in Qualcomm systems has caused a problem.
The binding is performed through Android’s Hardware-Backed Keystore, called KeyMaster. The module runs in a Trusted Execution Environment (TEE) which is considered the “secure world,” while the Android OS is considered the “non-secure world.”
The reasoning behind this is that KeyMaster can be used to generate encryption keys and perform cryptographic functions without revealing this information in the main operating system.
Once keys are generated, they are encrypted and returned to the main OS, and when operations require these keys, an encrypted block of data, the “key blob,” must be provided to KeyMaster. The key blob contains a 2,048-bit RSA key which runs inside a secure portion of the device’s processor and is required for cryptographic processes.
“Since this is all done without ever revealing the cryptographic keys used to protect the key blobs to the non-secure world, this means that all cryptographic operations performed using key blobs must be handled by the KeyMaster module, directly on the device itself,” the researcher says.
However, KeyMaster’s implementation is down to the hardware vendor. Qualcomm’s version runs in the Snapdragon TrustZone which is meant to protect sensitive functions such as biometric scanning and encryption, but Beniamini found that is is possible to exploit an Android security hole to extract the keys from TrustZone.
Qualcomm provides a Trusted Execution Environment called QSEE (Qualcomm Secure ExecutionEnvironment) which allows small apps, called “Trustlets,” to run inside of this secure environment and away from the main Android OS — and one of these QSEE apps running is KeyMaster.
However, you can exploit an Android vulnerability to load your own QSEE app inside TrustZone which can lead to privilege escalation and hijacking of the full space — as well as the theft of the unencrypted blob containing the keys generated for full disk encryption.
Once this step is complete, a brute-force attack is all you need to grab the user password, PIN or lock, and you have both parts of the puzzle needed to strip away Android’s FDE.
A deeper look into the decryption process can be found here. The full source of the exploit is located on Github.
As noted by The Register, the researcher has been in touch with the developer of hashcat, used to crack hashes, to implement the function being brute-forced which would speed up the cracking process.
“As we’ve seen, the current encryption scheme is far from bullet-proof, and can be hacked by an adversary or even broken by the OEMs themselves (if they are coerced to comply with law enforcement),” the researcher noted. “[..] However, I believe a concentrated effort on both sides can help the next generation of Android devices be truly “uncrackable.”
Beniamini has been in touch with Qualcomm concerning this issue, but says that “fixing the issue is not simple,” and it might even require hardware changes — and so until handsets are upgraded or switched to newer models, the problem will remain.