A newly found crack in mobile security puts encrypted Android devices in danger. As proven by security expert Gal Beniamini, the standard full disk encryption (FDE) scheme in Android has a major weak point, which could entirely render this layer of protection useless.

FDE in Android - the process of encoding all user data through an encryption key - was first introduced in 3.0 Honeycomb and became on by default in 5.0 Lollipop. It was a great advancement in the security of the platform. Enabling full disk encryption means that in order to turn on an Android device, you must decrypt it first and then unlock the screen. In other words, decryption happens before the usual boot process of the operating system.

How Android FDE works, in brief

Android FDE is based on a Linux kernel subsystem called dm-crypt, which is great because it is widely deployed and researched. On top of that, the scheme includes a special piece of hardware baked into Android devices. Also, there are imposed delays after entering a wrong decryption pass code a certain number of times, as well as an option to wipe the device after a few subsequent failed decryption attempts.

While the encryption scheme may be robust, it is only as strong as the pass phrase used to decrypt the information. If it's long and complex, brute-forcing the encrypted master key could take years. However, for the sake of higher user-friendliness, Android reuses the losckreen pass code for decryption, which in practice means that most people are likely to end up with a relatively short or low-entropy FDE code. But still, there are protections in place...

One prominent Android security researcher, Gal Beniamini, has recently published a striking discovery for many people relying on the standard Android FDE - it can be cracked.

Before elaborating, he provides a short and clear explanation of Android's FDE:

"In short, the device generates a randomly-chosen 128-bit master key (which we'll refer to as the Device Encryption Key - DEK) and a 128-bit randomly-chosen salt. The DEK is then protected using an elaborate key derivation scheme, which uses the user's provided unlock credentials (PIN/Password/Pattern) in order to derive a key which will ultimately encrypt the DEK. The encrypted DEK is then stored on the device, inside a special unencrypted structure called the "crypto footer"

The encrypted disk can then be decrypted by simply taking the user's provided credentials, passing them through the key derivation function, and using the resulting key to decrypt the stored DEK. Once the DEK is decrypted, it can be used to decrypt user's information."

Combined with the restrictions when trying wrong pass codes and the eventual device wipe, modern Android devices are pretty well equipped versus on-device FDE crack attempts.

The Android KeyMaster

To combat off-device brute-force attacks, contemporary Android devices rely on a step in the key derivation scheme which binds the key to the aforementioned special piece of hardware. This binding is performed using Android's hardware-backed keystore - KeyMaster.

Here's how Gal Beniamini nicely explains what the KeyMaster does:

"The KeyMaster module is intended to assure the protection of cryptographic keys generated by applications. In order to guarantee that this protection cannot be tampered with, the KeyMaster module runs in a Trusted Execution Environment (TEE), which is completely separate from the Android operating system. In keeping with the TrustZone terminology, we'll refer to the Android operating system as the "Non-Secure World", and to the TEE as the "Secure World".

Put simply, the KeyMaster module can be used to generate encryption keys, and to perform cryptographic operations on them, without ever revealing the keys to the Non-Secure World."

TrustZone is hardware-based security built into systems on chip (SoC) by semiconductor chip designers in order to provide secure end points and roots of trust.

So where's the weak point?

It's the KeyMaster and the TrustZone themselves! Gal Beniamini has found a way to extract KeyMaster keys directly from the TrustZone so that an Android device can be decrypted and unlocked without wiping it.

"Android FDE is only as strong as the TrustZone kernel or KeyMaster. Finding a TrustZone kernel vulnerability or a vulnerability in the KeyMaster trustlet, directly leads to the disclosure of the KeyMaster keys, thus enabling off-device attacks on Android FDE," the researcher says.

And here's another critical problem - the key derivation is not hardware-bound, Gal Beniamini points out. Instead of using a real hardware key which cannot be extracted by software, the KeyMaster uses a key derived from the SHK (sentinel hardware key) and directly available to TrustZone, and it is this second, derived software key that can be extracted.

If you think that patching the TrustZone might help... Wrong! Patching TrustZone vulnerabilities doesn't necessarily protect you from this issue, the researcher claims. Even on patched devices, if an attacker can obtain the encrypted disk image, for example through forensic tools, they can downgrade the device to a vulnerable version, extract the key by exploiting the TrustZone and then brute-force the encryption. The weaker the pass code, the faster. Since the key is derived directly from the SHK, and the SHK cannot be modified, this renders all downgradable devices directly vulnerable.

And if that's not enough, Beniamini suggests that not only attackers could break the Android FDE - OEMs could do it, too, if pushed by law enforcement!

"OEMs can comply with law enforcement to break Full Disk Encryption. Since the key is available to TrustZone, OEMs could simply create and sign a TrustZone image which extracts the KeyMaster keys and flash it to the target device. This would allow law enforcement to easily brute-force the FDE password off the device using the leaked keys," the researcher warns.

How does Secure Phone beat the hack?

secure_phones.pngAs a company that has been researching Android security for many years, we knew that we couldn't trust the standard Android FDE for our Secure Phone.

Although our Secure Phone models are based on existing devices, like HTC M8 and NEXUS 5, we have modified every piece of software on them that's above the Linux kernel in order to tighten up security to the maximum. This includes the implementation of a better full disk encryption scheme that requires separate pass codes for device decryption and screen unlocking. In addition, we have set the bar pretty high in terms of complexity and length, so that brute-forcing the decryption pass code would be an absolute nightmare even for the most powerful supercomputers.

There's no magic here. Secure Phone is designed with security and privacy in mind, so putting 1234 as a decryption pass code in order to get to your Facebook app faster is not an option. This is the trench between user data and the enemy, so we made it pretty damn deep.

In addition, Secure Phone can be wiped in numerous ways, including manually from the device, remotely from our Secure Administration System (SAS), via sending a special message to either the Secure Email or the Secure Chat app, as well as automatically in case of entering wrong pass codes or losing connectivity with the server for some predefined period.

Of course, there are many more elements and layers of defence that we have implemented in Secure Phone to make it as robust as can be. More on that can be found on our website, as well as in our Secure Group Academy.