Default Storage Encryption Remains Optional In Lollipop Until Future Android Version

Fans of default storage encryption will be disappointed to learn that Google has postponed mandating default encryption for Android Lollipop devices until a future version, according to a paragraph from the Android Compatibility Definition document:

9.9 Full-Disk Encryption If the device implementation has a lock screen, the device MUST support full-disk encryption of the application private data (/data partition) as well as the SD card partition if it is a permanent, non-removable part of the device. For devices supporting full-disk encryption, the full-disk encryption SHOULD be enabled all the time after the user has completed the out-of-box experience. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android.

Last year, when Apple announced that iOS8 will encrypt the local storage of iPhones in a way that even the company can't decrypt, Google was quick to follow with a similar announcement for Android Lollipop. However, Google's decision seemed to be made in a hurry, and it later became clear that indeed, the decision was rushed.

Google said that all new devices running Android 5.0 will be encrypted by default, just like the Nexus 6 and the Nexus 9. Soon after these devices came out, many of their owners became frustrated that the performance wasn't as good as it should have been. It was later discovered that Android's default encryption was the culprit, which convinced many to disable the encryption.

Since then, Google seems to have updated its Android compatibility policies to say that OEMs should support storage encryption (they can't eliminate the feature from the OS), but it's up to them whether to enable it by default or not.

The main issue isn't really caused by encryption, but by the fact that devices need an AES crypto processor to encrypt the data without affecting the general performance. This is something the iPhone has had for years and why no one ever complained about its encryption performance.

Nexus 6's Snapdragon 805 came with a crypto-processor as well, but for some reason Google couldn't or wouldn't support it in Android 5.0. Because Google uses Nexus devices to define the next version of the AOSP operating system, it's possible there were some licensing issues with Qualcomm's proprietary firmware.

All ARMv8 chips from the low-end Cortex A53 to higher-end ones should support an AES crypto-processor, which should make encryption performance a non-issue for the devices being powered by these chips. However, even if we see new devices come to market with crypto-processors, it won't necessarily mean they will be encrypted by default, because Google is only making default storage encryption optional for now.

In a future version of the OS, probably Android M, Google should start mandating all OEMs to encrypt their devices by default. By then, OEMs should have plenty of warning and they should be ready to encrypt all of their devices with no impact on general system performance, thanks to ARMv8 or other custom crypto-processors.

Follow us @tomshardware, on Facebook and on Google+.

Lucian Armasu
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
  • house70
    Both my Nexus 6 and Nexus 9 are left encrypted by default. While there are some benchmarks that would imply a lower performance due to encryption, I have yet to see an objective report regarding impact in everyday usage and performance, i.e. nobody has come forward claiming that their device takes 15 ms to open an app while encrypted, while it takes only 10 ms to do it without encryption. Benchmarks are just that, and they do not reflect real life performance. Both my devices run perfectly to my naked eye and I prefer the added security of encryption. IMO, the sheer number of opened apps have a far greater impact on day-to-day performance than encryption.
    Reply
  • Solandri
    One annoying thing with this policy is that it treats internal storage and the microSD card the same. That is, if you encrypt internal storage, you must also encrypt the microSD card. Which makes it useless for transferring files between the device and your computer.

    My friend had been hoping to use his microSD card to transfer photos and movies he took with his phone to his computer. His workplace mandates that the phone have encryption turned on however, which effectively turned the microSD card into nothing more than extra internal storage. There's no option to encrypt one but not the other.

    I understand encrypted internal storage + unencrypted microSD has the potential for secured data to be copied to the microSD card. But even with the forced encryption, you can still transfer secured data to a (unencrypted) cloud data service (which is how he's transferring his photos and movies). So I don't really see what's being gained by forcing the microSD card to also be encrypted.
    Reply
  • koga73
    I'm all in favor of encryption however there needs to be a way to decrypt the storage device from a PC. My last phone was encrypted and when I broke the screen I was unable to decrypt the device... and when plugging the device into a PC the internal storage doesn't get mounted because it hasn't been decrypted yet. So I ended up losing everything on it
    Reply
  • Peter Cockerell
    No, it's not an annoying part of this policy, which states clearly that the SD drive only needs to be encryptable (not encrypted, as yet) if it's non-removable (i.e. the "emulated" partition). It doesn't refer to removable SD cards. Your friend is subject to his employer's policy, probably communicated via an ActiveSync Provision command specifying the RequireStorageCardEncryption policy, enforced by Device Administrator, or some equivalent policy enforcement. This is different from what Google is mandating.
    Reply
  • dmb77
    Does that mean the FBI and other government agencies will be unable to retrieve data as well? That doesn't sound good.
    Reply
  • house70
    15410569 said:
    Does that mean the FBI and other government agencies will be unable to retrieve data as well? That doesn't sound good.

    Yep, doesn't sound good... sounds excellent.
    Reply