

Google quietly backs away from encrypting new Lollipop devices by default - privong
http://arstechnica.com/gadgets/2015/03/google-quietly-backs-away-from-encrypting-new-lollipop-devices-by-default/

======
nemothekid
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](http://www.androidpolice.com/2014/11/20)
... ot-pretty/

~~~
magicalist
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.

~~~
mschuster91
> 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.

~~~
magicalist
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.

------
matkam
Also disappointed about their promised privacy features that never made it:
[https://plus.google.com/+MaxHuijgen/posts/haKeEyEHR55](https://plus.google.com/+MaxHuijgen/posts/haKeEyEHR55)

~~~
wtbob
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.

~~~
tdkl
They make more from data, then upfront payments.

~~~
wtbob
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?

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

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

~~~
extra88
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](https://support.apple.com/en-
us/HT202064)

~~~
eyeareque
This should be a hardware requirement imposed by google then.

------
jwatte
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!

------
MBlume
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 =)

~~~
robin_reala
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.

~~~
MBlume
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.

~~~
x0x0
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...](http://resources.infosecinstitute.com/understanding-disk-encryption-
android-ios/)

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

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

~~~
skywhopper
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...](http://arstechnica.com/gadgets/2014/09/android-l-will-have-device-
encryption-on-by-default/)

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

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

