Lollipop device encryption by default is still in the future. No conspiracy here; it seems like they don't have the appropriate drivers yet. But while relaxing the requirement might make sense technically, it's not a good public relations move.
Android compatibility document. Slashdot story.
Posted on March 3, 2015 at 5:46 AM • 35 Comments
Curious reader • March 3, 2015 6:41 AM
what's lillipop encryption? Is it a new algorithm, Bruce?
New phones with ARMv8 CPUs solve part of the problem, because they have standardized AES instruction...
@Curious reader
Lollipop is the latest Android version. The encryption in discussion is encryption of data on internal flash and memory cards.
have look at linked pages or at http://arstechnica.com/gadgets/2015/03/google-quietly-backs-away-from-encrypting-new-lollipop-devices-by-default/
I think the bigger concern/issue is that it is a trend of back pedaling and changing where they stand on the issue. There will be more stories like this from other vendors.
wiredog • March 3, 2015 7:28 AM
Didn't the "Lillipop consipricy" open at Coachella a few years ago?
Mace Moneta • March 3, 2015 7:29 AM
Nothing stops you from enabling encryption manually, even on earlier Android releases. I'm using KitKat and have the system encrypted. There have been too many cases of lost/stolen phones, where the perp doesn't factory reset the device. Sure, they helpfully send along any selfies that they take along with their location, but that also means they have access to everything on the device. Full device encryption is easy to do and easy to live with (using trusted devices for unlock at home/work), and has no noticeable impact on performance. Why wouldn't you use it?
Bananaphone • March 3, 2015 8:47 AM
When an Android doesn't have hardware encryption, where does it protect the key? Keeping the 256-bit key on the SSD, only protected by your 4-digit pin is useless. Keeping the key behind a 20 unicode char password that you have to type in every minute makes the phone useless.
The iPhone solved this since the 3GS in 2009. Windows phone maybe solved this already, IFF you have a very expensive domain controller to flip that toggle (WTF!?!). Google has several Official 1st party devices, why don't they make FDE part of that experience?
Sasparilla • March 3, 2015 9:54 AM
Was reading this was due to performance impact when enabling the encryption and the hardware vendors not wanting this - the slow performance of the Nexus 6 was tied to this (encryption defaulting to on). Several people over on Ars who were testing it on and off were describing a noticeable hit occurring after you enabled it with recent handsets.
The real problem here, IMHO, is that Google made a big deal of announcing this would be the default for Lollipop, but then didn't say anything about this actually changing after their big announcement - so alot of folks that would be expecting, wanting it on, would just think it would be on - when in reality it wouldn't.
Alot of world govt agencies and police forces that like to copy what you have when they get access to your phone are probably quite relieved by this...if they could only get those darn Apple people to toe the line.
Morrison • March 3, 2015 10:11 AM
"Lillipop"? "consipricy"
I think these are subtle hints to tell us Clive Robinson is writing for Bruce's blog.
Trey • March 3, 2015 11:22 AM
@Sasparilla Completely false, regarding performance issues. I have heard the stories. I have a Nexus 6 in factory configuration (no root) with encryption enabled by default. It is loaded down with apps and I have not seen any performance issues whatsoever. In fact, its faster than any phone I have had before.
00O • March 3, 2015 11:41 AM
When you encrypt the partition or drive, if one bit gets flipped, how much of that filesystem is now unreadable? Bit-rot has been my big concern with whole-system encryption. It's one thing if it's a home desktop system with frequent backups. Quite another when you depend on it in the field.
x2bike • March 3, 2015 11:44 AM
I picked up a new Nexus 9 tablet a few weeks ago. Android 5.01 was installed on it and encryption was enabled by default.
I updated an LG GPAD 8.3 GPE tablet to Android 5.0, encryption was not enabled when I finished. I reset it back to factory settings. It kept Android 5.0, but no encryption enabled
I updated a 2102 Nexus 7 tablet to Android 5.02 last week. Encryption wasn't enabled by default when I got done.
Anura • March 3, 2015 12:09 PM
@00O
Depends on the algorithm. If it's a stream cipher, or a block cipher in CTR or mode, then flipping 1 bit of ciphertext results in only 1 bit of plaintext becoming unreadable. In some block cipher modes such as XTS, ECB, and CFB if you flip one bit of ciphertext it will corrupt plaintext equal to the blocksize (128-bits/16 bytes if using AES) - XTS is used by many HDD encryption programs, TrueCrypt included. In CBC mode, it will corrupt one block of data as well as flipping an additional bit in the plaintext of the next block.
SteveMB • March 3, 2015 1:36 PM
Meh -- as long as they aren't backtracking on the key (pardon the pun) improvement (of not having access themselves, and thus being unable to give it to a third party behind the user's back), this is a relatively minor issue IMO.
Erik • March 3, 2015 2:11 PM
I think the difference in attitudes about protecting user data and privacy between Google and Apple couldn't be more stark:
Google promises to make it default for forthcoming devices in a few months, then backtracks.
Apple makes it mandatory, and then makes it available on every IOS device introduced since 2011 (iPhone 4S / iPad2 era) as part of the standard IOS update process.
Anura • March 3, 2015 2:51 PM
A correction to my previous post: CFB mode also flips 1 bit and corrupts one block, like CBC mode except in CFB mode a bit is flipped in the same block, and the subsequent block is corrupted.
Sasparilla • March 3, 2015 3:00 PM
@Trey I'm sure the Nexus 6 is great, no disrepect meant towards the hardware. The issue with regards to the Nexus 6 were the performance benchmarks that were unexpectedly low considering its hardware (which was top of the line) when the reviews started coming in - the encryption lagging the performance was one of the things suspected.
But the main point is that folks can take their current Android phones with Lollipop on them and encryption disabled, then enable it - and they'll see a perceptible hit in performance. This was the reason suspected for Google not making encryption enabled by default (which they stated they would). Unfortunately Google didn't announce they were making encryption optional with Android v5.x and leaving potential users thinking they had it enabled by default.
untested • March 3, 2015 3:59 PM
Sasparilla "But the main point is that folks can take their current Android phones with Lollipop on them and encryption disabled then enable it"
Only a small minority will try this.
Mace Moneta "Why wouldn't you use it?"
Because it is only tested by a minority, hence the vendors will not make much effort to make it reliable.
I tried device encryption on my phone. The day after it went in a boot loop. I did a factory reset. I will never try again.
Thomas • March 3, 2015 4:39 PM
The fact that you 'enable' encryption once the phone is running indicates to me that it's a bitlocker-style (i.e. part of the filesystem) rather than NIX-style (part of the block-device).
Doesn't this mean your 'plaintext' is only a single-overwrite away?
Does it have the puzzling bitlocker feature of 'temporarily disabling encryption'?
If so, how can you tell if this has been done?
Personally I much prefer the block-device based encryption, even if it means re-installing from scratch.
Anura • March 3, 2015 5:35 PM
@Thomas
"Personally I much prefer the block-device based encryption, even if it means re-installing from scratch."
It's definitely a useful tool, but it's not ideal. Filesystem based encryption has the advantage in that it is more efficient to do authenticated encryption. The problem with sector based is that if you store a MAC for every sector, it is a lot of overhead. The problem with filesystem based is that not everything needs to read the whole file and instead wants random access, but verifying the whole thing is a lot of overhead. Binaries and config should probably all be using authenticated encryption.
Of course, I'm not familiar enough to know if any of these filesystem based encryption software actually uses authentication in the first place.
Daniel • March 3, 2015 7:13 PM
Color me skeptical about both Google and iOS. Sure Apple may not know the key but we all know that the NSA MO is not to attack keys but to attack implementation. I'd bet a lot of money that Apple has a way of breaking its own implementation so that it can say with a straight face it doesn't know the keys but can still comply with Nation Security Letters.
Dirk Praet • March 3, 2015 7:57 PM
@ Thomas, @ Sasparilla, @ untested, @ Anura, @ @00O
The fact that you 'enable' encryption once the phone is running indicates to me that it's a bitlocker-style (i.e. part of the filesystem) rather than NIX-style (part of the block-device).
Android disk encryption is based on dm-crypt, which means it's at the block device layer. The encryption algorithm used is AES-128 with cipher-block chaining (CBC) and ESSIV:SHA256. The master key is encrypted with 128-bit AES via calls to the OpenSSL library. New Lollipop devices encrypted at first boot cannot be returned to an unencrypted state.
@ Bananaphone
When an Android doesn't have hardware encryption, where does it protect the key?
The unlock PIN/password is used to derive the AES disk encryption key which is stored in the volume header. As from 4.4, scrypt is used to derive the keys in order to make brute force attacks a little harder, but using a strong password instead of a stupid PIN remains highly recommended. On certain Nexus devices, the key is hardware-protected (likely TrustZone-based TEE).
@ .
I think the bigger concern/issue is that it is a trend of back pedaling and changing where they stand on the issue.
I don't know. I prefer a company back pedaling on previous statements if for some reason they expect problems with it instead of just going ahead and creating headaches for a substantial part of the user base. Google has probably learned from past mistakes by Microsoft and IBM.
steve37 • March 4, 2015 1:57 AM
Google and Apple offer weak cryptography ;)
‘FREAK’ flaw undermines security for Apple and Google users, researchers discover
I wonder if the back peddling by Google is actually a symptom called "cold feet". We never know if the Powers That Be might have had tea sessions with Giggle's Execs and Managements and had either served delicious nice Dragon Well Tea (soft method) or gave them badly made factory rotten Tea Dust (hard method) to get a back peddle effect.
With the past articles about Apple, Google, other companies, and government compromising and lying, it is best today to never trust any statement or product from the same. True men of integrity never compromise. How do the British sometimes say it: Once bitten, twice wary.
Clive Robinson • March 4, 2015 7:53 AM
@ Moderator,
NZA appears to be exhibiting the same behaviour as some one who was recently asked not to return.
Can you check the logs to see if there is commonality in ip addresses or geo-location?
Wael • March 4, 2015 8:02 AM
@Clive Robinson,
as some one who was recently asked not to return.
Doesn't that count as trespassing, something prosecutable? Any attorneys in the house? :)
vas pup • March 4, 2015 3:13 PM
!!!China officially requested back doors: http://www.bbc.com/news/technology-31729305
Jake • March 5, 2015 10:07 AM
@00O:
Bitrot: Been there done, that. Is that ever an awful feeling to not be able to get the data back.
As far as the lollipop goes, only young ones small enoungh to be sucking on one would believe in the encryption scheme anyway. It'll be worthless, or close. An aside, and my quote for the day: The internet is a broadcast medium, cleverly disguised to be interactive.
Zach • March 5, 2015 2:20 PM
Perhaps Google is concerned about their future information-collection ability.
Google is after all not really a tech company. They are more like an advertizing company that provides tech tools, as their core business is adverts.
For example according to this article:
Google, Mighty Now, but Not Forever
http://www.nytimes.com/2015/02/12/technology/personaltech/googles-time-at-the-top-may-be-nearing-its-end.html
Although Google has spent considerable resources inventing technologies for the future, it has failed to turn many of its innovations into new moneymakers. About 90 percent of Google’s revenue is from ads, most of that on its search engine.
Anura • March 5, 2015 2:35 PM
@amazombie
Without a secure hardware storage solution, your key is stored in a file that is protected by the pin, which is trivial to crack for most pins - a 6-digit pin is easily doable in under a day on a computer with a single CPU core and no specialized software. Most people have very weak security (pin or pattern, the latter being even less secure than a 6-digit pin), because typing a strong password on a phone to unlock it is inconvenient.
vas pup • March 5, 2015 4:04 PM
Some good news on privacy and encryption: http://www.dw.de/privacy-advocates-take-big-data-to-task/a-18294270.
That is good point: "'calling on big Internet firms to adopt business models that don't revolve around t r i c k i n g u s e r s into forgoing their privacy'."
Whole article is good reading.
It's just all glooms overall even if INFOSEC/COMMSEC/ITSEC sees some "improvements". We have lots of good papers (e.g. ePrint IACR) but mostly the industry is still sitting on what we have about 20 years ago or even 40 years ago. It's about time the industry needs a very big reboot (that already was due for decades).
Android, iPhone, BlackPhone, BlackBerry, Nokia, WindowsPhone, XXXXXXPhone ??? It's all insecure.
Your hardware is insecure anyway.
Some solutions would be to use TPM chips in your ARM/Intel/AMD processors/crypto-processors or the use of the microSD card slot for microSD card secure elements in the form of ... microSD card that respond to and acts as a micro smartcard. Do you know the hardware and software (including firmware) of these chips to properly tell if it has been backdoored ?
No.
End of the day, it's back to square one for most people who try and seek security. The most basic level of security and trust which is the hardware (quote RobertT) cannot be verifiable.
Methods to sidestep like "air-gapping", data diodes with one way traffic, IOMMU and all these techniques are made to try and assert some levels of trust.
Regardless if Android has FDE-enabled or not, the end result is the ARM chips inside those Android phones or Intel chips if you will, are all backdoored (most likely) at the end of the day. If NSA could backdoor firmware of almost all hard disks, what is the likelihood they wouldn't do that to processors too ?
Wael • March 6, 2015 3:19 AM
@Thoth,
Your hardware is insecure anyway.
1- Why?
2- What can be done about it?
I would say the platform is not assured to be secure, but either way: Dig deep in the bowls of this blog and you may find the answers ;)
vas pup • March 6, 2015 10:15 AM
New encryption bug alert: http://www.bbc.com/news/technology-31765672
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Security.
Leave a comment