Lollipop encryption

Keeping your bits and bytes as safe as possible through encryption is a complicated affair.

There's a lot of information out there about Android 5.0 Lollipop's "default" full disk encryption (FDE). Some of it is good information, some of it is bad information, and plenty of it is just repeated snippets of speculation. While this makes for good conversation — and FDE is something worth talking about — we wanted to break down the finer points into an easy-to-read discussion.

This isn't meant to be the be-all end-all document on Android encryption. Google has already posted that one. We're going to tackle the consumer-oriented questions we keep hearing. As always, use the comments for discussion so we all can learn a little something.

What is encryption?

Lollipop encryption

Encryption is the process of protecting data using an encryption key. Think of a password as a key, and the encryption is a very secure lock. You need the key to get in to do something. And while getting in without the right key is possible, it's not very likely. (Yes, any and every encryption system can — theoretically, at least — be defeated by patient and crafty individuals.)

On our Androids, all the user data on a device (since Android 3.0) can be encrypted. The data is actually encrypted on the fly, before it's ever written to disk. In turn, the data is decrypted before it gets returned to any program that asks for it. All you need is the correct key, which is password based using the device master password.

Changes in Lollipop

Lollipop encryption

While FDE has been available in Android since the ill-fated Android 3.x Honeycomb, Android 5.0 brings some pretty big changes and improvements in how it all works.

In Lollipop, FDE is done with a kernel feature that acts directly on the block layer of the storage. This means encryption can work on flash devices like eMMC storage — which have no native encryption features — because they present themselves to the kernel as a standard block device. Encryption isn't possible with file systems that talk directly with the storage (like YAFFS). The people who made your phone or tablet might have included a method to encrypt external storage (like the SD Card), but the Android AOSP deals mostly with internal storage. The algorithm used is 128-bit AES with CBC and an encrypted salt-sector initialization vector using the SHA256 hash function. The master key also uses calls to the OpenSSL library.

In other words, it's damned secure.

On the first boot into Android, your device creates a random 128-bit master key, then hashes it and stores it in the crypto metadata. This data is unlocked by your user passphrase. (And remember, folks, don't use weak passwords.) The resulting hash is also signed through hardware backing, such as TEE-based (that's Trusted Execution Environment) features like TrustZone. Prior to Android 5.0, the master key was encrypted based only on the user's password, which could be vulnerable to off-box attacks through ADB.

Interestingly, Google is not using the Qualcomm hardware cryptographic engine in AOSP or for the Nexus 6. This is inefficient as it forces CPU-based encryption and decryption during disk I/O (likely at every 512 byte interval) versus using Qualcomm's hardware-based performance features. We're not going to second guess why this is done, but know that OEMs are free to implement it as they like. We hope they will.

Google has done a lot to make full disk encryption on Android secure. All in all, they've done a pretty good job.

Performance issues

Lollipop encryption

You've probably heard about poor performance for disk reading and writing on Nexus devices with encryption enabled. It's true — when you need to encrypt and decrypt on the fly, disk I/O speeds are going to suffer. As mentioned above, Google is not using Qualcomm's hardware-based kernel features on the Nexus 6, which causes it to suffer even a bit more. But how bad is it?

Disk I/O in Lollipop is several times faster than is was in KitKat and previous versions of Android. Software optimization and device-specific code means that Android can read and write from the storage faster than ever. This is a very good thing that's mostly negated by slower I/O times due to encryption.

If you need to use FDE (or are forced to use it because you bought a new Nexus and don't want to install custom firmware) your performance is still going to be better (on paper) than it would have been on KitKat. It just won't be as good as it could be without encryption. In real-world use, most users we've talked to don't notice any device lag because of slow I/O. Your experience might be different.

If you want or need FDE, the trade-off is probably worth it.

Encryption isn't mandatory (and do you need it anyway?)

Galaxy Note 4 encryption setting

Anyone with a phone that already has the Lollipop update can tell you that Lollipop doesn't force you to use encryption. While the Nexus 6 and Nexus 9 (and possibly all future Nexus devices) ship with it enabled and no easy way to turn it off, phones that were updated to Lollipop — like the Galaxy Note 4 — do not automatically have full disk encryption enabled.

The same goes for new devices that are shipping with Android 5.x like the LG G Flex 2. The option is there should you want to enable it, but by default full encryption is turned off. This brings us to a choice — do we need full disk encryption?

Plenty of us will find full disk encryption useful. If you have sensitive information that you never, ever want to fall into the wrong hands on your phone, FDE is a godsend. For someone to get into your data, they must know your device password. No amount of fiddling over a wire is going to let them break in, and provided you used a strong password, your data is safe because after a handful of wrong guesses, everything goes on lockdown.

For others, just the standard lock screen security will enough. If we lose a phone, we can remotely wipe it via Android Device Manager or another utility, and if someone is able to go offline before we can wipe, then get lucky enough to bypass our lock screen password (it can happen), all they get is a few pictures and Google account access that we can quickly change a password on.

There also is the whole government snooping issue to think about. While most of us don't have a reason to fear any consequences for what we have stored on our phones, we still deserve a bit of privacy and protection when our personal data is concerned. Full disk encryption gets us closer to keeping our data secure from government agencies who think they need to see it.

Only you know if you need full device encryption.