Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Android Cellphones Data Storage Encryption Google

Google Backs Off Default Encryption on New Android Lollilop Devices 124

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.
This discussion has been archived. No new comments can be posted.

Google Backs Off Default Encryption on New Android Lollilop Devices

Comments Filter:
  • by Anonymous Coward on Tuesday March 03, 2015 @06:14AM (#49170077)

    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.

    • by stephanruby ( 542433 ) on Tuesday March 03, 2015 @06:32AM (#49170123)

      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.

      • by PriyanPhoenix ( 900509 ) on Tuesday March 03, 2015 @06:51AM (#49170157) Homepage
        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.
        • 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.

          • by AmiMoJo ( 196126 ) *

            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.

          • by kenshin33 ( 1694322 ) on Tuesday March 03, 2015 @01:33PM (#49172937)
            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).
          • by Nyder ( 754090 )

            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.

        • by anybody_out_there ( 2814321 ) on Tuesday March 03, 2015 @10:04AM (#49170919)

          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.

          • by swillden ( 191260 ) <shawn-ds@willden.org> on Tuesday March 03, 2015 @02:03PM (#49173227) Homepage Journal

            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.

      • by DrXym ( 126579 ) on Tuesday March 03, 2015 @06:54AM (#49170165)
        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.
        • 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.

          • Re: (Score:2, Informative)

            by Anonymous Coward

            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 y

            • by LordLimecat ( 1103839 ) on Tuesday March 03, 2015 @11:31AM (#49171679)

              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.

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

              • 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 sto

                • 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".

                  • 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..."

                  • 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.
            • by DrXym ( 126579 )
              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.

          • 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=

            • 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

              • 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 ext

                • 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
                  • 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 encr

                    • 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
                    • 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 part

                    • 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".
                    • 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.
      • by Anonymous Coward

        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.

        • by phayes ( 202222 ) on Tuesday March 03, 2015 @10:01AM (#49170899) Homepage

          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... [androidpolice.com]

          • Re: (Score:1, Interesting)

            by Anonymous Coward

            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

      • by Anonymous Coward

        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.

      • by DigiShaman ( 671371 ) on Tuesday March 03, 2015 @08:36AM (#49170461) Homepage

        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?

         

        • by Anonymous Coward

          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.

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

          • 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

      • by mveloso ( 325617 )

        "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?

      • 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 yea

    • by moronoxyd ( 1000371 ) on Tuesday March 03, 2015 @06:35AM (#49170127)

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

      • by Anonymous Coward

        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.

      • by hankwang ( 413283 ) on Tuesday March 03, 2015 @09:24AM (#49170657) Homepage
        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.
      • by Anonymous Coward

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

      • 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?

        • by Rich0 ( 548339 )

          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.

      • by Rich0 ( 548339 )

        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.

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

      • by fph il quozientatore ( 971015 ) on Tuesday March 03, 2015 @07:08AM (#49170211) Homepage
        So the protection is only effective if someone steals my phone while it's turned off, which is, like, 0.1% of the time?
        • 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!

          • 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

            • 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:

        • by c ( 8461 )

          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.

        • by mlts ( 1038732 )

          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 en

        • by Nyder ( 754090 )

          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.

        • Presumably the phone would lock itself down after 2 or 3 failures entering the unlock pattern.

      • by swillden ( 191260 ) <shawn-ds@willden.org> on Tuesday March 03, 2015 @02:34PM (#49173587) Homepage Journal

        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.

    • 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 ri

    • 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 trustwort

    • by mlts ( 1038732 )

      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

    • by swillden ( 191260 ) <shawn-ds@willden.org> on Tuesday March 03, 2015 @02:00PM (#49173199) Homepage Journal

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

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

      Not necessarily. There have been some longstanding successful techniques [geoffboeing.com] for combining FDE and pattern lock for the screen for Nexus devices.

  • Don't be lazy (Score:4, Informative)

    by cyber-vandal ( 148830 ) on Tuesday March 03, 2015 @06:19AM (#49170089) Homepage

    Learn to spell Lollipop.

    • by Anonymous Coward

      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.

      • If I had up vote point, you would receive them. Pointless Grammar Nazi are the lowest form of spam
      • by gsslay ( 807818 )

        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.

      • 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

      • It's spelled as Lollilop in the headline. Given that the name of the OS is Lollipop, it's a fairly glaring error.

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

      • 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.
  • by ad454 ( 325846 ) on Tuesday March 03, 2015 @06:45AM (#49170147)

    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.

    • 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
  • by Anonymous Coward on Tuesday March 03, 2015 @06:55AM (#49170169)

    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.

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

  • 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).

    • by RyuuzakiTetsuya ( 195424 ) <taikiNO@SPAMcox.net> on Tuesday March 03, 2015 @11:11AM (#49171455)

      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. [xkcd.com] NSA has other ways to figure this out.

      • by Qzukk ( 229616 )

        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.

        • 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

  • 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
    • 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

      • 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?... [youtube.com]. 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 ma
  • Ok, why does this topic want me to open or save js.js from pixel.mathtag.com?
  • 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?

  • I think NSA didn't APPROVE it;

PL/I -- "the fatal disease" -- belongs more to the problem set than to the solution set. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

Working...