Google Backs Off Default Encryption on New Android Lollilop Devices

← Back to Stories (view on slashdot.org)

Google Backs Off Default Encryption on New Android Lollilop Devices

Posted by Soulskill on Monday March 2, 2015 @10:09PM from the give-the-people-what-the-government-wants dept.

An anonymous reader writes: Although Google announced in September 2014 that Android 5.0 Lollipop would require full-disk encryption by default in new cell phones, Ars Technica has found otherwise in recently-released 2nd-gen Moto E and Galaxy S6. It turns out, according to the latest version of the Android Compatibility Definition document (PDF), full-disk encryption is currently only "very strongly recommended" in anticipation of mandatory encryption requirements in the future. The moral of the story is: don't be lazy — check that your full-disk encryption is actually enabled.

124 comments

Min score:

Reason:

Sort:

FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-02 22:14 · Score: 5, Insightful

The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock. Who wants to type in a 20+ password every time they open their screen lock? Who even bothers with FDE if the key will be no stronger than what, six numeric characters?
There has been some dirty hacks you could do to combine FDE with e.g. pattern lock for the screen, but these have had the tendency to break the whole thing eventually.
1. Re:FDE on Android doesn't work as of yet by stephanruby · 2015-03-02 22:32 · Score: 5, Informative
  
  The real issue is the extra battery drain it creates and the extra delay it takes to read/write encrypted data. In other words, this is an acceptable tradeoff for an employer and this is an acceptable tradeoff for some people who really care about security, but it's really not acceptable for most consumers.
  If it ever becomes the default on consumer phones, for liability reasons or for whatever, the first thing people will learn is how to disable it so they can save battery power.
2. Re:FDE on Android doesn't work as of yet by moronoxyd · 2015-03-02 22:35 · Score: 5, Informative
  
  The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock. Who wants to type in a 20+ password every time they open their screen lock?
  Are you sure?
  For my Android phone I activated FDE. On boot I have to enter the FDE password, which is independent from the lock screen password/pattern/face unlock.
  So on boot I enter the complex password once, and later I use the less complex pattern to unlock my running phone.
  My phone is Running Android 4.4.4 (Cyanogen CM11S).
3. Re:FDE on Android doesn't work as of yet by Gaygirlie · 2015-03-02 22:45 · Score: 1
  
  The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock.
  No, it doesn't. At least in Lollipop FDE-password is separate and you enter it at boot.
4. Re:FDE on Android doesn't work as of yet by PriyanPhoenix · 2015-03-02 22:51 · Score: 5, Interesting
  
  Or at the very least it would need to come with a significant enough processor jump that no one notices the drop in responsiveness from any earlier device. I briefly switched on FDE on a Nexus 5 and it only took a few days to decide the trade-off was (for me) unacceptable. Had I jumped to the Nexus 6 at the same time, however, that may not have been an issue.
  
  --
  "Yes, Virginia, there is a Great Cthulhu..."
5. Re:FDE on Android doesn't work as of yet by DrXym · 2015-03-02 22:54 · Score: 3, Interesting
  
  Most SoCs have encryption circuitry so I doubt it has any appreciable effect on performance or battery providing its done through hardware. In Linux disk encryption is via dm-crypt which in turn is via the crypto api so Android could probably use that to provide blanket crypto in addition to whatever crypto is done higher up by apps or user storage.
6. Re:FDE on Android doesn't work as of yet by Gaygirlie · 2015-03-02 22:59 · Score: 5, Informative
  
  Or at the very least it would need to come with a significant enough processor jump that no one notices the drop in responsiveness from any earlier device.
  Depends on whether the SoC can do AES-encryption/-decryption in hardware or not. Your Nexus 5 does it in software, ARMv8 (ARM64) includes optional support for H/W-accelerated AES. It's unlikely that low-to-mid-end phones will be sporting ARMv8 SoCs anytime soon, but it'll happen eventually, and higher-end phones are already starting to move to it.
7. Re:FDE on Android doesn't work as of yet by SilentTristero · 2015-03-02 23:01 · Score: 1
  
  Whether in hardware or software, it's still a fair amount of computation, which means battery usage and latency. It has to affect the max IOPS, which means when the phone wakes up to do something, it'll stay awake for longer.
  My N5's battery life is already barely acceptable; I'm not going to enable FDE on the chance it takes even a 5% or 10% hit.
8. Re:FDE on Android doesn't work as of yet by fph+il+quozientatore · 2015-03-02 23:08 · Score: 4, Insightful
  
  So the protection is only effective if someone steals my phone while it's turned off, which is, like, 0.1% of the time?
  
  --
  My first program:
  Hell Segmentation fault
9. Re:FDE on Android doesn't work as of yet by Gaygirlie · 2015-03-02 23:26 · Score: 3, Informative
  
  So the protection is only effective if someone steals my phone while it's turned off, which is, like, 0.1% of the time?
  Yes, that's exactly what it was designed for. If the system required you to enter the FDE-password whenever you open up the screen then how would background-processes, like e.g. SMS-receiving, chat and such stuff work? They'd only be able to access the disk when you have the display open and that'd obviously make the whole thing unuseable as a smartphone in the first place. No full-disk encryption scheme has been designed to withstand attacks originating from an already-running system since you need to keep the key in memory to do anything with the disk in the first place!
10. Re: FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-02 23:36 · Score: 0
  
  I thought all non-iPhone phones had swappable batteries Wasn't a non-swappable battery the horrible design decision that would doom the iPhone?
11. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-02 23:51 · Score: 0
  
  The real issue is the extra battery drain it creates and the extra delay it takes to read/write encrypted data.
  
  I'm gonna go out on a limb and guess that you don't actually have any data back that up. And yet you're willing to declare that the "real issue."
12. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 00:25 · Score: 2, Informative
  
  No latency for hw crypty.
  A hardware crypto device can en-/decrypt faster than the disk transfers. Therefore, no latency at all. Of course it require power, but a crypto circuit is a lot smaller than a cpu, and doesn't need to run at the full cpu clock frequency either. Phones are custom chips anyway, so making one with fast low-power crypto device is not a problem. The only reason for not doing crypto by default is that not all current phones have such HW. And then they rack up latency & power use as you describe.
13. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 00:32 · Score: 1
  
  The battery drain complaint seems rather lame as IOS 8 come by default with encryption enabled and I have not seen wide spread complaints about battery issues.
  I think the real issue is that older slower devices testing the Android system with encryption complained about poor performance. This is the real reason behind the pull back.
14. Re:FDE on Android doesn't work as of yet by fph+il+quozientatore · 2015-03-03 00:34 · Score: 1
  
  If the system required you to enter the FDE-password whenever you open up the screen then how would background-processes, like e.g. SMS-receiving, chat and such stuff work? They'd only be able to access the disk when you have the display open and that'd obviously make the whole thing unuseable as a smartphone in the first place.
  I get your point, but I disagree on the part where you write that background operations need the disk or else they can't possibly work at all. Current smartphones are not designed to work without accessing the disk, that's true, but in theory 1GB of RAM is plenty for processes like polling a chat server or SMS to run entirely in it.
  
  --
  My first program:
  Hell Segmentation fault
15. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 00:35 · Score: 1
  
  Battery drain can't be the real issue in FDE adoption if the FDE itself is so broken it can't be adopted at all. You should read about AES-NI too, it should give you some insight in how HW accelerated crypto works. Minimal load on battery and minimal impact on disk performance. So minimal it's practically impossible to notice in use.
16. Re:FDE on Android doesn't work as of yet by DigiShaman · 2015-03-03 00:36 · Score: 3, Insightful
  
  But how much? At least on Intel CPUs that have the AES-NI instructions, FileFault2 on a MacBook Pro is of minimal impact. Throwing a number out there, but perhaps less than 1% hit in performance?? And this is me running and compacting (cleanup) VMs (massive read/write operations) on an encrypted SSD. Certainly these new CPUs in mobile phones contain a similar feature as AES-NI, no?
  
  --
  Life is not for the lazy.
17. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 00:37 · Score: 0
  
  I'm following you OK on the security angle of using a short PIN, etc. as a key protector. Note it is the protector though and not the key itself. Meaning that if you were able to somehow get hold of the raw encrypted data, then PIN wouldn't unlock it. It would only unlock the actual key (which could be used to decrypt). As far as the hack thing, I have a Nexus 6, I use a pattern lock, and my device is encrypted. This is built in to Android 5.0+. The key protector is the pattern lock - which is a usability / security tradeoff I consciously made knowing that is it not as secure as a very long code and is more secure than a swipe to unlock. I don't see the hack there - the key protector is simply the pattern.
18. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 00:43 · Score: 1
  
  They may have fixed this in CM independently since it's been a pain in the ass for many users for a very long time. I'm not sure whether it's fixed in the upstream Android, though.
19. Re:FDE on Android doesn't work as of yet by Gaygirlie · 2015-03-03 00:44 · Score: 1
  
  I get your point, but I disagree on the part where you write that background operations need the disk or else they can't possibly work at all. Current smartphones are not designed to work without accessing the disk, that's true, but in theory 1GB of RAM is plenty for processes like polling a chat server or SMS to run entirely in it.
  Yes, but if the phone was to lose power, like e.g. run out of battery or crash you'd lose all the data in RAM. From a general usability-standpoint losing any data that does only reside on your phone is unacceptable, most people would definitely throw a major fit about it even if it only ever actually harmed very few individuals. What if that SMS-message you just got, for example, was something important, but it got lost in bit-space? Well, you wouldn't know until it's too late!
  As for keeping things in RAM: Android isn't known for being small and efficient, not even Lollipop. There are plenty of RAM-hungry background-tasks running and things like e.g. Facebook and such that are notoriously bad. Then some phones even offer things like spoken keyword-recognition that would require keeping a whole effing lot of stuff at all times in RAM just to work. I doubt 1GB RAM would be even nearly enough on most people's phones, though 2GB or more would of course help. You'd still have the issue I mentioned above, though.
20. Re:FDE on Android doesn't work as of yet by AmiMoJo · 2015-03-03 01:18 · Score: 2
  
  It's starting to be built into some mobile flash controllers too. It's already pretty standard on SSDs for computers. On most you can't choose the key yourself, only make the SSD generate a new one with a disk erase command. Some drives support OPAL v2 (called eDRIVE by Microsoft) that lets you use your own key, and is supported by Bitlocker. In benchmarks there is only a 1-2% loss of performance from enabling it.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
21. Re: FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 01:18 · Score: 0
  
  I only want to swap my battery if I have to replace it permanently. I'm not keen on having to constantly remove my OtterBox. Also, I don't want to carry around a spare battery "just in case". However, being able to remove the battery is still important, as I have had to do that once when the phone completely locked up and I couldn't even power it off the normal way. There are more use cases than "use a spare battery" for being able to remove the battery yourself.
22. Re:FDE on Android doesn't work as of yet by hankwang · 2015-03-03 01:24 · Score: 3, Informative
  
  Cyanogenmod 11 (Android 4.4.4) indeed has an option to set the encryption password separately. With stock Android this only possible on a rooted device (vdc cryptfs changepw [secretpassword1]), but the encryption password will be reset if you change the screen unlock code.
  
  --
  Avantslash: low-bandwidth mobile slashdot.
23. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 01:27 · Score: 0
  
  I have an android device from Samsung and I have enabled encryption. The unlock password is the same as the boot password. With the phone locked, it cannot be accessed via USB. Access to information on the phone will need to get past the screenlock or the non-volatile encryption, both of which have the same password (assuming you are not looking at malicious software installs or advanced persistent threats that can clone RAM states).
24. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 01:28 · Score: 0
  
  The iPhone has been encrypted by default for a long time already. AFAIK, there is no way to turn it off either. Seems to work fine.
25. Re:FDE on Android doesn't work as of yet by phayes · 2015-03-03 02:01 · Score: 4, Informative
  
  What is lame is people posting ignorant comments as Anon Cowards.
  Apple has control of both the hardware & the software & has optimized both to make use of FDE as painless as possible. This is clearly not the case in Android.
  Stealing from Seillac's comments on ARS:
  "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/2...
  
  --
  Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
26. Re:FDE on Android doesn't work as of yet by anybody_out_there · 2015-03-03 02:04 · Score: 3, Interesting
  
  Had I jumped to the Nexus 6 at the same time, however, that may not have been an issue.
  As a recent Nexus 6 owner, I can confirm that encryption is enabled by default. I have not noticed any performance lag and the battery life has been really good. I will admit, I'm coming from an 'ancient' phone, so maybe that's why I think it's fast enough; way faster than my old phone.
27. Re:FDE on Android doesn't work as of yet by c · 2015-03-03 02:45 · Score: 2
  
  So the protection is only effective if someone steals my phone while it's turned off, which is, like, 0.1% of the time?
  Entirely different threat vectors.
  When the phone is on and locked, the attacker has to (relatively slowly) manually punch in a PIN and deal with lockouts and such. Shorter passwords are sane in that case.
  When the phone is powered off, the attacker can pull the flash and do a high-speed static attack. A short PIN won't stand up in that situation.
  
  --
  Log in or piss off.
28. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 02:58 · Score: 0
  
  You see, that is why short battery life is a FEATURE and not a problem.
29. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 03:05 · Score: 0
  
  iOS devices handle FDE with minimal battery impact. It's certainly doable.
30. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 03:07 · Score: 0
  
  iOS actually unloads the key when the phone is locked. Running apps have to store what they need in memory or are unable to access that data.
31. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 03:10 · Score: 1
  
  ... Then all someone needs to do to compromise your phone is guess the lock screen password / pattern / face. You've only bought security in the event your phone is powered down.
32. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 03:19 · Score: 0
  
  >
  If it ever becomes the default on consumer phones, for liability reasons or for whatever, the first thing people will learn is how to disable it so they can save battery power.
  Or you could, you know, stop checking your phone every ten seconds. Look around at the real world instead.
33. Re:FDE on Android doesn't work as of yet by LordLimecat · 2015-03-03 03:28 · Score: 1
  
  Who even bothers with FDE if the key will be no stronger than what, six numeric characters?
  I do, because I recognize that you dont have to hit "perfect security" to have "worthwhile security". A 7-10-digit pin is going to protect my data pretty well against casual theft, and against attackers who do not have the time or resources to image the flash. It also protects me against casual backdooring; until the code is cracked, no malicious code can be inserted (again without gaining physical access to the flash chips).
  Yea, it wont protect me against top-echelon attackers, but then if that was my risk model there are a LOT of other vectors I would be worried about before the length of my PIN.
34. Re:FDE on Android doesn't work as of yet by mveloso · 2015-03-03 03:29 · Score: 1
  
  "If it ever becomes the default on consumer phones, for liability reasons or for whatever, the first thing people will learn is how to disable it so they can save battery power."
  You mean consumer phones like the iPhone?
35. Re: FDE on Android doesn't work as of yet by LordLimecat · 2015-03-03 03:30 · Score: 1
  
  The N5 does have a swappable battery.
36. Re:FDE on Android doesn't work as of yet by LordLimecat · 2015-03-03 03:31 · Score: 3, Insightful
  
  A hardware crypto device can en-/decrypt faster than the disk transfers. Therefore, no latency at all.
  
  Latency and bandwidth are distinct measurements. Im not sure your assumption is safe at all.
37. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 03:37 · Score: 1
  
  FileFault2
  Hmm, you haven't, by chance, lost data recently have you?
  I find it so surprising that in this day and age of TB hard drives and online services, that there are still programs with a save button, programs that lack of incremental storage of any and all changes and that losing files are still a common occurrence.
38. Re:FDE on Android doesn't work as of yet by Anubis+IV · 2015-03-03 03:58 · Score: 2
  
  this is an acceptable tradeoff for an employer and this is an acceptable tradeoff for some people who really care about security, but it's really not acceptable for most consumers.
  If it ever becomes the default on consumer phones, for liability reasons or for whatever, the first thing people will learn is how to disable it so they can save battery power.
  The iPhone line has had this feature since the 3GS back in 2009, which seems to directly contradict all of the statements I quoted from you. When implemented properly, the battery drain and performance hit for FDE is demonstrably insignificant enough that it will go unnoticed by everyday consumers. The fact that iPhones continue to sell without the sorts of consumer outcry/consternation you're talking about is proof of that fact
  The notion that this feature involves a massive trade-off was proven false 6 years ago. Why people are trying to make that claim now is beyond me, since we already have contradictory evidence to that claim.
39. Re:FDE on Android doesn't work as of yet by DrXym · 2015-03-03 04:02 · Score: 1
  
  I bet virtually every SoC has the hardware. Whether it exposes this hardware to the kernel in a stable manner through a driver is another matter.
  I bet the performance hit on battery or IO would be neglible if it were functioning properly. Maybe Google has had problems with some chipsets.
40. Re:FDE on Android doesn't work as of yet by WaffleMonster · 2015-03-03 04:44 · Score: 1
  
  The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen.
  Not really necessary.. cost just needs to be gated by hardware security chip holding actual encryption keys. It can do anything it wants. Slow down the process to 1hr/attempt after nn attempts or even enforce a hard limit based on entropy estimate of the underlying data.
  Personally I have a strong distrust of "full disk encryption" ... Much better off with implementations closer to the application than as a generic transparent storage aspect.
  This is especially true given Android OS has never been trustworthy with well known exploits routinely going unpatched for years or forever given laughable product lifecycle vendors currently get away with peddling.
41. Re: FDE on Android doesn't work as of yet by LiENUS · 2015-03-03 04:45 · Score: 2
  
  Since when?
42. Re:FDE on Android doesn't work as of yet by WaffleMonster · 2015-03-03 04:54 · Score: 1
  
  Are you sure?
  For my Android phone I activated FDE. On boot I have to enter the FDE password, which is independent from the lock screen password/pattern/face unlock.
  So on boot I enter the complex password once, and later I use the less complex pattern to unlock my running phone.
  My phone is Running Android 4.4.4 (Cyanogen CM11S).
  What kind of access does cracking "the less complex pattern" provide? What percentage of time do mobile devices spend being completely off? What's the point?
43. Re:FDE on Android doesn't work as of yet by mlts · 2015-03-03 05:03 · Score: 1
  
  This is an issue, but at least the FDE code is out in the open, and is based on a known, good algorithm (dm-crypt) that has been in Linux for a long time.
  Google is taking steps to fix it. In the latest iteration of devices, the encryption key won't be directly decrypted from the password the user gives, but the password goes to a hardware chip that compares the PIN, and if correct, passes the volume decryption key to the OS.
  If one has root access, there is even a better way. You can have the password used to boot and decrypt the /data partition separate from your screen unlocking PIN. This will be a PITA when rebooting the phone... but you can use a much shorter screen unlock code, while still having the full protection of a long key that you set. The downside of this is that root access is required.
44. Re:FDE on Android doesn't work as of yet by ultranova · 2015-03-03 05:22 · Score: 1
  
  Latency and bandwidth are distinct measurements.
  
  But they aren't independent. A device that has high bandwidth and high latency must be massively parallel (since for a sequential device bandwidth is simply inverse of latency) and have massive internal buffers to hold all the data being processed. That seems pretty unlikely for implementing such a simple algorithm, unless of course the implementation is purposefully broken.
  
  --
  Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
45. Re:FDE on Android doesn't work as of yet by kenshin33 · 2015-03-03 05:33 · Score: 3, Interesting
  
  nexus 5 has the hardware to do it, just not used. the CAF variante of CyanogenMod (http://github.com/CyanogenMod/android_device_lge_hammerheadcaf) has that enabled. No nightelies for the moment but you can build it from source, give it a spin, if you'de like (bear in mind that there's no upgrade path from SW encryption to HW one, ie : a wipe is required to go from on to the other).
46. Re:FDE on Android doesn't work as of yet by swillden · 2015-03-03 06:00 · Score: 5, Informative
  
  (I'm a member Android Security team who worked on bits of Lollipop FDE)
  
  The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock.
  This isn't completely true on Lollipop devices that have hardware-backed credential storage. (Well, it's not really "hardware-backed", but it's in a Trusted Execution Environment, typically ARM TrustZone.)
  For Lollipop, a big change to FDE was the inclusion of a hardware-backed key in the key derivation function (KDF) for the FDE master key encryption key. This provides two benefits:
  1) It means that a dump of the contents of your encrypted flash is useless without the device.
  2) It means that brute force search of your PIN/pattern/password space is serialized and rate-limited by the performance of the device. In a way this means that faster devices are less secure, though we also apply a device-tuned scrypt function as part of the KDF, which compensates in the case of an attacker who tries to perform the entire attack on-device.
  The best attack against Lollipop FDE, on a device with HW-backed credentials, is to dump the data from the device flash, then flash a custom OS which makes calls into the HW crypto to create an oracle, processing a stream of requests and returning the responses. Then you do a brute force attack with a mixture of on-device and off-device resources, computing the first scrypt function offline, then performing the on-device crypto operation, then taking the results of that and performing the second scrypt function offline, which you then use to try to decrypt the FDE master key, offline.
  The fastest devices on the market today will perform the HW-backed crypto operation in about 50 ms. Assuming everything is pipelined properly, this is the brute force attempt rate: 20 attempts per second. With a four-digit PIN, this is negligible: the entire space can be searched in 8 minutes. However, a six-character alphanumeric password (random, all lowercase) would take 630 days, on average, to break. That's pretty reasonable security.
  In theory. In practice it would take much longer than that. I tried running this test on a Nexus 9 and found the device kept throttling itself because it got too hot, plus even with a 2A charger it consumed more power than was being provided to it, so I had to stop when the battery died and wait for it to recharge.
  Pre-Lollipop, and even on Lollipop devices that lack HW-backed crypto, you can conduct the entire attack off-line, parallelized, on however much hardware you care to throw at it. I can't make any promises about the future, but I will say that I, personally, really want to significantly improve Android FDE in the future. I have changes in mind that will make brute force essentially impossible, unless you can break into the Trusted Execution Environment.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
47. Re:FDE on Android doesn't work as of yet by swillden · 2015-03-03 06:03 · Score: 3, Interesting
  
  Had I jumped to the Nexus 6 at the same time, however, that may not have been an issue.
  As a recent Nexus 6 owner, I can confirm that encryption is enabled by default. I have not noticed any performance lag and the battery life has been really good. I will admit, I'm coming from an 'ancient' phone, so maybe that's why I think it's fast enough; way faster than my old phone.
  As mentioned by Gaygirlie, a big factor is the AES-NI instruction in the ARMv8 instruction set supported by your Nexus 6. It dramatically reduces the performance and power hit of AES operations.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
48. Re:FDE on Android doesn't work as of yet by sexconker · 2015-03-03 06:20 · Score: 1
  
  Most of the time I don't WANT to save. I'd be damned pissed if my disk was writing shit I didn't want it to.
49. Re:FDE on Android doesn't work as of yet by swillden · 2015-03-03 06:34 · Score: 3, Informative
  
  The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock.
  No, it doesn't. At least in Lollipop FDE-password is separate and you enter it at boot.
  It's not separate. In stock Lollipop there is only one password, and it's used both for FDE and for screen unlock. Some customized ROMs (e.g. CM) have separated it, which allows you to choose a strong boot password and a more convenient unlock password. Stock Android didn't go that direction because too many users would set a strong boot password which they only use once every few weeks and therefore forget, losing all of their data.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
50. Re:FDE on Android doesn't work as of yet by mlts · 2015-03-03 06:51 · Score: 1
  
  Attacking the device PIN is a lot harder. After a few times, the device will prompt for one's gmail account (if set up), or just start giving ever-longer timeouts. Some devices can be set to just format the /data partition and do a factory restore.
  Some Android phones have some anti-brute force protection at boot, if someone doesn't find a way to dd off the /data partition. First, the device starts timing out, then after 30 tries, it zeroes out /data and does a factory restore.
  The protection is decent enough. Most attackers won't guess a 4-6 digit PIN before the phone locks, and if they decide to turn it off and back on, they end up presented with having to deal with the entire /data unlocking passphrase, and get it right in 30 tries.
51. Re: FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 06:58 · Score: 0
  
  Since its release. It's not easily swappable though, you'll need a screwdriver.
  "Non-swappable" to me means "permanently attached to the circuit board", i.e. replacement not viable.
52. Re:FDE on Android doesn't work as of yet by Nyder · 2015-03-03 07:00 · Score: 1
  
  Or at the very least it would need to come with a significant enough processor jump that no one notices the drop in responsiveness from any earlier device.
  Depends on whether the SoC can do AES-encryption/-decryption in hardware or not. Your Nexus 5 does it in software, ARMv8 (ARM64) includes optional support for H/W-accelerated AES. It's unlikely that low-to-mid-end phones will be sporting ARMv8 SoCs anytime soon, but it'll happen eventually, and higher-end phones are already starting to move to it.
  My Nintendo 3DS has some sort of AES hardware chip in it for encryption/decryption. The 3DS has Arm 9 & Arm 11 cpu's in it. So it's possible they could put in something like that and have it work decent.
  
  --
  Be seeing you...
53. Re:FDE on Android doesn't work as of yet by Nyder · 2015-03-03 07:02 · Score: 1
  
  So the protection is only effective if someone steals my phone while it's turned off, which is, like, 0.1% of the time?
  If there is a front facing camera, have it turn on to see who's accessing the phone, like when you hit the unlock. If it recognizes the user (whitelist), then it allows it on, if not, then you have to put in a password.
  Seems like something that would be easy to do these days.
  
  --
  Be seeing you...
54. Re:FDE on Android doesn't work as of yet by mlts · 2015-03-03 07:17 · Score: 1
  
  If the entire filesystem was locked, apps that save pictures off like Dropbox's app that get CPU time from iOS due to shifting GPS locations would not work.
  There are protected stores which do get locked and are not readable until the device is unlocked, but that is generally part of Apple's KeyChain mechanism.
55. Re:FDE on Android doesn't work as of yet by Rich0 · 2015-03-03 07:19 · Score: 2
  
  Whether Android does this I have no idea, but the device could be configured to power off if the wrong screen PIN was entered too many times. A FDE password has to withstand offline attack, which means unlimited attempts at a high rate.
  It is completely appropriate to use a different level of security for each.
56. Re:FDE on Android doesn't work as of yet by Rich0 · 2015-03-03 07:20 · Score: 1
  
  Is this supported if you don't set a screen lock password/etc?
  I'd love to have FDE, but I have no desire to enter a password when driving/etc. The two should be completely independent.
57. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-03 07:46 · Score: 1, Interesting
  
  All you've told me is that, again, Android is inferior to Apple devices, even though it *should* be better. I've spent 6 years and 1200 dollars on phones trying to convince myself it's better or would be better. It's not, screw Google and screw Android. I've already bailed on the tablet last year and couldn't be happier with my iPad. My girlfriend's basic iPhone 6 runs circles around my Samsung Galaxy S4, which is something like 20 months old. Google's 18 month old Nexus is even worse than my S4. Also, having used both app stores, holy crap does Google Play suck and the apps are generally inferior if they're from anything but the biggest companies. This is not shocking for fairly obvious reasons, which can be easily googled (oh the irony), so yes I'm handwaving and calling it okay in this instance.
  So screw it, I'll keep running my linux desktops, but I'm done with Android.
58. Re: FDE on Android doesn't work as of yet by LiENUS · 2015-03-03 09:10 · Score: 1
  
  I mean its swappable in the sense that the iphone has a swappable battery
59. Re:FDE on Android doesn't work as of yet by DamnOregonian · 2015-03-03 10:19 · Score: 1
  
  Let's try some context.
  
  Whether in hardware or software, it's still a fair amount of computation, which means battery usage and latency.
  
  No latency for hw crypty.
  
  A hardware crypto device can en-/decrypt faster than the disk transfers.
  If the disk can transfer 1MB/s, and the crypto engine can handle <1MB/s, then there is going to be reduction in functional disk bandwidth, or at a higher level, an increase in latency between the requested block of data and the service of that block to the higher layer.
  
  Now, if the disk can transfer 1MB/s and the crypto engine can handle >1MB/s, the crypto engine can run transparently (unless for some godforsaken reason crypto block access is mutually blocking with attached storage access), thus introducing 0 *added* latency to the system.
  
  I think his assumption is quite safe.
60. Re:FDE on Android doesn't work as of yet by LordLimecat · 2015-03-04 00:54 · Score: 2
  
  Now, if the disk can transfer 1MB/s and the crypto engine can handle >1MB/s, the crypto engine can run transparently (unless for some godforsaken reason crypto block access is mutually blocking with attached storage access), thus introducing 0 *added* latency to the system.
  What if the pipeline is very long but wide, and it can handle 1MB/s sustained, but it takes any amount of data 1MB at least 1 second to travel through the pipeline?
  It will add 1 second of latency to the system, regardless of the fact that it is running at "wire speed".
  While it COULD add nearly zero latency to the system, it is not enough to say "the bandwidths of the two pipelines are equivalent, therefore no latency is added".
61. Re:FDE on Android doesn't work as of yet by LordLimecat · 2015-03-04 00:55 · Score: 1
  
  but it takes any amount of data 1MB at least 1 second to travel through the pipeline?
  should be "takes any amount of data less than or equal to 1MB at least 1 second..."
62. Re:FDE on Android doesn't work as of yet by Anonymous Coward · 2015-03-04 01:13 · Score: 0
  
  Thanks for the thorough answer (I posted the original question)!
  I'm always looking to improve my security and this far my phone has certainly been the weakest link. I can already fine tune a lot of security settings to try and maximize my online/offline security, but FDE has always been the weakest link, at least on a theoretical level. I admit that I haven't tried Lollipop myself yet and I've mostly depended on what I've read about it, but it still seems to lack some features I'm really looking forward to.
  I would very much like to see a feature with completely separate FDE password that is entered when booting and a pattern/pin lock for the screen. One feature regarding the screen lock many people are wishing for a feature, me included, is that upon entering the screen lock pattern/pin wrong n times (user defined) the device would shut down. This would alleviate at least some fears of a cold boot attack or a buggy screen lock implementation (we've seen plenty over the years).
  These days we carry so much private and even confidential information on our phones it's getting difficult to make any compromises. I understand there are limitations in security applications that can be done using only software solutions, but considering we have multiple work and private e-mail accounts synced on our phones along with a ton of IM conversations it's getting worrysome.
  So even if current solutions offered me at maximum 630 days of security, my private and confidential messages and photos would still be something I would never want to have leaked. Mobile phones of government and big business employees are juicy targets and I can definitely see how some people would want to go through the effort of cracking an encrypted device even if it takes a year or two. I know of instances where Russian officials have confiscated encrypted devices of government employees of a certain country who were visiting a facility there and they certainly had the interest to throw in every attempt possible to break the encryption. This might be a marginal problem in the large scale, but to me and many others these are issues to consider.
  Anyway, I hope the FDE on Android gets some improvements rather sooner than later.
63. Re:FDE on Android doesn't work as of yet by swillden · 2015-03-04 01:30 · Score: 1
  
  I'm skeptical that an Android device would survive running flat out for two years to crack a PIN. The heat and battery life issues I experienced when I tested it demonstrate clearly that mobile devices simply aren't designed to run full-speed 24x7.
  Also, it should be pointed out that the attack I described is far from easy to carry out. Among other things, it requires dumping the contents of flash, which basically requires removing the flash chips from the mainboard without damaging it, then either putting the flash chips back or installing new flash, then the device must be unlocked, a custom, hostile OS flashed, and finally the attacker can start the multi-year process.
  Note that the 630-day figure I cited is on average. It would take twice that long for a guaranteed break.
  Finally, if you add one more character to your passcode (7-character alphanumeric), the crack time jumps from 630 days on average to 124 years.
  I agree that Lollipop FDE still needs some improvement, but it's already quite good.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
64. Re:FDE on Android doesn't work as of yet by DamnOregonian · 2015-03-04 06:54 · Score: 1
  
  I knew where you were originally going with the bandwidth vs. latency argument. That's why I threw in context. What he said *was* accurate. All you did was provide an example of how his exact wording could be inaccurate, which nobody can argue.
65. Re:FDE on Android doesn't work as of yet by Slashdot+Parent · 2015-03-04 08:42 · Score: 1
  
  Presumably the phone would lock itself down after 2 or 3 failures entering the unlock pattern.
  
  --
  They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
66. Re:FDE on Android doesn't work as of yet by DigiShaman · 2015-03-05 03:16 · Score: 1
  
  FileVault2. As for lost data, yes, I've had a ribbon SATA go bad in the laptop; notorious issue as a result in material defect / breakdown in MacBook Pro's. Anyways, that's why I keep two external USB drives with current Time Machine backups around; both encrypted too. In fact, I've done a full MBR restore from one of the drives without trouble.
  With confidence I can truly say that both my MacBook Pro and external drives are fully encrypted and a system recovery has been performed successfully. Should either my laptop or a drive get lost or stolen, I won't break a sweat and worry about the data falling into the wrong hands. I would be pissed about being $1500+ out of pocket in lost hardware however.
  
  --
  Life is not for the lazy.
Don't be lazy by cyber-vandal · 2015-03-02 22:19 · Score: 3, Informative

Learn to spell Lollipop.
1. Re:Don't be lazy by Anonymous Coward · 2015-03-02 22:40 · Score: 1
  
  Learn to spell Lollipop.
  It's funny, but I never realized how fucking pointless it is to ensure certain words are spelled correctly until now.
  This would be a perfect example, especially considering the word was named after Lolly Pop, and likely derived from the term lolly, referring to tongue.
  We misspell shit all the damn time. On purpose. Perhaps you should be more selective when you feel your inner grammar nazi coming on strong.
2. Re:Don't be lazy by Anonymous Coward · 2015-03-02 22:48 · Score: 0
  
  Considering the word is over 200 years old, I think that we can safely say that the spelling of the word has been established, don't you?
3. Re:Don't be lazy by alabandit · 2015-03-02 22:55 · Score: 1
  
  If I had up vote point, you would receive them. Pointless Grammar Nazi are the lowest form of spam
  
  --
  "You are still innocent until proven guilty. What's changed is what they do to innocent people." by notnAP (846325)
4. Re:Don't be lazy by gsslay · 2015-03-02 23:10 · Score: 2
  
  It's funny, but I never realized how fucking pointless it is to ensure certain words are spelled correctly until now.
  So which certain words don't need to be spelt correctly?
  Do wee gett to desside owrsef watt words? Or do we need some kind of standard? Otherwize who nos wat problems mite be cozzed.
5. Re:Don't be lazy by Anonymous Coward · 2015-03-02 23:23 · Score: 0
  
  I think it would be time to rename them to "Grammar Republicans"...
6. Re:Don't be lazy by cyber-vandal · 2015-03-02 23:23 · Score: 1
  
  It's not a grammar mistake it's a misspelling of the OS' name in the title of the story which is spelled as Lollilop
7. Re:Don't be lazy by cyber-vandal · 2015-03-02 23:25 · Score: 4, Informative
  
  The title is Google Backs Off Default Encryption on New Android Lollilop Devices. That is a spelling mistake.
8. Re:Don't be lazy by Anonymous Coward · 2015-03-02 23:55 · Score: 0
  
  Considering the word is over 200 years old, I think that we can safely say that the spelling of the word has been established, don't you?
  I'd say nothing is safe regarding the history of the word.
  http://en.wikipedia.org/wiki/Lollipop
9. Re:Don't be lazy by Anonymous Coward · 2015-03-02 23:57 · Score: 0
  
  Wow, you're a genius... from the page you cite... "The term 'lollipop' was recorded by English lexicographer Francis Grose in 1796."... from OED.
10. Re:Don't be lazy by Anonymous Coward · 2015-03-02 23:59 · Score: 0
  
  The title is Google Backs Off Default Encryption on New Android Lollilop Devices. That is a spelling mistake.
  The real mistake was assuming anyone would actually give a shit about said spelling mistake.
  The irony is in the history of the word, and how words become misspelled over time, which tends to question whether the dictionary spelling is right.
11. Re:Don't be lazy by Anonymous Coward · 2015-03-03 00:05 · Score: 0
  
  It's funny, but I never realized how fucking pointless it is to ensure certain words are spelled correctly until now.
  So which certain words don't need to be spelt correctly?
  Do wee gett to desside owrsef watt words? Or do we need some kind of standard? Otherwize who nos wat problems mite be cozzed.
  Yes, let's "axe" society what they think should be proper spelling and pronunciation...what say you, Director of Official Languages. How's dat Ebonics working out?
12. Re:Don't be lazy by fisted · 2015-03-03 00:21 · Score: 1
  
  If I had up vote points, you would receive them.
  FTFY
  
  --
  CLI paste? paste.pr0.tips!
13. Re:Don't be lazy by cyber-vandal · 2015-03-03 01:23 · Score: 2
  
  It's spelled as Lollilop in the headline. Given that the name of the OS is Lollipop, it's a fairly glaring error.
14. Re:Don't be lazy by gsslay · 2015-03-03 01:45 · Score: 1
  
  I truly have no idea what point you are trying to make. Where do I say that "society" should be asked on proper spelling? What the hell has Ebonics got to do with it?
  Different dialects of English pronounce words in different ways. Attempts to get a unified spelling based on pronunciation would be fruitless. This is why we have spelling as it is now; often archaic and often non-intuitive. But it's a standard that can be used by all to ensure accuracy and ease of reading.
  If we decide, on the other hand, that certain words are exempt from that standard, then the first thing we need to do is determine which are the certain words. Then I'd be interested in what logic determined which words.
  Otherwise we may as well give up on spelling and say you can spell all words however you like. Just don't complain if people can't follow you.
15. Re:Don't be lazy by Anonymous Coward · 2015-03-03 07:18 · Score: 1
  
  So you think, given time, people will start spelling "lollipop" as "lollilop" (L-O-L-L-I-L-O-P)? Will they pronounce it differently, too?
  This isn't an example of our evolving language. It's a fairly straightforward misspelling.
So this is why I've been wanting to write ... by eighthdev · 2015-03-02 22:25 · Score: 1

... a secure notepad which syncs between devices. Because you can't rely on Google or Microsoft when it comes to your data's security. But two different business consultants persuaded me to write 8th instead (which I was going to do in any event, to get to the secure notepad). Now I'm seriously weighing whether or not to take up the secure notepad project again
1. Re:So this is why I've been wanting to write ... by stephanruby · 2015-03-02 22:52 · Score: 1
  
  ... a secure notepad which syncs between devices. Because you can't rely on Google or Microsoft when it comes to your data's security. But two different business consultants persuaded me to write 8th instead (which I was going to do in any event, to get to the secure notepad).
  Now I'm seriously weighing whether or not to take up the secure notepad project again
  There are already secure notepads on Google Play. That being said, my own impression of those apps could be flawed, so you should test if those two business consultants are serious. Ask them what other similar apps they've tried. Ask them how much they're willing to contribute to your project if you start a Kickstarter on it.
  Talk is cheap. Ideas are cheap (especially if it makes them sound important). Just ask them to put money where their mouths are.
2. Re:So this is why I've been wanting to write ... by Anonymous Coward · 2015-03-02 22:56 · Score: 0
  
  Go ahead. In the meantime, what is "8th"? No amount of Google-fu is going to find something called that without more context.
3. Re:So this is why I've been wanting to write ... by Anonymous Coward · 2015-03-02 22:58 · Score: 0
  
  Because there is some Law Enforcement protocol that demands phones be gettable by many agencies (and European crackers), so real effective encryption might break law enforcement software, if the standard state security API hook was somehow disabled. It could also break corporate BYOD management software. Like SuperFish, there is strong sucking up to other interests, and screw hard user privacy(with no back-doors). If the big phone names had the balls, they could release Security Extended editions, say a Galaxy whatever(SE), with new firmware released daily with different hook points, and control tables that change a lot. It would be legal, documented, only this time, casual snooping by low skilled monkeys would cost a bit more. Give it time, and someone may move in and fill this gap. If properly approached, custom firmware could 'leak' bogus data and not quite right timestamps of the owners choice.
4. Re:So this is why I've been wanting to write ... by Anonymous Coward · 2015-03-03 00:32 · Score: 0
  
  Law enforcement should have no problems with full disk encryption. If they want in, they produce a search warrant. And then you're required to hand over the password, or they arrest you.
  It is not as if they have problems with the (optional) encryption some people deploy already. They like to tap wires and data traffic without you knowing - they don't do much of that secret snooping inside the file system. They may snoop when they have the device - but you know it when they have your device. So such snooping isn't secret anyway, which means they don't loose anything by extracting the password through a search warrant (or a judge, if you decide to not cooperate anyway . . .)
5. Re:So this is why I've been wanting to write ... by eighthdev · 2015-03-03 02:22 · Score: 1
  
  "8th" is a cross-platform development language, you can find out more at the site 8th-dev.com - sorry about the lack of Googleability of the name...
6. Re:So this is why I've been wanting to write ... by eighthdev · 2015-03-03 02:26 · Score: 1
  
  Good point. Because I've recently had a number of people say they would "definitely" use my product if I developed it. Of course as you say, talk is cheap.
7. Re:So this is why I've been wanting to write ... by f3rret · 2015-03-03 02:51 · Score: 1
  
  And then you're required to hand over the password, or they arrest you.
  "You have the right to remain silent", you cannot be compelled into testifying or giving testimony.
  I think it's the Fifth constitutional amendment, but what do I know. We have the same rights here in Denmark.
  Granted a refusal to testify might be construed as an indication of guilt in and of itself.
  
  --
  Admit nothing. Deny Everything. Make Counter-accusations.
FDE is unreliable in Android by ad454 · 2015-03-02 22:45 · Score: 2

So many people have issues when it comes to enabling and using FDE (full disk encryption) with Android.
Quite often when they upgrade their OS they are advised to first decrypt their OS in order to avoid bricking their devices or losing data.
When when there is no FDE and users try to enable it, it often fails, especially with 3rd party OS such as Cyanogenmod, often due to partition issues such as the main file system overlapping the crypto footer region, forcing many to give up in order to avoid having to repartition and then reinstall OS, apps, data, etc.
Forcing FDE in all future Android version as the default, just as Apple does with iOS, will ensure that always-on encryption is normal consistent state which is always tested against, instead of the messy mixed encrypted and unencrypted Android ecosystem we have today.
1. Re:FDE is unreliable in Android by fuzzyfuzzyfungus · 2015-03-02 23:01 · Score: 1
  
  There's also the problem that, given the fairly tight power constraints and often mediocre storage in phones, even fully fixed software is going to be somewhat mediocre if the hardware producers aren't shoved to support the feature.
  
  On the PC side, it doesn't matter as much, it's downright tricky to buy a slow CPU and only modestly costly to get a really fast SSD, so doing FDE fully in software is relatively painless(though you can also get hardware support, of TCG Opal is your thing). Phones, not so much. Especially in the cheaper seats there are often some fairly terrible storage performance at the best of times, and while modern CPUs are fast when asked to be, you'll pay in battery life for every second they spend not sleeping.
Android privacy guard app by Anonymous Coward · 2015-03-02 22:55 · Score: 4, Interesting

Do you remember back in Android 4.3 where Google added a feature similar to Cyanogenmod's "Privacy Guard"? That let you withhold rights to your contacts, Wifi, camera, microphone, GPS etc. from Apps selectively? Regardless of what the App demanded?
Then later they withdrew the app, and it never appeared again, they claimed it broke applications, yet the one in Cyanogenmod and Paranoid Android distributions work fine. Yet Google withdrew their privacy feature.
http://www.pixeldynamo.com/editorial/2013/12/14/1869/google-withdraws-android-privacy-tools/
"It was a surprise therefore, to find that Android 4.3 contained an undocumented feature, the Android Permissions Manager, or AppOps. Pictured below, AppOps groups applications based upon the type of permissions requested (Location, Personal, Messaging), ordering them by how recently they used that feature."
"Tapping on any app then shows all permissions granted to the application in question, allowing you to toggle them at will. iOS includes a similar feature, albeit with less granularity, listing applications under broad categories such as location, contacts, photos, and calendar access, again allowing users to see what has requested access, and, if they prefer, disable it."
"In the second point release of Android 4.4, Google has now withdrawn AppOps, claiming it was never intended to be accessed by end users."
-------
Do you know you handed Google your wifi password?
You did that when you handed your wife or brother your Wifi password, and when Google asked them to 'back up to their server', and they clicked yes, they handed that password to Google and to NSA via PRISM.
There are some serious issue in Android, and encryption is just the latest of them.
1. Re:Android privacy guard app by Anonymous Coward · 2015-03-02 23:59 · Score: 0
  
  Yeah, the security implications of this one have often confounded me.
  "Hey, can I have your wifi password?"
  "What, so that you can back it up to (and therefore give it to) Google? I don't think so."
  "Jerk".
  It doesn't *have* to be that way. They could encrypt that data so that to them it's just an opaque blob.
  As https://code.google.com/p/android/issues/detail?id=57560 points out, while the "backup to google" is a google service and not AOSP feature, AOSP does provide the framework for backup vendors to plug into and could implement encryption of backups so that any backup vendor "plugin" like google's would automatically have the payload encrypted so that no said vendors would have access to the data.
  The part that makes this problem hard is gating giving your wifi password to people who have strong backup passphrases, if they are user-dependent. Whole conversations around the strength of backup password needing to gate getting my wifi password is probably not terribly workable.
  Perhaps somehow (wavy hands here), WAP owners need to be able to opt their wifi password out of that back up.
2. Re:Android privacy guard app by Anonymous Coward · 2015-03-03 00:25 · Score: 0
  
  They claim to encrypt the data, although thats only transit. So people sort of think its encrypted. Yet you can take another Android device, sign it up to your account and all the networks settings are restored too.
  And PRISM gave all that data to NSA.
  And politicians around the world are so far behind the loop, they don't realize what's been done.
3. Re: Android privacy guard app by Anonymous Coward · 2015-03-03 00:44 · Score: 0
  
  What are Google or NSA gonna do with your WiFi password? Send a truck to your house to download pr0n over your Internet connection? Snoop your WiFi traffic? That's useless of course, since they can get into the cabinets at Verizon, Comcast! AT&T, etc. TLS or die, man.
  Your WiFi password is a waste of time to anyone other than your neighbors. That password is about as good as The Club: some a-hole driving by your house will ignore your encrypted connection and connect to someone else's instead.
4. Re:Android privacy guard app by Overzeetop · 2015-03-03 06:22 · Score: 1
  
  Must be after 4.4.2, because I have access to AppOps on my device. Still, it would be a shame to lose this if I move to v5.
  
  --
  Is it just my observation, or are there way too many stupid people in the world?
The NSA/FBI's answer by Anonymous Coward · 2015-03-02 23:19 · Score: 0

"Sorry, the Full Disk Encryption feature has been disabled by your carrier. For your safety, they have also locked the bootloader."
This looks like a canary by cloud.pt · 2015-03-02 23:20 · Score: 1

This has all the nuances of Android file system's own version of a warrant canary: it was there, by default, until it wasn't.
Makes it easy for the NSA to distinguish those that feel the need to encrypt their data, and those who don't. I'm betting this flag is passed to Google's server for some business logic reason (reason being "unspecified" due to non-disclosure of law enforcement requests).
1. Re:This looks like a canary by Anonymous Coward · 2015-03-03 00:48 · Score: 0
  
  Lately we've been hearing a lot about the tax loopholes that allow big companies -- especially the IT giants -- to setup an office in Ireland which receives "royalties" from other tax jurisdictions, thus bringing their taxable profit to virtually zero in those other tax jurisdictions.
  US Government probably said to Google: "Say, it'd be a shame if something were to happen to those tax loopholes."
  If those loopholes are closed-off, Google would lose many, many billions in profit every year. Do you think multiple billions are incentive enough for Google to yield to the fed gov?
2. Re:This looks like a canary by RyuuzakiTetsuya · 2015-03-03 03:11 · Score: 3, Funny
  
  Yet, Apple hasn't backed down on their disk encryption.
  My guess isn't that the NSA is demanding it, it's that vendors are more likely to be fucking it up.
  Oblig XKCD. NSA has other ways to figure this out.
  
  --
  Non impediti ratione cogitationus.
3. Re:This looks like a canary by Qzukk · 2015-03-03 03:56 · Score: 1
  
  The problem with your XKCD comic is that $5 wrenches only work on one person at a time, and they have to have already decided which person they're going to use the wrench on.
  PRISM and other wide-scale NSA dragnets are specifically designed to be as wide a net as possible so that they can collect everyone's information all the time at a minimum cost, and then later decide what to do with it. As the cost to spy on you decreases to zero, so does your ability to be "not worth" spying on.
  
  --
  If I have been able to see further than others, it is because I bought a pair of binoculars.
4. Re:This looks like a canary by cloud.pt · 2015-03-03 04:34 · Score: 1
  
  You're missing two points:
  PRISM is one program. There are many others out in the wild (as per Snowden leaks) that don't rely on bulk data collection. This dragnet you talk about is meant to do exploratory investigation, yet intelligence methods also apply to targeted data collection. Discriminating factors in this data (e.g. the fact the user is inclined to opt-in) make it the more interesting for targeted collection, although some might disagree and argue the contrary also holds true (people not encrypting data not to raise suspicion).
  Secondly, encryption by default burdens the actual relevance of the data. In the statement I made, conspiracy theory, XKCD comic, name it what you will I am also implying PRISM becomes more effective, as enabling the collection of data that is decryptable in due time renders it usable. Add the fact that opting in is made post-flashing/initial setup so the phone is exponentially more likely to have a connection to the internet during the process of opting-in/encryption. Run-time generated key is thus more likely to be passed around the cloud like an Indian smoke pipe that agencies drag from middlemen (Google) whenever they feel like getting a proverbial high.
5. Re: This looks like a canary by Anonymous Coward · 2015-03-03 08:29 · Score: 0
  
  It is. Wouldn't dare wanting the masses thinking encryption was either good, easy, or a default 'feature'. Especially! coming from a giant like google.
  If you root your droid don't forget to install xprivacy.
  Really, the only reason I see to fully encrypt the average users phone, which btw I fully agree with, is to simply piss off those who would dare to "try bitch" to decrypt it. Make a backup and be prepared to buy another phone but still fuck em, shits mine and that's how it's gonna stay.
My Nexus 4 has been encrypted since day 2. by Anonymous Coward · 2015-03-02 23:24 · Score: 0

My Nexus 4 has been encrypted since day 2. Had a Galaxy 3 before that. No issues related to encryption that I've noticed.
It doesn't feel slower.
OS upgrades have been seemless.
The only hassle is that a passphrase is required.
Ah ... one thing that isn't working, may or may not be related is my yubikey Neo doesn't NFC unlock the device always. Sometimes, it works, other times it won't.
I've lost a phone overseas and a business partner had his stolen. Knowing the data is encrypted really does provide some comfort. His phone is now in central Africa (he worked for a global cell network company) since it is blocked from use in the western world.
Encryption for any portable device is mandatory in my mind - phones, laptops, tablets, and external storage.
Required HW by Trevelyan · 2015-03-02 23:46 · Score: 1

Do Android devices have a hardware encrypter/decrypter built into the DMA bus, like iPhone does?

I would guess without something like that, encryption would have a high latency and battery life cost. Encryption accelerated via special CPU features/instructions, like what dm-crypt is able to use, would only partially alleviate those costs.

My guess the problem isn't to do with features in the Andriod software, but rather hardware costs. i.e. Development and Manufacturing costs. Does the lack of encryption really affect sales enough to justify those costs? One thing is clear: The perception of improved battery life does affect sales.

I think in the end Android will get a botched job. Encryption in SW for those that want to turn it on, but off by default as to not affect the phone's vital statistics; especially early benchmarks.
1. Re:Required HW by Gaygirlie · 2015-03-02 23:59 · Score: 1
  
  As I said in the earlier comments, ARMv8 does support AES-encryption/-decryption in hardware. Most phones out there at the moment are not ARMv8, though, so they still have to resort to software-encryption/-decryption and that is the reason why Google backed off with the requirement of defaulting to encrypting devices. Up-and-coming higher-end phones are starting to ship with ARMv8 SoCs so they can perfectly feasibly enable full-disk encryption (FDE), but low-to-mid-end devices will most likely take several years before they have H/W-accelerated AES-encryption/-decryption.
2. Re:Required HW by chowdahhead · 2015-03-03 02:19 · Score: 1
  
  Low and mid-range phones are already shipping with Cortex-a53's. Even without dedicated hardware, the overhead isn't very noticeable outside synthetic benchmarks in everyday use for older upper-tier phones https://www.youtube.com/watch?.... I think this reversal was probably done to speed up the adoption of Lollipop, particularly for all of the phones shipping with a Snapdragon 400. But I really doubt that we are years away from widespread disk encryption on phones, especially with security becoming a marketing focus.
Here's a pipe wrench by Anonymous Coward · 2015-03-03 00:15 · Score: 0

Drug him, and hit him with this until he gives up the password. Translation: FDE does nothing for you.
js.js from pixel.mathtag.com by Drethon · 2015-03-03 01:24 · Score: 1

Ok, why does this topic want me to open or save js.js from pixel.mathtag.com?
Speed penalty of encryption by hankwang · 2015-03-03 01:53 · Score: 1

Whether in hardware or software, it's still a fair amount of computation, which means battery usage and latency.
I wouldn't be so sure about that. Android will only encrypt the /data partition, not /system. That's why you can still do a factory reset on an encrypted device. I'd guess that a lot of the I/O is in /system.
Anyway, here is a 100 MiB write test (Nexus 5, Cyanogenmod 11, Android 4.4, rooted), to the /data ("sdcard") partition and to /cache (not encrypted):

sync; sync time sh -c 'dd if=/dev/zero of=/sdcard/foo.bin bs=1048576 count=100; sync; sync' 3.67 seconds sync; sync time sh -c 'dd if=/dev/zero of=/cache/foo.bin bs=1048576 count=100; sync; sync' 2.13 seconds

At 27 MiB/s versus 47 MiB/s it seems to be fast enough for me. Most apps are below 15 MB (apk size).
On a low-end, but fairly recent, LG L40/D165 phone, it's 11.2 seconds for a 100 MB encrypted write. (No root here, so I can't write to /cache for comparison). Still fast enough for me.

--
Avantslash: low-bandwidth mobile slashdot.
1. Re:Speed penalty of encryption by SilentTristero · 2015-03-03 03:19 · Score: 1
  
  Still fast enough for me.
  Sure, I agree -- it's probably fast enough for most people, myself included. It's just the extra 1.5 sec of awake time (in your benchmark -- probably a lot less for real-world workflows, but if it happens on every mail sync, podcast download, it could multiply out to minutes of additional wake time per day) that bugs me because it will likely have an effect on battery life.
  As hardware gets faster and (hopefully) less power-hungry, this should become less of an issue, so I expect I'll be happy to turn it on in a generation or two. I'm not there yet though. YMMV.
2. Re:Speed penalty of encryption by hankwang · 2015-03-03 09:58 · Score: 1
  
  if it happens on every mail sync, podcast download
  In that case, the bottleneck is the data transfer over Wifi or 3G. At least, I'm pretty sure that I never reach 27 MiB/s (270 Mbit/s) data transfer rates. The wake time will not be affected in such cases. I think it's only activities such as app startup and media indexing that are affected by slow storage bandwidth.
  And otherwise, encryption is really a must for me. With a custom ROM and bootloader (and no encryption), it's too easy for someone else to extract all personal data from the device, including credentials for my Gmail account and my banking app, both of which can have actual financial consequences.
  
  --
  Avantslash: low-bandwidth mobile slashdot.
3. Re:Speed penalty of encryption by kenshin33 · 2015-03-04 16:41 · Score: 1
  
  Lock it. Once rooted, the bootloader is lockable/unlockable at will without wiping. Plus, you don;t need to keep it unlocked once the recovery is replaced.
  Abd by default is in secure mode, meaning it need authorization, which is something honored by the recovery (CM's at least, can'st speak of other recoveries).
  Last but not least, do you own builds and sign them with your own keys! (again CM's recovery installs only and only zips that are signed with the right release key). And then you can add the extra layer of encryption.
  My beef with encryption is that it kills any chance of recovering the phone (cerberus, android device manager ... etc) if the phone is turned off.
  Let's not forget the password thingy.
4. Re:Speed penalty of encryption by hankwang · 2015-03-07 01:04 · Score: 1
  
  Locking the bootloader only prevents replacing the bootloader. For both the TWRP and the ClockworkMod boot loaders: locking does not prevent going into the bootloader (on devices that let you do this by pressing the volume button on power on, such as the Nexus 5 and Nexus 7 (2012)) and making a backup of the data partition, e.g. onto an SD card. Moreover, ClockworkMod cannot handle encrypted data partitions, which seems to make it impossible to do upgrades on a device without SD card. TWRP does support encryption, but it does not do adb authentication.
  I don't see your point about killing recovery options. With an encrypted device, it's still possible to do a factory reset. With an encrypted device + TWRP, you can even make a backup of the data partition. (My N7-2012 with stock Android corrupted the encrypted data partition on upgrade to Lollipop; only way out was a factory reset. Grrr. I flashed CyanogenMod+TWRP+encryted data, but the bug in the flash memory controller hit me and made the whole tablet unbearably slow. Grrrr!)
  
  --
  Avantslash: low-bandwidth mobile slashdot.
5. Re:Speed penalty of encryption by kenshin33 · 2015-03-14 11:37 · Score: 1
  
  a locked bootloader will prevent you from changing 1 the bootloader itself, the recovery and the modem. Unlock it and you wipe the whole phone clean (including internal storage AKA sdcard in the case of a nexus device). if you install the public (you do not build it yourself makeing sure that it DOESN'T accept test keys and ENFORCES signature verification) build of any recovery out there you're at risk because of the simple fact that signature verification of OTA packages is either disabled or accepts the know, wildly available TEST KEYS!
  Now ADB, since few years ago adb is always run in SECURE mode, meaning it will ASK when you connect the device a computer the first time (for that you need to unclock the device and ACCEPT), that is enforced in recovery (I don;t know about TWRP though, stcok CM does) that means if you never connected the device to any computer before, there's NO way in hell you're having access to ADB.
  The only downside is backup in recovery, but for that you have Titanium, or helium they do a fine job (with titanium, you can even encrypt and upload the backup to some "cloud thingy out there")!.
6. Re:Speed penalty of encryption by hankwang · 2015-03-15 09:19 · Score: 1
  
  I don't know about TWRP though, stcok CM does
  ClockworkMod (if that's what you mean by "Stock CM" bootloader) on my older Android-2.3 device has an option "Backup", which will write a backup of /data on the removable SD card; I don't even need to connect over adb (but if I try, it doesn't complain). Maybe this has changed with more recent CWM releases, but for me this was a major reason to encrypt /data on all my Android 4.x devices that run CM.
  I'm using TWRP because CWM cannot handle an encrypted data partition, so it has nowhere to store the new ROM image on devices without a physical unencrypted SD card. TWRP will happily accept an ADB connection from an unknown device. (Just to make sure: I just revoked all ADB authentications, rebooted into Fastboot (Power+Volume), selected Recovery, and connected over adb.) Anyway, because the device is encrypted with a long passphrase, I don't care that much.
  
  --
  Avantslash: low-bandwidth mobile slashdot.
7. Re:Speed penalty of encryption by kenshin33 · 2015-03-16 03:18 · Score: 1
  
  the cm recovery (i.e the one that gets built with the OTA package : out/target/product/hammerhead/recovery.img ) enforeces adb.secure, pre cm-12 looked like CWM, the new doesn't (and doesn't have a backup option either -not yet anyways-), if I clear the authorizations, I see a device in adb devices but it says simply offline, If I attempt to connect (ex: adb shell) it spits something that goes along those lines : "unlock the device, authorize then try again".
8. Re:Speed penalty of encryption by kenshin33 · 2015-03-16 03:35 · Score: 1
  
  sorry, I made a mistake : if the file: "/data/misc/adb/adb_keys" can't be open for any reason at all (fopen returns NULL), "ade.secure" is not set and it will accept connections from any computer (with root privileges no less). if it can be open , it is copied to / (in recovery) and "adb.secure" is set.
Comment removed by account_deleted · 2015-03-03 06:58 · Score: 1

Comment removed based on user account deletion
The more important questions... by jonwil · 2015-03-03 10:13 · Score: 1

1.Are all Android device manufacturers required to include support for it so users can turn it on if they want to (and are willing to accept the resulting performance hit).
and 2.Is it still the case that Google is unable to decrypt a device protected by android FDE?
NSA approval by NewYork · 2015-03-04 15:39 · Score: 1

I think NSA didn't APPROVE it;

--
Casteism