From the article comments, it looks like a hardware issue:
"Apparently, Google has not merged the various drivers that optimize Qualcomm's QCE module for encryption and decryption into AOSP. The generally-assumed reason is that this code is proprietary. Without these optimizations, the Nexus 6's hardware decryption module on the Snapdragon 805 is essentially hamstrung."
Also from the comments, ARMv8 requires AES instructions, so having the drivers around won't be a problem in the future. This appears true from the ARMv8-A docs, but can someone more knowledgeable confirm this?
Supposedly this is why the Nexus 9 (which is ARMv8-A) does have default encryption and suffers no performance hit.
> Also from the comments, ARMv8 requires AES instructions
Just random guessing around (I have no actual knowledge)... if the mentioned encryption drivers are required for performant cryptography, then it is likely that the encryption is done by a separate core/chip/soc module, totally transparent to the CPU and maybe also battery-saving.
Right, sorry, I think the claim is that since ARMv8 requires AES instructions, it no longer needs separate encryption hardware, and the proof is that the Nexus 9 supposedly doesn't have the encryption performance hit that the Nexus 6 does.
Native instructions would also require one less closed-source driver, which is also a win.
But the article shows that Google just made FDE a "SHOULD" and a "RECOMMEND" for OEMs. And the Nexus 6 supposedly does ship encrypted. It's just new phones coming out aren't, because OEMs aren't forced to.
As an actual product line, Google seems to have mismanaged Android pretty terribly, sorta like MS did with Windows for a long while. From a get-it-in-tons-of-peoples-hands, I suppose it's OK that each OEM can ship a messed up version that's an unknown quantity for consumers.
Seems weak to me. I doubt the cipher latency is noticeable even if done in well-optimised software. How much I/O to flash does a phone, once booted, really do anyway? There may be a battery life argument...but pfft, most of the battery consumption isn't CPU
And what's a real shame is that they could still make money off of private users. It's possible to offer targeted ads based on unencrypted metadata and hashed keywords (c.f. some of the interested work GNUnet has done on search); they could also offer 100% private (client-side encrypted) accounts for an upcharge. Google's revenue per user is reputed to be roughly $10 per annum; I'd be willing to pay $50/year for client-side encrypted everything.
Yes, it'd cost money to maintain that infrastructure, but I bet there are enough people who'd want to do it, and would be willing to pay enough to do it, that it'd be profitable.
The revenue-per-user number (supposedly) reflects the revenue they're getting from that data. If they're making $X/user from data+payments, and Z users propose paying $XY, where $XYZ is more than sufficient to pay for the infrastructure and yield a tidy profit, why not do it?
I tried encryption on my HTC One M7, currently running 4.4, and performance was sufficiently bad to make the phone barely usable. Then I needed to factory-reset the phone to turn encryption off.
Because iPhones have had encryption hardware since the 3GS (2009).
"Data protection is available for devices that offer hardware encryption, including iPhone 3GS and later, all iPad models, and iPod touch (3rd generation and later)."
this is the most likely scenario. The reality is most people notice and care about performance. The majority of people don't care about privacy and encryption. Its still available to those that want it.
Yes, but only because it wasn't backed by hardware-accelerated encryption (like the iPhone is).
I feel like this is mostly Qualcomm's fault, but also Google's for announcing a product (FDE) that wasn't actually fully ready to come to market (typical half-assism from Google, I would say).
This pisses me off because many people now might not want to use encryption anymore even when it does get hardware accelerated and the issue is solved, because of all the articles that "encryption slows down your Android devices" Google has caused to appear now.
Samsung/Sprint pushed a system update that wasn't tested with full device encryption. My device was bricked and not recoverable. Sprint required me to pay repairs.
How much of a point is there to device encryption anyway? I have a four-digit PIN -- if someone has access to my phone aren't they just going to try 10,000 PINs and crack the phone pretty much instantly?
EDIT: according to x0x0 things are better than I naively imagined =)
Depends on whether it’s tarpitted or not (i.e. do subsequent attempts to unlock the device have a progressively longer cool down time before another unlock request can be made). Also, Apple for example will wipe the device after, I believe, 10 failed attempts? It’s possible to defeat 4-digit keys in 10 attempts but it’s not likely.
Right, but that's relying on the OS to lock the attacker out, and you can do that without encryption -- the point of encryption is that even if someone bypasses the operating system and reads the disk directly, they can't read your files. If someone has a full image of your phone's flash storage, they can try PINs as fast as they want.
I'm not using the right words, but it isn't that easy.
On modern phones, even if you have an image of the phone's storage, the code you enter is merged (wrong word) with a large random number stored in an externally inaccessible chip in the phone (different for each phone, obviously). This large random number is then used as a seed to encrypt the drive. So it's not anything like just extracting the disk image then brute force attempting the 10000 valid codes from 0000-9999.
edit: here is a better explanation
Apple was a front runner in implementing some sort of encryption long before
others even thought about it. Apple uses a 256-bit device-unique secret key
(UID) stored in the phone’s hardware, where it’s hard to extract from. Apple
says this UID is unique to the device and it doesn’t store these values. It
also says that no software or hardware can read this key. This UID is mixed
with the passcode to generate a new key (passcode key) to secure data on the
device. Unlike Android, this UID key can’t be extracted from the device, so
all the brute forcing attempts have to be done on the device itself. [1]
So I would guess it's reasonably secure to non-governmental adversaries. If you're worried about governments, the US now supports torture (the only person punished for torture during the war on terror was a whistleblower), so the NSA is free to torture your code out of you.
Is this now possible? Last time I checked Android required that your boot passphrase is used as your screen unlock method. It's the main reason I haven't switched over to encrypted on my N5.
This doesn't seem _that_ bad. I was under the impression that it would be up to the OEM who is putting Lollipop on their own devices, anyway. By providing the option they can ensure they don't get tons of heat from OEMs who haven't prepared their hardware for this.
It sounds like their policy is still default encryption for the Nexus 6, with the plan to make all Android devices support default encryption eventually. To me, that's actually better news than I had originally thought it was.
This seems right to me. The headline claim that Google was going to "require" encryption on all Lollipop devices contradicts the linked Google blog posts as well as Ars's own headline from when the announcement was made[1].
"On by default" is not the same as "required of OEMs". No one should be surprised that the OEMs might change the defaults, as that was sort of the point of Android at least at first.
"Apparently, Google has not merged the various drivers that optimize Qualcomm's QCE module for encryption and decryption into AOSP. The generally-assumed reason is that this code is proprietary. Without these optimizations, the Nexus 6's hardware decryption module on the Snapdragon 805 is essentially hamstrung."
From: http://www.androidpolice.com/2014/11/20 ... ot-pretty/