Google's 'encrypted-by-default' Android is NOT encrypting by default

Last year, Google said Android 5, codenamed Lollipop, will encrypt the contents of smartphones and tablets by default. Now it's had to do some backtracking. In short, despite Google's boasts that Lollipop will encrypt handhelds' data by default "out of the box," that simply isn't being enforced on all devices running Android 5 …

[Anonymous Coward]

I don't really like Apple/iOs

Mostly because I hate the "getting nickeled-and-dimed" sensation I get from buying iPhone gear and accessories.

However, this might get me to change, and I should probably be thinking about an upgrade on my 2+ year old Android phone anyway.

[cashxx]

Re: I don't really like Apple/iOs

I'd rather have that sensation than Google scanning through all my documents and selling me as their B!tch to the highest bidder feeling! And not feeling truly safe at all with most of the malware/viruses being pointed at Android and lack of updates and Google leaving me being out in the cold in the 60% of users it refuses to update for so they are secure! So Android truly is open as in WIDE open!!

[ThomH]

Re: I don't really like Apple/iOs

On malware/viruses: I don't believe Android has a significant security problem, it just doesn't have a gatekeeper. The benefit is your freedom to download a greater diversity of apps, the detriment is that you have to look out for yourself. Nowhere near every app with a problem has been some dodgy hack from a Russian warez site but you can be confident that Dropbox, Facebook, Desert Golfing, etc, when downloaded from Google or Amazon or equivalent, are safe.

On disk encryption: if all we're arguing about is on-by-default then if it's something you care about just for you it's no big deal.

So I think that just leaves those who think non-technical people should be able to assume protection. I think they should. But is that Google's responsibility to police or should it be left to the market to decide?

[Sandtitz]

Re: I don't really like Apple/iOs @ThomH

"On malware/viruses: I don't believe Windows has a significant security problem, it just doesn't have a gatekeeper. The benefit is your freedom to download a greater diversity of apps, the detriment is that you have to look out for yourself. Nowhere near every app with a problem has been some dodgy hack from a Russian warez site but you can be confident that Dropbox, Facebook, Desert Golfing, etc, when downloaded from Google or Amazon or equivalent, are safe."

See what I did there?

[Anonymous Coward]

Re: I don't really like Apple/iOs @ThomH

> See what I did there?

You ignored a great deal of recent history regarding critical security flaws in the base install of Windows operating systems?

Microsoft doesn't release patches for software which users download themselves from "Russian warez sites" and such. Nevertheless, "Patch Tuesday" happens every month in the Microsoft world, and regularly includes critical security fixes.

[quarky]

Re: I don't really like Apple/iOs @ThomH

Didn't I see a certain AV vendor release stats showing that there were more vulnerabilities found in MacOS, iOS ,and Linunx, last year than in Windows?

[Anonymous Coward]

Re: I don't really like Apple/iOs

"I don't believe Android has a significant security problem"

Come on, it's based on Linux and Java - two platforms both with one of the highest vulnerability counts in their class. Keeping Android secure is like trying to hold back water with collanders and thinly sliced Swiss Cheese...

"You ignored a great deal of recent history regarding critical security flaws in the base install of Windows operating systems?"

The Linux kernel had more vulnerabilities than Windows did last year. And that's without even looking at Java or everything else deployed in Android with the kernel...

[wikkity]

Re: Come on, it's based on Linux and Java

Eh, no it's not based on java at all. There is no java runtime, the only java related aspect is that the programming _language_ of choice is java.

[CFWhitman]

Re: Come on, it's based on Linux and Java

"Come on, it's based on Linux and Java - two platforms both with one of the highest vulnerability counts in their class. Keeping Android secure is like trying to hold back water with collanders and thinly sliced Swiss Cheese...

"The Linux kernel had more vulnerabilities than Windows did last year. And that's without even looking at Java or everything else deployed in Android with the kernel..."

This is utter nonsense based on a lack of technical understanding, wishful thinking, and gullibility.

The article that claimed that the Linux kernel had more vulnerabilities than Windows did last year took the vulnerabilities of every version of the Linux kernel still being supported and added them together as though people ran several versions of the kernel at the same time (not to mention as though none of the same vulnerabilities could be in two different versions of the kernel). If you appropriately restrict the vulnerabilities reported to single versions of the kernel, then suddenly the numbers become quite low. (Of course, that the numbers are actually lower than Windows doesn't tell us very much because they're not really comparable, but that's another story).

When it comes to Java, all the famous "Java vulnerabilities" are regarding the Java sandbox for Web applications. That is, the vulnerabilties are regarding taking applications you don't/can't trust at all and trying to run them safely anyway. Of course, Android isn't running actual Java. The virtual machine that it is running isn't being sandboxed in the first place because the applications are supposed to be trusted. There can't be security holes in a sandbox that doesn't exist. The sandbox doesn't exist for conventional trusted apps on iOS, Windows, OS X, Linux, etc., etc. either.

This is also a reason why conventional Java apps on other systems aren't actually security risks any more than any other conventional apps because you already trust them. It's only letting Java run in your browser that is specifically more of a risk.

If you want to criticize Android for being used as a tool for Google to get your information and use it for marketing purposes, then fine, but at least base the criticism on something real and accurate.

[Test Man]

Re: I don't really like Apple/iOs

"I'd rather have that sensation than Google scanning through all my documents...<snip!>"

Shut up.

[Charlie Clark]

Re: I don't really like Apple/iOs

However, this might get me to change, and I should probably be thinking about an upgrade on my 2+ year old Android phone anyway.

Or you could just enable encryption yourself (if it isn't done already). Personally, while I think encryption of data on device by default is good, for most people I reckon it's more important to encrypt network traffic. Apple and Google will happily encrypt your device and just as happily read your address book, calendar, e-mail, text messages, etc.

[Anonymous Coward]

Re: I don't really like Apple/iOs

"Well, part of the reason is that Android doesn't have all the drivers to take advantage of AES acceleration in the chips powering smartphones and slabs"

Finding Linux drivers has always been a nightmare compared to say Windows. I note that Windows Phone enables full device encryption out of the box...

[Anonymous Coward]

Re: I don't really like Apple/iOs

I note that Windows Phone enables full device encryption out of the box...

Device encryption is available in Windows Phone 8.1, but it must be set up at the enterprise level. In order to set up encryption, users must connect the phone to a network running Exchange ActiveSync and choose “RequireDeviceEncryption.”

So, yes it does, but most users cannot even turn it on even if they want to (and I am one of those users). At least with Android, I could.

I understand they have promised Windows 10 will make encryption available to all. If not, my next renewal will be an iphone, despite my general dislike of iOS.

[Anonymous Coward]

Re: I don't really like Apple/iOs

"So, yes it does, but most users cannot even turn it on even if they want to (and I am one of those users). At least with Android, I could."

Not true. You can enable it fairly easily via a free Office 365 trial:

Step 1: Create an free Office Account 365 at https://office.microsoft.com/en-us/business/office-365-small-business-premium-office-online-FX103037625.aspx (other plans will work to)

Step 2: Login into Office 365 https://i.imgur.com/rvJIvBd.png

Step 3: Login into the Admin exchange area, click Admin - Exchange https://i.imgur.com/UK0kqW3.png

Step 4: Select mobile - mobile device mailbox policies - Edit https://i.imgur.com/zJH5t1o.png

Step 5: In the popup window you need to modify both tabs; general and security

Step 5.1: general tab - both boxes checked (allowed)

Step 5.2: security it should look like this, wipe part is optimal and can be unchecked https://i.imgur.com/6xMEJW4.png

Step 6: Check the policy https://i.imgur.com/djmVUDW.png

Now you need to connect to Office 365 - open the Office app on your Phone:

Step 1: Select Office 365 https://i.imgur.com/QNd1C4yl.png

Step 2: Select Set up https://i.imgur.com/uZakUlPl.png

Step 3: Login https://i.imgur.com/Dd5JjZll.png

You should be able to see a new OneDrive and Sharepoint link in the Office app or recive a notification. Sometimes it doesn't sync so you might need to add the E-Mail account. Just go into Settings - email+accounts - add an account - select Exchange and sing in with the details you used before https://i.imgur.com/Dd5JjZll.png

Now go to Settings - storage sense - you should see "encypted" in the phone area https://i.imgur.com/AenJm5yl.png Viola!

[NoneSuch]

Re: I don't really like AES

Any encryption solution depending on AES is crap. I want to choose the encryption method and key strength that goes on my phone. Google gives us free choice from a list of one.

[shonangreg]

Re: I don't really like Apple/iOs

If I cannot get a Nexus for my next phone, I'll go with an iPhone and tether to my Nexus 7 for android things. Carrier's excessive control over phones is about as bad as Apple's walled garden.

[James 51]

Blackberries have had this for years. Only problem is that you couldn't use it and blackberry protect on the same device.

[Mark 85]

I'm shocked.... shocked I say!!!

For the first time in a long time, El Reg did not refer to Google as the "Chocolate Factory".

[Anonymous Coward]

Re: I'm shocked.... shocked I say!!!

They have gone all corporate and dropped the cuddly crackpot image.

Even "don't be evil" is no longer their mantra.

[Anonymous Coward]

Re: I'm shocked.... shocked I say!!!

Yes, and there was nothing dismissive of climate change, or justification of tax dodging by billionaires.

It's all getting a bit 'Guardian' for my liking.

[cashxx]

Just goes to show....

Just goes to show that it was an after thought and the only reason they said "we are doing this too" is because Apple is doing it!

[ThomH]

Re: Just goes to show....

There shouldn't be any shame in responding to how consumers receive a competitor's product.

[Anonymous Coward]

Re: Just goes to show....

So long as you deliver what you promise, otherwise you're making a vapourware statement.

[Andy Tunnah]

VERY surprising

Not at them backing down, nope not at all.

The surprising thing is that not only are Apple doing something first, but they're also doing it best, even though it doesn't benefit them in some way (although actually them being able to say "nuh uh sorry mr policey-man can't help you" and not have to retrieve people's files is a plus to them).

I don't really see this as Google backing down as such..but you can sure as hell bet every itard will put it that way.

[T. F. M. Reader]

Headline a bit misleading?

The way I read it this does not mean that after an "attitude readjustment" from NSA or advertisers or both Lollipop devices will not have full disk encryption enabled out of the box. Most probably will, while some, presumably cheaper ones, may leave the setting off.

So between 4.4 and 5.0 Google realized that since their model, as far as I understand it, allows basically anyone to make an Android device, then with all their power they cannot really force all device manufacturers to include HW encryption accelerator. This makes the use of SHOULD quite proper under RC2119 (they refer to it). To quote the latter:

SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Paranoid as I am, this does not sound like "the BASTARDS are selling me out to NSA/advertisers AGAIN!" They are, of course, but disk encryption is probably irrelevant for that purpose. All it protects you from is someone who gets hold of your device and tries to read the disk bypassing the screen lock. Or something.

Apple can afford to use RFC2119 MUST in their internal requirements documents.

[Anonymous Coward]

Google can too require it

Make it a condition of getting the Google apps, Google Play, etc. installed. There are already a lot of conditions Google puts on OEMs like this, and they tighten it up further on every Android release.

They shouldn't have let lousy hardware be an excuse - the phones with lesser hardware could stick with Android 4.4.

[Anonymous Coward]

Re: Google can too require it

Some of the low end shovelware Android phones can barely run the OS as it is. Doing CPU bound encryption will reduce performance and the battery life.

You really need some sort of chip to do the encryption.

[Anonymous Coward]

Re: Google can too require it

So those low end shovelware Android phones would have had to stick with 4.4 instead of being allowed to use 5.0. So what? As 4.4 becomes longer in the tooth over time market pressures will force them to want to upgrade, and they'll have to do what is necessary to support encryption.

Doing it this way Google totally abdicated their responsibility to their users, as even high spec phones like the new Galaxy S6 do not encrypt by default. How is that in anyone's best interest? If Android 5.0 didn't give them the choice, they would have had to enable encryption.

Samsung didn't want to, because boo hoo it'll hurt their benchmark scores, and they're obviously worried about their new Exynos CPU's performance given the lies they spread about supposed heat issues with the Snapdragon 810 (see semiaccurate.com for a good writeup on this from one of the very few tech journalists that actually does journalism instead of repeating rumors & press releases like 99.9% percent of them, El Reg included)

[David 164]

Re: Google can too require it

That still results in the same thing happen, android devices without encryption only as an added bonus Android with no encryption and no security updates.

[Any mouse Cow turd]

it's a shame...

... that Google don't have any world class developers in its company. If they did then maybe they could (reverse) engineer a driver for the AES part of the chip. Maybe they could even open source it for all the world to keep us safe from snooping. Oh, there goes the alarm clock, time to stop dreaming...

[Richard 12]

Re: it's a shame...

I'm certain that it would be technically possible for Google to do, and pretty sure that they employ people who are good at it.

However, I'm also pretty sure that doing so would have simply got them sued, gaining them nothing.

This type of limitation is usually legal, not technical.

(There are several features we've been forced to remove from our products due to stupid patents that should never have been granted. Unfortunately, the court would have been in Texas, so...)

[Anonymous Coward]

Re: it's a shame...

or they could just, you know, license it?

[Charlie Clark]

Re: it's a shame...

or they could just, you know, license it?

Google doesn't decide which chips companies use in their devices and, therefore, it doesn't pay for the licences. Maybe this will encourage more companies not to use Qualcomm's chip which might not be such a bad thing considering their close relationship with the US military.

[Anonymous Coward]

Re: it's a shame...

It's an advert company.

[Anonymous Coward]

LOL, the never ending Android fragmentation.

Apple at least provide what they promise in this case.

[Anonymous Coward]

Wow, you wrote 'LOL', do people still do that?

[RyokuMas]

One of my co-workers uses it in everyday speech...

/headdesk

[Jim E]

How does this work exactly.

So where does the encryption key come from when you encrypt a phone? The entry PIN (or pattern in Android). Not much entropy there. Is there a key stored on the phone? Also flawed. I'm genuinely curious. Or are they just encrypting traffic with SSL?

[Warm Braw]

Re: How does this work exactly.

The phone creates "a randomly generated 128-bit master key" when encryption is turned on, this is used to encrypt the data partition. If you create a PIN/password, this is used to encrypt/decrypt the master key (to protect it against discovery), but the key itself is not changed.

[Phil Endecott]

Re: How does this work exactly.

Apple have a doc describing their approach here:

https://www.apple.com/br/privacy/docs/iOS_Security_Guide_Oct_2014.pdf

See page 11:

Passcodes

By setting up a device passcode, the user automatically enables Data Protection. iOS supports four-digit and arbitrary-length alphanumeric passcodes. In addition to unlocking the device, a passcode provides entropy for certain encryption keys. This means an attacker in possession of a device can’t get access to data in specific protection classes without the passcode.

The passcode is entangled with the device’s UID, so brute-force attempts must be performed on the device under attack. A large iteration count is used to make

each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds. This means it would take more than 51⁄2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers.

The stronger the user passcode is, the stronger the encryption key becomes. Touch ID can be used to enhance this equation by enabling the user to establish a much stronger passcode than would otherwise be practical. This increases the effective amount of entropy protecting the encryption keys used for Data Protection, without adversely affecting the user experience of unlocking an iOS device multiple times throughout

the day.

To further discourage brute-force passcode attacks, the iOS interface enforces escalating time delays after the entry of an invalid passcode at the Lock screen. Users can choose to have the device automatically wiped if the passcode is entered incorrectly after 10 consecutive attempts. This setting is also available as an administrative policy through mobile device management (MDM) and Exchange ActiveSync, and can be set to a lower threshold.

On a device with an A7 or later A-series processor, the key operations are performed by the Secure Enclave, which also enforces a 5-second delay between repeated failed unlocking requests. This provides a governor against brute-force attacks in addition to safeguards enforced by iOS.

[Anonymous Coward]

Re: How does this work exactly.

"So where does the encryption key come from when you encrypt a phone?"

In a secure phone design, from a TPM chip as part of Secure Boot.

[anonymous noel coward~]

Missed opportunity

I recently acquired a Galaxy Note 4 and was thrilled to discover the new Private Mode, which hides certain content until a pattern, password or fingerprint is used to decrypt it. I loved the idea of protecting important data without constantly needing to unlock the phone for day-to-day stuff like calls and texts.

Unfortunately it will only really protect the content that doesn't matter to me, and won't work on what does. I don't care about encrypting my photos or music, I do care about someone nicking my phone and browsing through emails, facebook, or using saved data in Chrome.

Unfortunately Private Mode doesn't work for any of this. It would have been far more relevant if you could set specific apps to only run under this mode, rather than just hiding embarrassing holiday snaps or your taste in music.

[Matt Piechota]

Re: Missed opportunity

"I recently acquired a Galaxy Note 4 and was thrilled to discover the new Private Mode, which hides certain content until a pattern, password or fingerprint is used to decrypt it. I loved the idea of protecting important data without constantly needing to unlock the phone for day-to-day stuff like calls and texts."

Upon upgrading my Nexus 7 (first gen) to Lollipop it prompted me to set up auto unlock, where the device would skip the passcode if a paired Bluetooth device was in range (in my case, the Bluetooth audio adapter on my speakers. Maybe you should be looking for a Bluetooth fob if this bothers you enough.

http://www.amazon.com/Kensington-Proximo-Bluetooth-Tracker-Samsung/dp/B00FQQ4PNQ

[Anonymous Coward]

See https://www.youtube.com/watch?v=2gmdRlg0vag for tests on Nexus 5 encryption overhead. The bottom line is in some situations responses are slower but in real word usage the delays are so slight you'd probably not notice - worst case one or two seconds to start a game. Only when running benchmarks do differences become significant - but that's a pretty artificial situation.

[Anonymous Coward]

"The bottom line is in some situations responses are slower but in real word usage the delays are so slight you'd probably not notice - worst case one or two seconds to start a game"

And the impact to battery life?

[Dan 55]

Android userunfriendliness

So all I need to do before purchasing is look at a table with chipset and phone model to determine if a) there's no chance of hardware encryption, b) there might be hardware encryption in the near future with the next phone update if the chipset manufacturer obliges with a binary blob and the manufacturer feels like enabling it, or c) it's a Nexus 9. Oh, the Nexus 9 is not a phone. Never mind.

OTOH the new Jolla OS is out, it's got SD and removable battery, and the phone's not too expensive. That looks interesting.

[hi_robb]

Sod the encryption.

Who;s the lovely lady standing behind the lollipop in the article pic?

D

[Dan 55]

Re: Sod the encryption.

Popular on the hit parade I hear.

https://www.youtube.com/watch?v=F57P9C4SAW4

[hi_robb]

Re: Sod the encryption.

Ah thanks,

I didn't recognise her as here in the UK she's called Katy Lambrini....

/gets coat

[Anonymous Coward]

Re: Sod the encryption.

Is that a nipple in the picture? Looks like it !

PS: Didn't think the video was as good as that Rollin Chick Chick one, with or without said nipple.

[Wilseus]

Re: Sod the encryption.

She's saucy! :D

[Crisp]

NSA and GCHQ were unavailable for comment.

Notable for its absence at the end of the article.

[libove]

Encryption in Software Slow on modern devices?

I find it hard to believe that having to perform disk (on-device Flash-based storage) encryption in software (on the main CPU) would make a modern mobile device noticeably slow. The article quotes Google as saying it ... but can someone give specifics/details?

For example, it is very common today to buy moderately priced mobile devices with quad core 1.2GHz+ CPUs. Given the relatively slow performance of the Flash storage on mobile devices (which limits the amount of data which the CPU core would need to encrypt every unit of time), and the efficiency of modern software encryption algorithms, is the performance impact of software-based encryption really noticeable to the human user?

[David Gosnell]

Every silver lining...

Encryption may have been an extra nail in the coffin for our 2012 Nexus 7 when its storage went tits-up. It tried to at least partially recover itself but the encryption appeared to get in the way of that happening at all. Thankfully nothing of importance lost, but still an extra annoyance, and of course the user experience of Lollipop en route to that was hardly consolation.

[Hans 1]

Re: Every silver lining...

Backups, backups, backups ...

[David Gosnell]

Re: Every silver lining...

> Backups, backups, backups ...

That's why nothing of any importance was lost, duh :-P

[Hans 1]

>We remain firmly committed to encryption because it helps keep users safe and secure on the web.

ROFLMAO

That is BS - encryption allows you to protect data on internal/external storage from thieves, people who attack the security sieve that android is via the web will have the data decrypted - the data is available to applications decrypted.

Besides, what use is encryption when your data is sync'ed with the cloud ?