nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

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

By Iain Thomson, 1 Jul 2016

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."

So... is it patched?

Beniamini exploited a chain of security bugs to infiltrate KeyMaster – bugs that have since been patched in the source code: one in January and the other in May.

If you're running a Nexus device or otherwise have received and installed the fixes from Google and Qualcomm, then you're safe until the next privilege escalation bugs are found (and there will be more. There always is). Without these programming flaws, you cannot leap from userspace to the kernel to QSEE to KeyMaster.

However, there's a large pool of unpatched Android handsets out there because it's down to the manufacturers and mobile carriers to test, validate and distribute updates to their customers. People's phones and tablets won't trust patches unless they've been signed off by their manufacturers, and Android hardware makers are notoriously slow to do so. That leaves folks with holes in their handhelds' operating system.

A lot of the time, Google can quietly push out patches via Google Play services: the software can install fixes directly from the mothership, bypassing tardy hardware makers. However, problems deep within Android and its drivers – such as the bugs exploited to crack the KeyMaster – cannot be fixed by the Play services, and must be fixed via updates obtained from the manufacturer. When they finally appear, of course.

Even if you are patched, this issue isn't going to go away, Beniamini said, because the way the Qualcomm TrustZone operates means that if another privilege escalation hole is found it can be used in the same way.

"If anyone finds another TrustZone bug in the KeyMaster module, or manages to elevate privileges to the TrustZone kernel, they'd be able to extract the KeyMaster keys again," he said. "This is really the sore point of it all – it means that the FDE scheme is only as strong as the TrustZone software."

Beniamini's exploit code, published on GitHub, checks out according to security experts contacted by The Reg, and the attack does make it possible to brute-force decrypt a phone's file system. Obviously, the stronger the PIN or password, the longer it will take to crack the encryption key – but it's better than trying to crack a 2048-bit RSA key.

"I've been contacted by the developer of hashcat, a platform used to rapidly crack various types of hashes and PRFs," Beniamini said.

"He said he would like to implement the key derivation function (which is the function being brute-forced) in the hashcat framework. Such an implementation would be very fast (and even faster once you 'throw' more hardware at it)."

Google pointed out that the issue is patched in the latest build of Android. Qualcomm told The Register that it had been working with Beniamini and Google on the issue after finding the bugs some time ago.

A Google spokesperson said: "We appreciate the researcher's findings and paid him for his work through our Vulnerability Rewards Program. We rolled out patches for these issues earlier this year."

Alex Gantman, vice president of engineering at Qualcomm, told us: "It's an architectural problem in how current Android architecture handles FDE. We are aware of this and are working with Google to make this more robust in the future."

The fear is that a serious change will require new hardware, leaving older customers with insecure handsets. But Gantman said that there are "things that can be done" with the existing hardware to make this kind of attack a lot less plausible. ®

The Register - Independent news and views for the tech community. Part of Situation Publishing