Android’s full-disk encryption just got much weaker—here’s why

Share this…

Unlike Apple’s iOS, Android is vulnerable to several key-extraction techniques. Privacy advocates take note: Android’s full-disk encryption just got dramatically easier to defeat on devices that use chips from semiconductor maker Qualcomm, thanks to new research that reveals several methods to extract crypto keys off of a locked handset. Those methods include publicly available attack code that works against an estimated 37 percent of enterprise users.

A blog post published Thursday revealed that in stark contrast to the iPhone’s iOS, Qualcomm-powered Android devices store the disk encryption keys in software. That leaves the keys vulnerable to a variety of attacks that can pull a key off a device. From there, the key can be loaded onto aserver cluster, field-programmable gate array, or supercomputer that has been optimized for super-fast password cracking.

The independent researcher that published the post included exploit code that extracts the disk encryption keys by exploiting two vulnerabilities in TrustZone. TrustZone is a collection of security features within the ARM processors Qualcomm sells to handset manufacturers. By stitching together the exploits, the attack code is able to execute code within the TrustZone kernel, which is an enclave dedicated for sensitive operations such as managing cryptographic keys and protecting hardware.


A third of enterprise Android phones exploitable

Both Google and Qualcomm are quick to note that both of the vulnerabilities involved—indexed asCVE-2015-6639 and CVE-2016-2431—have since been patched. The first was patched in Januarywhile the second was patched in May. Google also pointed out that it paid the researcher for his work through the company’s bug bounty program.

But researchers from two-factor authentication service Duo Security told Ars that an estimated 37 percent of all the Android phones that use the Duo app remain susceptible to the attack because they have yet to receive the patches. The lack of updates is the result of restrictions imposed by manufacturers or carriers that prevent end users from installing updates released by Google.

What’s more, Gal Beniamini, the independent Israeli researcher who authored the blog post and wrote the exploit code, said that many Android devices that were once vulnerable but later patched—including a Nexus 6 he tested—can be rolled back to their earlier, unprotected state. He suspects the reversion is possible if a device has an unlocked, or unlockable, bootloader. This is the case with both the Nexus 6, Nexus 5, and many devices sold outside of the US. (A Qualcomm spokeswoman disputed the theory, saying its platforms support anti-rollback mechanisms that manufacturers can use to block installation of older/outdated/deprecated software versions.) Whatever the cause, the rollback capability means that with slightly more work, an attacker can exploit many devices even after they’re patched. (The more recently released Nexus 5X and 6P also have unlocked bootloaders but were never vulnerable to begin with, Beniamini said.)

Not just Google that can mess around

Beniamini’s research highlights several other previously overlooked disk-encryption weaknesses in Qualcomm-based Android devices. Since the key resides in software, it likely can be extracted using other vulnerabilities that have yet to be made public. Beyond hacks, Beniamini said the design makes it possible for phone manufacturers to assist law enforcement agencies in unlocking an encrypted device. Since the key is available to TrustZone, the hardware makers can simply create and sign a TrustZone image that extracts what are known as the keymaster keys. Those keys can then be flashed to the target device. (Beniamini’s post originally speculated QualComm also had the ability to create and sign such an image, but the Qualcomm spokeswoman disputed this claim and said only manufacturers have this capability.)

“That’s significantly different than how iOS works,” Dan Guido, an expert in mobile device encryption and the founder and CEO of security consultancy Trail of Bits, told Ars. “What it means is that now you trust a second party, you trust somebody who built the software that holds the key. Maybe people didn’t realize that before, that it’s not just Google that can mess around with the software on your phone, but it’s also [Google partners], and it’s in a very significant way.”

He continued: Google has always been behind on full disk encryption on Android. They have never been as good as the techniques that Apple and iOS have used. They’ve put all their cards in this method based on TrustZone and based on the keymaster, and now it’s come out how risky that is. It exposes a larger amount of attack surface. It involves a third party in the full disk encryption, and all this extra software that handles this key could potentially have bugs that allow an attacker to read it back out. Whereas on iOS it’s very simple. It’s just a chip. The chip is the Secure Enclave, and the Secure Enclave communicates via this thing they call the[interrupt-driven] mailbox. And that basically means you put really simple data in on one end, and you get really simple data out the other end. And there’s not a lot else that you can do with it.

These two approaches are completely different. [On iOS] there’s no software to exploit to read the hardware key. On Android they expose the full-disk encryption key to a fairly complex piece of software this researcher has exploited.

Matt Green, a Johns Hopkins University professor specializing in encryption, agreed. The problem the FBI had after seizing an encrypted iPhone belonging to a gunman who killed 14 and wounded 22 in San Bernardino, California, was that the forensics experts had no way to remove the underlying UID key from the device. That meant the password that locked the key could only be cracked by entering it on the device itself, a slow and cumbersome process that risked triggering a built-in data-wiping feature.

“The way Apple builds their phone is they actually build that UID key into the silicon of the device so even if they can push a software update they can never actually extract it from the device short of using an electron microscope or something like that,” Green explained. “It sounds like in the Qualcomm TrustZone, that’s not true.”Beniamini said Android phones have a similar silicon-bound key dubbed SHK that’s used for some cryptographic functions. But rather than using the SHK to directly unlock an encrypted drive, the Qualcomm TrustZone uses the SHK to create a second key that exists as a software variable. It’s this second key that can be extracted through one of the methods outlined above. Duo Security researcher Kyle Lady has more in-depth explainers hereand here. According to a comment left in response to Thursday’s blog post, the lead developer of the freely available Hashcat password-cracking program is exploring the possibility of building in support for extracted disk-encryption keys. This would streamline attacks once a key has been extracted.

Beniamini said he wouldn’t be surprised if TrustZone implementations from chipmakers other than Qualcomm contain similar vulnerabilities.

“The design of the FDE key-derivation function is conducive to that, and I believe it was only meant to keep encryption keys on devices (keymaster’s original purpose), not to safeguard FDE,” he explained.

The take-away from the research is that Android’s full-disk encryption still provides meaningful protection as long as people use a strong password. But everything else being equal, iPhone disk encryption is probably more secure. Yes, the FBI was ultimately able to break the disk encryption on the San Bernardino shooter’s phone, but unlike the case with Android, that technique has yet to be made public, and it applied only to an older iPhone that didn’t have Secure Enclave. By contrast, an estimated one-third of Android phones are vulnerable to publicly released exploit code, and a much larger slice can be unlocked with the assistance of its manufacturers. For the truly paranoid, iOS is arguably a better bet.