Google quietly backs away from encrypting new Lollipop devices by default | Hacker News Reader

Google quietly backs away from encrypting new Lollipop devices by default

arstechnica.com

155 pointsprivong43 comments

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."

From: http://www.androidpolice.com/2014/11/20 ... ot-pretty/

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.

If so, I imagine it would also fit nicely with big.LITTLE designs.

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.

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

People did side by side comparisons on the Nexus 9 and the encryption made a huge difference:

http://www.androidauthority.com/nexus-6-device-encryption-pe...

http://www.reddit.com/r/nexus6/comments/2mufbm/huge_improvem...

Fixed your link

http://www.androidpolice.com/2014/11/20/anandtech-posts-side...

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.

Also disappointed about their promised privacy features that never made it: https://plus.google.com/+MaxHuijgen/posts/haKeEyEHR55

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.

They make more from data, then upfront payments.

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?

Google revinue is ~US$ 66.001 billion so they make ~9.54$ per person in the world.

However, I suspect actual users is probably closer to 2 billion than 7 billion. ex: ~1.17 billion people use Google search.

> promised privacy features

They were never promised. It was internal dev tools that accidentally got released.

From what I heard, the encryption was having a very noticeable impact on performance.

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.

And everyone will think they're secure anyway, since Google got lots of press for announcing they'll encrypt everything. Win-win for Google!

Interesting. I wonder why the iPhone doesn't have the same issue?

Apple controls the entire hardware stack on an iPhone

At the very least, iPhone 6 is ARMv8-A, so has AES instructions.

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)."

https://support.apple.com/en-us/HT202064

This should be a hardware requirement imposed by google then.

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.

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.

I was using encryption on 4.4.

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.

Pretty sure the ecosystem isn't ready for this!

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.

That could potentially be done at the hardware level, which would make it much harder to bypass.

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.

[1] http://resources.infosecinstitute.com/understanding-disk-enc...

Aha, that's really reassuring, thank you =)

I'd imagine that a sufficiently sophisticated attacker would be able to extract that random number somehow.

You can set your device encryption and screen unlock code separately already. Android also uses scrypt as a PBKDF.

How do you do this on stock Android?

Well one right way is to have a passphrase on boot, then switch over to PIN/swipe/whatever. Seems sorta obvious...

But, if Google just mandated TPMs, then a 4-digit PIN is fine as the hardware can perform a lockout/cooloff/self-destruct.

TPMs aren't super-hardened, but against losing your phone in a taxi, or random local cops trying to crack it, it's probably good enough.

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.

It's possible if you're rooted: https://play.google.com/store/apps/details?id=com.kibab.andr...

The pin unlocks the key in the TPM. If you brute force the pin (I hope) the TPM will wipe the key.

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.

[1] http://arstechnica.com/gadgets/2014/09/android-l-will-have-d...

The old standard is that many promises are made (by Google and others) on privacy that are false.

The new standard is that we're all aware of this and seeking better options.

You can simply encrypt the phone yourself (there's a simple button in the settings menu).

Reply on news.ycombinator.com