Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Backs Off Default Encryption on New Android Lollilop Devices

Posted by Soulskill on 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.

31 of 124 comments (clear)

  1. FDE on Android doesn't work as of yet by Anonymous Coward · · 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 · · 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 · · 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 PriyanPhoenix · · 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..."
    4. Re:FDE on Android doesn't work as of yet by DrXym · · 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.

    5. Re:FDE on Android doesn't work as of yet by Gaygirlie · · 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.

    6. Re:FDE on Android doesn't work as of yet by fph+il+quozientatore · · 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

    7. Re:FDE on Android doesn't work as of yet by Gaygirlie · · 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!

    8. Re:FDE on Android doesn't work as of yet by Anonymous Coward · · 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.

    9. Re:FDE on Android doesn't work as of yet by DigiShaman · · 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.
    10. Re:FDE on Android doesn't work as of yet by AmiMoJo · · 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
    11. Re:FDE on Android doesn't work as of yet by hankwang · · 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.
    12. Re:FDE on Android doesn't work as of yet by phayes · · 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
    13. Re:FDE on Android doesn't work as of yet by anybody_out_there · · 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.

    14. Re:FDE on Android doesn't work as of yet by c · · 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.
    15. Re:FDE on Android doesn't work as of yet by LordLimecat · · 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.

    16. Re:FDE on Android doesn't work as of yet by Anubis+IV · · 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.

    17. Re: FDE on Android doesn't work as of yet by LiENUS · · Score: 2

      Since when?

    18. Re:FDE on Android doesn't work as of yet by kenshin33 · · 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).

    19. Re:FDE on Android doesn't work as of yet by swillden · · 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.
    20. Re:FDE on Android doesn't work as of yet by swillden · · 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.
    21. Re:FDE on Android doesn't work as of yet by swillden · · 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.
    22. Re:FDE on Android doesn't work as of yet by Rich0 · · 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.

    23. Re:FDE on Android doesn't work as of yet by LordLimecat · · 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".

  2. Don't be lazy by cyber-vandal · · Score: 3, Informative

    Learn to spell Lollipop.

    1. Re:Don't be lazy by gsslay · · 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.

    2. Re:Don't be lazy by cyber-vandal · · Score: 4, Informative

      The title is Google Backs Off Default Encryption on New Android Lollilop Devices. That is a spelling mistake.

    3. Re:Don't be lazy by cyber-vandal · · 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.

  3. FDE is unreliable in Android by ad454 · · 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.

  4. Android privacy guard app by Anonymous Coward · · 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.

  5. Re:This looks like a canary by RyuuzakiTetsuya · · 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.