Android 5.0 Data Better Protected with New Crypto System

There’s been a lot of hoopla in recent weeks over claims from Apple and Google that user content, stored in the latest iterations of the iOS and Android operating systems, is encrypted in such a way that neither company has the capacity to decrypt the locally stored information.

Crypto By Default

Law enforcement agencies are not happy about this new reality, because it means that even with a warrant, they’ll have no sure-fire way of compelling users to decrypt locally stored data. So they’ve been parading their officials around in a not-so-veiled attempt to scare the public – surely with common stories of pedophiles and terrorists – into believing encryption is bad and dangerous.

Meanwhile, privacy and security advocates are heralding the new disk-encryption schemes, which seem to equip consumers with real mobile data-security.

Some will see these moves as reckless; others will see them as obvious reactions to an environment where it’s become entirely too easy for the government to collect prosecutorial information with little to no oversight.

The newest version of #Google #Android, like #Apple #iOS, will enable full #crypto by default

Tweet

We wrote about Apple’s new, default-enabled encryption earlier this month, and you can read that article for more on the law enforcement angle. Now it’s time to talk technically about the by-default encryption that Google is touting as part of its newest Android Lollipop, also known simply as “Android 5.0” or “Android L” (because L is both the roman numeral for 50 and the first letter of the word “Lollipop”).

A Brief History of Android Crypto

According to Nikolay Elenkov of Android Explorations, Android users have had the option to deploy full disk encryption (FDE) since Android 3.0, also known as Honeycomb. Android’s FDE offering then remained largely unchanged until Google fortified it in Android 4.4. They will strengthen that cryptographic system yet again in Android L, but more importantly, they are also turning FDE on by default for the first time in Android 5.0.

The initial encryption scheme deployed by Google in Android was apparently quite secure. However, its implementation in the software, as is so often the case, is where weaknesses arise. Particularly, the security of this encryption scheme depends almost entirely on the complexity of the disk encryption passphrase and its susceptibility to brute-force attacks.

http://instagram.com/p/ptPZ2dv0Fj/

“If it is sufficiently long and complex, bruteforcing the encrypted master key could take years,” Elenkov explains. “However, because Android has chosen to reuse the lock-screen PIN or password (maximum length 16 characters), in practice most people are likely to end up with a relatively short or low-entropy disk encryption password.”

In other words: the strength of the disk encryption on Android was as strong (or weak) as your lock-screen password. And in most cases it is really weak because people are too lazy to set long lock-screen passwords.

A built-in rate limiting mechanism made brute-force attacks impractical because an attacker would be locked out after a certain number of login attempts. Of course, Elenkov circumvented this protection. If you want to wade into the details about how he managed this, feel free to read his analysis, but we won’t get into that here. The point is: there is a way of brute-forcing weak PINs or passwords in order to decrypt content stored on Android devices.

Again, this attack would be much more difficult to perform against a strong password. But if you have a typical 4 to 6 character password, you can decrypt users’ data literally in only a few seconds.

Hashkill now cracks Android FDE images master password. Speed is ~135k on 6870, ~270k/s on 7970. Android FDE is weak. pic.twitter.com/mhcvEuEP48

— gat3way (@gat3way) 28 April 2013

In Android version 4.4, Google moved towards a stronger crypto-system. Despite this, it is still based on a PIN or password. So it is still possible to perform an attack and ultimately brute-force weak PINs and passwords, though in Android 4.4 it took a matter of minutes rather than seconds.

Some varieties of Android 4.4 allowed users to create a separate encryption password. In this way the barrier to entry was increased, because users with separate encryption passwords were protected by two barriers (lock-screen and crypto passwords).

Enter Lollipop

Such attacks will not work for Android L. The exact reason for that is unclear, because there is not yet any available source-code for the operating system. Elenkov’s analysis led him to conclude that decryption key derivation is no longer based purely on a user’s passphrase, PIN or lock-screen password. Instead, it seems decryption in future varieties of Android will be based only in part on the user’s lock-screen PIN or password.

Elenkov believes there will be a kind of second factor of authentication. So, in the past, the PIN or passcode alone derived the decryption key. Now, it seems the password or PIN plus some built-in, possibly hardware-based credential, derives the decryption key. Thus, brute-forcing a password may still be possible, but it won’t decrypt encrypted disk space.

TL;DR

“In addition to enabling FDE out of the box, Android L is expected to include hardware protection for disk encryption keys, as well as hardware acceleration for encrypted disk access,” Elenkov concludes. “These two features should make FDE on Android both more secure and much faster.”

In other words, most popular mobile operating system in the world finally becomes more secure.