Next Android To Enable Local Encryption By Default Too, Says Google

An anonymous reader writes The same day that Apple announced that iOS 8 will encrypt device data with a local code that is not shared with Apple, Google has pointed out that Android already offers the same feature as a user option and that the next version will enable it by default. The announcements by both major cell phone [operating system makers] underscores a new emphasis on privacy in the wake of recent government surveillance revelations in the U.S. At the same time, it leaves unresolved the tension between security and convenience when both companies' devices are configured to upload user content to iCloud and Google+ servers for backup and synchronization across devices, servers and content to which Apple and Google do have access.

Comments

show stopper

[multi io]

The device encryption feature is apparently designed to always use the lock screen password. So you're forced to have such a password, which you have to enter every time the device comes out of sleep mode, AND (much worse) it breaks essential apps like SkipLock that want to disable the lock screen under certain conditions, e.g. when you're within range of a known WiFi network, thereby relieving you of the need to enter your PIN about 5,000 times a day while you're sitting on your couch at home.

See also https://code.google.com/p/andr...

Unfortunately, this is a total show stopper for full device encryption.

Re:Really?

[swillden]

Google has pointed out that Android already offers the same feature as a user option and that the next version will enable it by default.

Why isn't it already the default setting?

(Android Security Team member here... though these are my own perceptions and opinions, not an official statement.)

Two reasons:

First, because it's not completely trivial to make it work correctly, all the time, every time, on hundreds of different devices. Android uses dm_crypt, so the foundation is solid, well-proven code, but that doesn't mean there aren't tricky corner cases. With the huge number and variety of Android devices out there, you can be certain that if there's a way it can go wrong, it will. So, conservatism suggests it's a good idea to make it optional for a while and shake out any issues. It's been optional for three years now, and is in use on many devices (I don't know how many; I'd guess tens of millions, though), so it's time to take the next step.

Second, performance was a problem. Not run-time performance -- AES is really fast -- but the initial encryption required reading and writing many gigabytes so it took a long time just to do that much I/O. Encrypting by default means that either the device has to be encrypted in the factory, which would be a major production bottleneck, or else users would have to wait 20 minutes for their phone/tablet to start up just after they unbox it. That's a bad user experience. For L this was optimized so it only encrypts blocks that are in use. Since on a new device very little of the data partition is in use, very little has to be encrypted. That makes the initial encryption very fast (a few seconds).

There's actually another device encryption-related improvement coming in L. I'd love to describe it in detail since I worked on parts of it, but the article doesn't mention it so I'll hold off.

Re:Good

[Mike Buddha]

iOS, like Android, only encrypts all data if a user opts to put a pin in. iOS8 might be different, but all prior version of iOS only encrypted when a pin was entered.

Re:Are they going to fix the bugs?

[AmiMoJo]

I have a Nexus 5 with a long boot time encryption password and a shorter unlock pin. Seems it was already fixed.