This article is more than 1 year old

Cracking Android's full-disk encryption is easy on millions of phones – with a little patience

Just need a couple of common bugs, some GPUs and time

Android's full-disk encryption on millions of devices can be cracked by brute-force much more easily than expected – and there's working code to prove it.

Essentially, if someone seizes your Qualcomm Snapdragon-powered phone, they can potentially decrypt its file system's contents with a friendly Python script without knowing your password or PIN.

The tech details

Android encrypts a gadget's file system using a randomly generated 128-bit Device Encryption Key aka the DEK. Android encrypts the DEK using the owner's PIN or password and stores it alongside the encrypted file system in the device's flash storage chips. When you give Android the correct PIN or password, it can decrypt the DEK and use the key to unlock the file system.

However, it's not quite that simple: the DEK is actually encrypted using the owner's PIN or password and an encrypted block of data called the KeyMaster Key Blob. That blob contains a 2,048-bit RSA key generated by a KeyMaster program that runs inside a secured portion of the device's processor. The KeyMaster creates the RSA key, stores it in the blob, and gives an encrypted copy of the blob to Android.

It's important to understand that Android and your mobile apps run in the non-secure portion of the processor. Android is not allowed to see into the KeyMaster's secure world and therefore it cannot see the RSA key inside the blob. Android is only given the blob in encrypted form and only the KeyMaster can decrypt it.

When you enter your PIN or password, Android takes the encrypted blob, and passes it back to the KeyMaster in the secure portion of the processor along with a scrypt-scrambled copy of your PIN or password. The KeyMaster privately decrypts the blob using a secret key fused into the processor to obtain the long RSA key.

The KeyMaster then, again privately, produces an RSA signature using the scrambled PIN or password and the long RSA key, and sends the signature back to Android. Android then runs that signature through a series of algorithms to ultimately decrypt the DEK and unlock the device.

So: this all hinges on the KeyMaster's blob. The blob contains the long RSA key that's needed to complete the decryption of the DEK. Android only has the encrypted blob – and only you have the PIN or password. And only the KeyMaster can decrypt the encrypted blob.

If you can decrypt the blob and extract its RSA key then you're potentially more than half there to decrypting the file system: you can now realistically start brute-forcing the PIN or password to complete the unlocking. Ideally, you should never be able to get hold of the unencrypted blob. But... there's always a but.

The vulnerabilities

Android defines how the KeyMaster should work but leaves the implementation to the hardware manufacturer. Qualcomm provides a KeyMaster for its ARM-compatible Snapdragon system-on-chips that are at the heart of millions and millions of phones, tablets and other gadgets. The KeyMaster runs in the processor's TrustZone – a special walled-off compartment present alongside various ARM cores. The operating system runs outside of TrustZone and cannot, ideally, interfere with the secure area. Special functions, such as encryption and fingerprint scanners, operate in the protected TrustZone.

Security researcher Gal Beniamini has been investigating Qualcomm's TrustZone code for a while now, and has documented in detail how he was able to extract the KeyMaster's keys from devices.

Qualcomm runs a small kernel in TrustZone to provide what's known as QSEE – the Qualcomm Secure Execution Environment – and little apps are allowed to run in this QSEE space away from Android.

Qualy's KeyMaster is a QSEE app. Beniamini has detailed how it is possible to exploit an Android kernel security hole to load your own QSEE app and then, within that protected space, exploit a privilege-escalation vulnerability in Qualcomm's TrustZone kernel to take complete control of the entire QSEE space. Once you've done that, you can peer inside KeyMaster and extract the unencrypted blob.

And with that blob, you can potentially decrypt the encrypted file system by brute-forcing the remaining secret: the PIN or password. Without the blob's secret RSA key, you'd be completely out of luck.

It's part security bug, part design blunder: the KeyMaster makes its crucial keys available to software, albeit software within a walled garden, so the aim of the game is to leap over the barriers and snatch the prize within. A malicious app could start the process, attacking the Android kernel to get into the QSEE zone, or a booby-trapped text message could slip in through StageFright and stab at TrustZone.

Alternatively, the FBI, say, could flash a custom Android build to a seized device with a TrustZone environment that extracts the KeyMaster keys, allowing the file system to be unlocked by brute force.

"Android uses the same FDE [full-disk encryption] scheme across all devices," Beniamini told The Register.

"This FDE scheme relies on the KeyMaster module to 'bind' the key to the hardware of the device. My research has shown that this 'binding' can actually be circumvented on Qualcomm's devices. It could be the case that this is also possible on devices made by other SoC manufacturers."

More about


Send us news

Other stories you might like