Android 5.0 Data Better Protected with New Crypto System

There’s been much 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 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 with common stories of paedophiles and terrorists.

Meanwhile, privacy and security advocates are heralding the new disk-encryption schemes, which seem to equip consumers with meaningful 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 or no oversight.

Newest version of #Android, like #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” (L is both the roman numeral for 50 and the first letter of 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 in Android 5.0 for the first time.

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 lockscreen 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 cause people are too lazy to set long phone lock 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 go into it 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 typical 4 to 6 character password, you can decrypt user’s data literally in 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 апреля 2013

In Android version 4.4, Google moved toward a stronger crypto-system. Despite this, it is still based on PIN or password. So it is still possible to perform 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

In addition to enabling [full disk encryption] 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

Such attacks will not work for Android L. The exact reason for that is unclear, because there is not yet any available source-code of 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 sort of a 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, the most popular mobile OS system in the world finally becomes more secure, and that can only be a good thing.