Big news a few months ago: Google announced that all new devices which ship with Lollipop would have encryption enabled by default. Fast forward to today, and aside from Google’s own Nexus devices, none of the new Lollipop devices actually seem to have encryption enabled by default. It turns out that Google has quietly relaxed this requirement in the Android Compatibility Definition, from ‘MUST’ to ‘very strongly RECOMMENDED’.
Why? Performance, supposedly.
Our best guess at this point is that the encrypted-by-default requirement was relaxed to give OEMs more time to prepare their hardware for the transition. The performance problems can be offset by using faster flash memory, faster file systems like F2FS, and chips that are better at encrypting and decrypting data quickly, but phones and tablets take long enough to design that OEMs will need time to make these changes. Whether the change in policy was prompted by external pressure or an internal decision isn’t clear, but the performance explanation makes the most logical sense.
Ouch. It’s pretty clear Google wanted to quickly gain some positive press, especially after Apple announced it would turn encryption on by default in iOS, but failed to look at any possible performance repercussions. Sleazy move.
Not sleazy. Just incompetent.
It’s neither sleazy, not incompetent, it’s “pragmatic”.
Android is still targeting cheap, slow devices. It’s part of the appeal and leads to broad adoption. We have some amazing hardware in our pockets, but it’s not all amazing.
Encryption has a performance and power cost that can be quite noticeable.
They haven’t removed the capability, rather simply removed it as a compliance mandate to let the cheaper platforms still able to play.
The incompetence is not realizing this from day one. Now they have to backpedal rather hard.
I don’t think they will have to back pedal at all.
Google have it enabled by default in their phone and have allowed OEMs to disable it if they want. This means it’s the OEMs that will have to explain why they have chosen not to support this feature and not Google. Why target Google when it’s the OEMs that are at fault ? IMHO.
Well, look at it this way. Android runs on a plethora of devices. If they say “encryption for all!” and actually enable it on any device that is updated to Lollipop, then performance of the lower end devices will be poor, and everyone will say ‘boo, Android sucks, let’s go to Apple.’ but those same people who would do that probably have the lower end devices because they can’t afford the higher end ones, which means they wouldn’t be able to afford to move to Apple devices in the first place.
Kind of a lose/lose scenario. Either way, I figure both platforms suck in their own way.
I think the biggest loss is their PR wrote checks the SoCs couldn’t/OEMs wouldn’t cash. They weren’t ambiguous in it, either:
“The next generation of Google’s Android operating system, due for release next month, will encrypt data by default for the first time, the company said Thursday…”
They didn’t qualify it by adding “at least on our higher-end Google-brand phones. Cheaper models will be shit-outta-luck, or if, you know, your OEM/carrier decides not to do it for whatever reason.”
To do it efficiently requires hardware support. Unless they want to up the minimum a lot and prevent most Android users from updating, then they need to allow it to not be encrypted. Apple only makes high-end on the newest generations so they can rely on having the newest chips and everyone will just pretend they are not breaking their promise in similar ways when they ship older devices without encryption but with the newest OS, just like Android.
Yes. ARM64 has support for AES encryption, making it a lot faster. The Nexus 6 took a huge performance hit due to the default encryption. However, you can’t expect any shitty new midrange device to come with the newest SOCs.
Once booted how much data is transfered from and to disk!? Not that much I hope! and that should be reasonably fast. I have encryption on on my laptop and I don’t have any performance problems at all!
I recommend reading this: http://www.anandtech.com/show/8725/encryption-and-storage-performan…
Also, http://www.androidcentral.com/what-full-disk-encryption-android-lol… mentions this tidbit:
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.
I would assume that many low-to-mid-end phones can’t use H/W-assisted encryption/decryption either, and they just don’t have the CPU-grunt to do it in software.
Your laptop most likely does AES-encryption in hardware and even if it did it in software it’s going to be miles and MILES ahead of any low-to-mid-end cellphone in raw performance, so it’s quite obvious why there is such a difference.
Edited 2015-03-02 18:51 UTC
Why on earth would anyone want to encrypt a lolipop? this makes no sense…* That’s right it’s an Android phone.
Never mind!
According to Mr. Owl, it takes three licks to get to the center of a Tootsie® Pop.
How many licks does it take to get to the center of an encrypted Lollipop?
Edited 2015-03-02 19:51 UTC
It’s so that you’ll never be able to discover how many licks it truly takes to get to the chewy center!
Good.
I do not want my stuff to be encrypted, because any recovery attempt is made harder.
I do not carry government secrets in my device, so recovery is higher on my priority list than non-access to my non-sensitive data.
What I want is strong encryption of passwords (browser and app), a cookie policy that prevents XSSes and cookie theft, and the ability to remotely lock the device.
Edited 2015-03-02 20:01 UTC
Yeah, this. Mandatory disk encryption makes me very nervous – I’ve had to do “salvage what’s still readable”-recovery more than once, and even if I somehow had the keys it would still be unfeasible on an encrypted disk.
Edited 2015-03-02 22:09 UTC
1) If your SoC doesn’t have the circuitry for AES then your I/O will suffer tremendously.
2) Full disk encryption means you cannot use TRIM, which means your flash will degrade a lot faster.
3) Encryption for most people means … lost data vs. data security.
Do your math.
Are you sure about the TRIM thing? It should be possible to special-case empty blocks somehow – even if it dilutes the security a notch by making it easier to identify which blocks are in use or not.
Depends on where the encryptions sits, between disk and filesystem or is it part of the filesystem?
Though I guess a modern block level encryption layer could just implement TRIM itself and handle and forward that.
Carewolf,
It would depend on implementation, but there’s no technical reason Trim can’t work. Filesystem encryption like encfs would naturally inherit the Trim behavior of the host file system. These forms of encryption are a bit less secure than full disk encryption though because the metadata isn’t encrypted (ie you know the file dates/times/lengths/permissions/hierarchy/etc). This metadata could be matched to internet activity even without file contents.
An unneeded sector can be trimmed whether it’s encrypted or not. Dm-crypt does just that. Here’s an example where ext4 FS passes trim to LVM, which passes it along to dm-crypt, and then to the SSD.
http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-…
The problem that comes to mind is with something like Truecrypt’s hidden volume feature, which intentionally uses empty space to store hidden volumes that an attacker doesn’t know exists or not. Obviously those sectors couldn’t get trimmed or you’d loose the data. But if you trim everything normally except for anomalous hidden sectors, then it gives away the fact that a hidden volume is present.
NSA obviously has called Google to remove encryption by default.
Good job, NSA boys
they would be sued by now and we would be having a flame war on how bad Apple sucks. Lol.