Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Google Android Cellphones Encryption Handhelds Security Upgrades

Google Makes Full-Disk Encryption Mandatory For Some Android 6.0 Devices (itworld.com) 150

Posted by samzenpus from the raise-shields dept.
itwbennett writes: Google's plan to encrypt user data on Android devices by default will get a new push with Android 6.0, also known as Marshmallow. Devices with enough memory and decent cryptographic performance will need to have full-disk encryption enabled in order to be declared compatible with the latest version of the mobile OS. From the ITWorld article: "The move is likely to draw criticism from law enforcement officials in the U.S. who have argued over the past year that the increasing use of encryption on devices and online communications affects their ability to investigate crimes. In addition to encryption, Google also mandates verified boot for devices with AES performance over 50MB/s. This is a feature that verifies the integrity and authenticity of the software loaded at different stages during the device boot sequence and protects against boot-level attacks that could undermine the encryption."
This discussion has been archived. No new comments can be posted.

Google Makes Full-Disk Encryption Mandatory For Some Android 6.0 Devices More

Google Makes Full-Disk Encryption Mandatory For Some Android 6.0 Devices

Comments Filter:

  • Sigh (Score:4, Funny)

    by Trailer Trash ( 60756 ) on Wednesday October 21, 2015 @01:03PM (#50775243) Homepage

    The terrorists and criminals have won :(

    • Apple has won, at least until the array of Andriod devices available catches up to all be resistant to government snooping.

      *ducks*

      • What does Apple have to do with this? Are you that much of an Apple freak?

        • Re:Sigh (Score:4, Interesting)

          by UnknowingFool ( 672806 ) on Wednesday October 21, 2015 @01:30PM (#50775487)
          As per the post [slashdot.org] earlier today, Apple said it was "impossible" for them to access the files on a customer's iPhone if they had a newer phone. In essence, what Apple is saying is that if law enforcement brings them only the phone of a suspect, Apple cannot technically access the files on the phone without the help of the phone's owner. They did it using a number of processes including full data storage encryption. I suspect that it has been optional on Android since not all devices had the all the hardware pieces in place to secure the phone completely.

          • Re: (Score:2)

            by antdude ( 79039 )

            I don't trust companies that they don't have access to their on encrypted datas if they (creat/mad)e them. How did they develop and test them then?

            • Um, it's not their data. It their customer's data. That's like saying you won't buy a Dell server if Dell can't break into your server.

            • I don't trust companies that they don't have access to their on encrypted datas if they (creat/mad)e them. How did they develop and test them then?

              You are a well and proper idiot, idiot.

          • As per the post [slashdot.org] earlier today, Apple said it was "impossible" for them to access the files on a customer's iPhone if they had a newer phone. In essence, what Apple is saying is that if law enforcement brings them only the phone of a suspect, Apple cannot technically access the files on the phone without the help of the phone's owner. They did it using a number of processes including full data storage encryption. I suspect that it has been optional on Android since not all devices had the all the hardware pieces in place to secure the phone completely.

            And since part of Apple's solution is hardware-based (and this is the reason that their "can't decrypt" statement does not apply to iPhones prior to either the 5 or 4s) or to phones running earlier to iOS 8 (I believe).

            If Google's solution is not at least partially hardware-based, then it is only a partial solution, which is tantamount to Security Theatre.

            Not that it matters, because most existing Android phones will never see Android 6.0, anyway.

            • If Google's solution is not at least partially hardware-based, then it is only a partial solution, which is tantamount to Security Theatre.

              That's not my reading of the situation. The benefit of Android is that it will run on many different devices. The drawbacks of Android is that it has to run on many different devices. Some Android devices have all the hardware in place to implement full encryption. Some already have. But since Google cannot dictate what hardware runs on Android, it can only dictate minimums.

              • If Google's solution is not at least partially hardware-based, then it is only a partial solution, which is tantamount to Security Theatre.

                That's not my reading of the situation. The benefit of Android is that it will run on many different devices. The drawbacks of Android is that it has to run on many different devices. Some Android devices have all the hardware in place to implement full encryption. Some already have. But since Google cannot dictate what hardware runs on Android, it can only dictate minimums.

                Ok, then I will revise my comment to read "On Devices which do not provide for some hardware security component with keys that are unknown and unreadable except within said security component (e.g., Apple's Security Enclave [apple.com]), Google's approach is tantamount to Security Theatre; because said methods are at least potentially compromise-able through legal process or "rubber-hose" crypto-analysis techniques."

                There, is that precise enough for ya?

  • Does anybody even proofread these summaries? What, precisely, is the point of a link from the words "need to have full-disk encryption enabled" to a page that doesn't mention the word encryption even a single time?

    • Ummm ... what? If you mean the first link, "crypto" appears like 25 times.

      So what, precisely, are you trying to say? Because the ENTIRE TFA is about encryption.

      • Probably should've read my full post before you replied, because I identified exactly which link I was talking about. I provided the exact phrase on which the link was placed; that link has since been moved to the words Android 6.0. (And the fact those words no longer had a link should probably have tipped you off.)

  • Verified boot by who? (Score:5, Insightful)

    by e r ( 2847683 ) on Wednesday October 21, 2015 @01:06PM (#50775283)

    Google also mandates verified boot for devices with AES performance over 50MB/s.

    Who verifies it?

    Google verifies it (with NSA consent)?
    Or is it completely, 100% open source such that I can compile my own boot loader and sign it with my own key and install it myself?

    Anything else really just means that the NSA have a backdoor to your device that you cannot remove because your boot loader is locked against you.

    • It has been opensource for ages.

      • Re: (Score:2)

        by skids ( 119237 )

        Except that the verification keys used are not public, and in general, no option to install additional trusted keys is made available. It basically kills the ability to have custom boot loaders for backup/restore or for any other reason and makes it rather easy to hard-brick the device as no utility to undo an unverifiable bootloader is made availble to the public. The age of mods is coming to an end unless consumer demand for devices that they can add keys to rises to unlikely levels.

        (Often the keys are

    • Or is it completely, 100% open source such that I can compile my own boot loader and sign it with my own key and install it myself?

      Yes.

      The Android verified boot specification requires that unlockable devices allow you to install your own verification key, to verify your own system images. Boot loaders mostly aren't open source, unfortunately, so it'll be an OEM-provided bootloader that's using your key. Google is working on that. The starting point is the new Pixel C tablet, which uses ChromiumOS's open source boot loader, so the full stack is open (though there are still bits of closed firmware, sigh).

      Oh, and note that I said *un

    • Who verifies it?

      http://source.android.com/devi... [android.com]

      http://source.android.com/devi... [android.com]

      It's a hardware key. The good news is that you can unlock it if you want.

      When you transition from a locked state to an unlocked state, the device is wiped. If the device is unlocked, there is a warning on the boot screen.

      So, if an evil organization tries to backdoor your phone (or you just want to flash another OS on it), the data is lost and a warning comes on. You are free to do as you want with the device. Should you wish to re-sell

  • Comment removed based on user account deletion

  • Honestly, this is good (Score:5, Interesting)

    by surfdaddy ( 930829 ) on Wednesday October 21, 2015 @01:17PM (#50775375)
    First Apple and now Google are pushing back on the US government, which is trying its hardest to spy on people. These companies are compelled to give up information, in secret, without warrants, due to PATRIOT Act and other government "intelligence". This has hurt business for Apple, Google, Microsoft, and others. It seems that they've decided that they are going to make it hard/impossible for the US government to steal their customers' data. Bravo to them.

    • Re:Honestly, this is good (Score:5, Insightful)

      by pla ( 258480 ) on Wednesday October 21, 2015 @01:27PM (#50775451) Journal
      Bravo to them.

      Make no mistake, they don't do this out of some love of privacy or benevolence toward their customers. Outside the US, the phrase "Made in America" has become synonymous with "pre-cracked by the NSA". Companies have no more noble goal with efforts like whole-device encryption than not watching their global sales drop to zero over the next few years.

      • Re:Honestly, this is good (Score:5, Insightful)

        by UnknowingFool ( 672806 ) on Wednesday October 21, 2015 @01:40PM (#50775575)
        I suspect also that Apple and Google don't want to be responsible any more for law enforcement duties. I can only imagine how many requests they get every week to break into someone's phone. Now they can legitimately say that they can't do it.

        • I suspect also that Apple and Google don't want to be responsible any more for law enforcement duties. I can only imagine how many requests they get every week to break into someone's phone. Now they can legitimately say that they can't do it.

          Exactly.

      • They love what their customers love. The system works.

  • DRM (Score:4, Interesting)

    by ickleberry ( 864871 ) <web@pineapple.vg> on Wednesday October 21, 2015 @01:22PM (#50775417) Homepage
    I'm gone a bit too cynical to think this is an altruistic effort by Google to protect De People from the government spying on them. Could it just be an attempt to make their DRM more robust?

    • Re:DRM (Score:5, Insightful)

      by gstoddart ( 321705 ) on Wednesday October 21, 2015 @01:28PM (#50775475) Homepage

      Possibly, but you can be cynical and not think this is altruistic ... they get the PR of saying "we're on your side" to consumers, as well as eventually saying "now piss off, we can't help you" to law enforcement.

      It can benefit consumers AND be self-serving.

      • Re: (Score:2)

        by DrJimbo ( 594231 )

        It [mandatory full-disk encryption] can benefit consumers AND be self-serving.

        Not according to the standard definitions of self-serving which includes:

        1. Serving one's own interests, especially without concern for the needs or interests of others.

        2. Exhibiting concern solely for one's own interests: serving one's own interests often in disregard of the truth or the interests of others.

        It would be more accurate to say that this may be a case where benefiting consumers also benefits the corporate interest. It is curious that you have managed to twist around something good Google has done and spin it as something negative (self-serving). I'm not claiming it was intentional on your part or that it is part of a vast conspiracy but it is part of a larger pattern. Most news stories I've seen about Google doing somethi

        • It's called enlightened self interest. Interesting concept.

        • Something someone does without concern for your needs or interests can still benefit you. For example, the guy who puts a bullet between the eyes of a gunman who's already shot 3 people, and is aiming at you now, probably did so not to save you, but to save himself. You still benefit, though, by not getting shot.

        • It is curious that you have managed to twist around something good Google has done and spin it as something negative

          Then perhaps you should read the damned comment I replied to instead of pulling this gibberish out of your backside.

          Google is a corporation. By definition, they are self-serving. It just so happens that in order to be self serving, they need to periodically align with consumer interests. But they sure don't do it all the time.

          The GP said they couldn't accept it as altruistic. I agree, ther

        • Most news stories I've seen about Google doing something good have been spun into stories about Google being evil.

          Welcome to the world of Apple News on Slashdot; where this exact form of yellow journalism has been practiced for over a Decade.

          Slashdot's just now applying the same form of Editorialism with Google.

    • I'm gone a bit too cynical to think this is an altruistic effort by Google to protect De People from the government spying on them. Could it just be an attempt to make their DRM more robust?

      No, this doesn't do anything to improve the DRM, which is already done in a separate secure OS that has always been cryptographically verified by the bootloader.

  • Priorities (Score:4, Interesting)

    by Anonymous Coward on Wednesday October 21, 2015 @01:28PM (#50775467)

    Though this is a welcome move, Google has its priorities totally wrong.

    As it stands right now, a large percentage of the Android population is running insecure software which, in some cases, is remotely exploitable without user intervention, with no way to mitigate the risk.

    This is utterly embarrassing for Android if you think about it. Here we have a (mostly) open source stack that is MUCH LESS secure than its most significant opposition - Apple, which is closed source and absolutely restricted - but we can't do anything about the vulnerabilities because someone in the supply chain decided that it isn't cost-effective to provide something as simple as root access to the OS.

    This is partly the manufacturer's and carrier's fault, but it is very much also Google's fault.

    If I understand correctly, Google has a set of conditions that manufacturers must meet to be able to ship Google apps with their phone. One of the conditions that Google should be forcing RIGHT NOW is that manufacturers (and carriers) must provide a mechanism to allow updating the operating system (or to replace it entirely).

    This shouldn't be a hard thing for Google to do. Heck, for all the evil they do, Microsoft gives you unrestricted access to the Operating System (recent host file shenanigans notwithstanding), and I've never seen a x86 PC that doesn't allow you to wipe Windows and install something else, despite the whole "secure boot" scare.

    So, Google, good move, but get your priorities straightened out.

    • Full encryption does nobody any good if the OS, as deployed, is so full of holes that the encryption isn't much of an impediment to gaining full access to everything on the device.

      I'm pretty sure that neither Android nor iOS is a true bar to getting at what's on your phone (iOS almost certainly has plenty of exploitable bugs your tax dollars have discovered or paid for information on), though it might not be information that's going to be admissible in a trial.

    • Disclaimer: While educated speculation, the following is still speculation and therefore this is not libel.

      Do you know why the new Windows phones won't work on Verizon despite having all the necessary hardware? It's because Verizon has decided to not authenticate those phones, in essence blocking a completely capable phone from their network. They get away with it because nobody cares about Windows phones. I mention that to highlight the power the carriers have over the manufacturers and OS companies.

      You wo

    • Carriers should support Phones for 2 years after the last day it was available for sale. I mean, they could simply hand over the blobs needed to get CyanogenMod running on said phone, and unlock the bootloader and pay CM to actually fulfill the need, rather than crying "Proprietary" (no, it isn't).

    • One of the conditions that Google should be forcing RIGHT NOW is that manufacturers (and carriers) must provide a mechanism to allow updating the operating system (or to replace it entirely).

      That mechanism exists, and has existed, and has been mandated, for years.

      The challenge is getting manufacturers and carriers to use it.

    • Heck, for all the evil they do, Microsoft gives you[1] unrestricted access to the Operating System

      [1]: And everybody else

      I kid, of course. But not by much.

    • As it stands right now, a large percentage of the Android population is running insecure software which, in some cases, is remotely exploitable without user intervention, with no way to mitigate the risk.

      I'd like you to cite which of the vulnerabilities actually have a real world value in being exploited. I mean there's been plenty that have come out in the past few years but they all fall into the category of:

      1. So old that they don't affect common versions of Android in use.
      2. Work on some very device specific edge case only that is completely mitigated by other security features of the devices (stagefright)
      3. Require physical access to the device.
      4. Require the user's consent. (the single most common for

      • Re: (Score:2)

        by tepples ( 727027 )

        So old that they don't affect common versions of Android in use.

        You'd be surprised how many 2.2 and 2.3 devices are still in use because Google refused to make Android updates that fit in older devices' smaller RAM.

        • I don't need to be surprised. It's 4%. These figures are published by Google. Also I'm not surprised. If this were a virus we're talking about we could claim herd immunity. If it were a targeted attack it would fail unless you're really REALLY good at picking a target demographic where you're likely to hit one of those phones, and if you look hard enough you may find these are not the kind of high-tech people who link their personal lives with their devices or have loads of international premium SMS time on

    • for all the evil they do, Microsoft gives you unrestricted access to the Operating System (recent host file shenanigans notwithstanding)

      As of Windows 10, you need to buy and renew an EV code signing certificate in order to run any drivers that you have built. This is cost prohibitive for many individual hardware hackers.

      I've never seen a x86 PC that doesn't allow you to wipe Windows and install something else

      Xbox was this way, at least until mods were figured out. So is Xbox One. So is PlayStation 4, though it comes with a FreeBSD-based operating system called Orbis OS instead of Windows.

      Another issue is drivers. A PC maker can ship Windows on its PCs and refuse to ship drivers for other operating systems, as ASUS does with its

    • If I understand correctly, Google has a set of conditions that manufacturers must meet to be able to ship Google apps with their phone. One of the conditions that Google should be forcing RIGHT NOW is that manufacturers (and carriers) must provide a mechanism to allow updating the operating system (or to replace it entirely).

      This.

      I have been saying this same thing for years now, everytime some Fandroid makes an excuse that it isn't Google's fault that Android phones never (for nearly all values of "never") get Security Updates.

      Google certainly has enough clout with the OEMs and Carriers to enforce more reasonable Update policies; but they just. Don't.

      Why?

      Because ultimately, they simply don't give a shit.

  • Who holds the keys (Score:3)

    by shuz ( 706678 ) on Wednesday October 21, 2015 @01:42PM (#50775599) Homepage Journal

    Encryption is great! It keeps data private. However only private to those who hold the keys to the encryption. What is preventing Google from creating a master key that would allow them or a government to decrypt the data. Without such a backdoor mechanism are there some countries where Google would not be allowed to deploy the newest OS? I will be curious about the legal ramifications and privacy notice connected to this next update. What legal recourse would consumers have if it were found out later that Google did in fact create a backdoor. In the US, for instance, would the patriot act absolve Google of any class action even if they did not disclose facts to the consumer?

    • This is technically possible IF Apple and Google are lying about how the symmetric key itself is generated and stored.

      The passcode is used to secure the "real" key, which is used for data encryption. This symmetric key is supposedly not predictable or retrievable. However, it could in fact be the output of crypt('$1$hfgfydhjd$', imei + masterkey)

      That would allow anyone who knows the imei and master key to derive the symmetric key.

      • This is technically possible IF Apple and Google are lying about how the symmetric key itself is generated and stored.

        The passcode is used to secure the "real" key, which is used for data encryption. This symmetric key is supposedly not predictable or retrievable. However, it could in fact be the output of crypt('$1$hfgfydhjd$', imei + masterkey)

        That would allow anyone who knows the imei and master key to derive the symmetric key.

        For Android, the code you're wondering about is all open source. Go take a look: https://android.googlesource.c... [googlesource.com]

        • They have published some code which they say is used to generate the initial master key. They are probably telling the truth, but there's no way to know - they master key looks like random bits.

          • They have published some code which they say is used to generate the initial master key. They are probably telling the truth, but there's no way to know - they master key looks like random bits.

            Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated. The master key is generated on line 1497, by reading 32 bytes from /dev/urandom. If you'd like, you can also go verify that the Android random number generator is the standard Linux RNG, unmodified (I have, but don't trust me). Then you can verify that the RNG is fed the normal stuff... network packets, user input data, etc. On devices that have one (most, these days), it's also fe

            • Thanks for taking the time to reply with such a reply response.

              > Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated.

              In that case perhaps you can clarify whether I'm misunderstanding or just didn't communicate clearly. My understanding is:

              The symmetric AES key is generated ~once, then that key is encrypted based on the password or pattern.

              By the time an end-user is using the device, the key has -already- been generated (or may hav

              • Thanks for taking the time to reply with such a reply response.

                > Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated.

                In that case perhaps you can clarify whether I'm misunderstanding or just didn't communicate clearly. My understanding is:

                The symmetric AES key is generated ~once, then that key is encrypted based on the password or pattern.

                It's generated once when the file system is first encrypted, yes.

                By the time an end-user is using the device, the key has -already- been generated (or may have been).

                May have been, but generally isn't. Usually the first time a device is booted is when the customer turns it on. Key generation and encryption happens at that point in time. This used to be a usability problem because dm-crypt didn't distinguish between in-use and unused blocks, which meant that when the user first turned on a device with on-by-default encryption, they immediately had to wait several minutes for the device to encrypt a whole bu

      • Re: (Score:2)

        by D.McG. ( 3986101 )

        https://www.apple.com/business... [apple.com]

        According to Apple, one of the many keys in the chain is unique to each device, imprinted into the silicon when the chip is fabricated, and not exposed on any pins of the chip. This doc is a great read, and even goes into how each file is encrypted with a different key.

  • I know this is an unpopular opinion but most people don't need to encrypt their phone because they have no sensitive data on it. There is always a trade-off between encryption and data integrity, and the latter is way more important for most ordinary use cases. Good voluntary encryption is nice and important for business, but mandatory encryption ... why?

    • Re: (Score:2)

      by 0123456 ( 636235 )

      I know this is an unpopular opinion but most people don't need to encrypt their phone because they have no sensitive data on it.

      Ha-ha-ha. Ha-ha-ha-ha-ha. Ha-ha-ha-ha-ha-ha-ha-ha-ha.

      You don't think that your bank app on your phone, and your email app for the email address the bank account is registered to, might be considered 'sensitive'?

      (And, no, I don't do that, because I'm not dumb enough to let anyone who steals my phone take over my bank account)

      • Apart from the fact that the author of an app can choose to encrypt data as he wishes, anyone who uses his phone for banking is just plain stupid and no amount of encryption will help that person.

    • EVERY mobile computer has sensitive data on it. IM not talking about your blog... It has locations, logs of keystrokes, visited web pages on and on. All that data is INCREDIBLY PRIVATE. You lack imagination.

    • Re:Makes no sense (Score:4, Insightful)

      by Primate Pete ( 2773471 ) on Wednesday October 21, 2015 @02:10PM (#50775861)
      I think your assumption about lack of sensitive data is incorrect.

      Virtually all android phones have a Google account password that should be protected. Many (probably most) phones have other passwords, personal data, financial data, credit cards, and other information that needs to be protected. Really, the idea that all phones need to be encrypted to prevent loss of data in case of phone theft or similar event makes sense as a default assumption. It may not protect you against the various governments, but it will help protect you against common criminals.

      • It goes without saying that apps that deal with sensitive data must encrypt it before writing it to disk. The authors of such apps should even be legally required to do so. But that has nothing to do with full disk encryption, which in most use cases is simply not needed and counter-productive (higher resource usage, lower data integrity).

    • I know this is an unpopular opinion but most people don't need to encrypt their phone because they have no sensitive data on it. There is always a trade-off between encryption and data integrity, and the latter is way more important for most ordinary use cases. Good voluntary encryption is nice and important for business, but mandatory encryption ... why?

      From section 9.9
      https://static.googleuserconte... [googleusercontent.com]

      It appears to be required to be enabled by default yet nothing seems to prevent users from disabling it.

  • About that boot encryption... (Score:5, Interesting)

    by cloud.pt ( 3412475 ) on Wednesday October 21, 2015 @02:20PM (#50775969)
    So, if I get this right, Google just made boot-level customization useless, because verified boot will pretty much prevent CWM, TWRP, unlocking the bootloader etc. There goes also easy rooting, easy custom ROMs (CyanogenMod), easy backups, MultiROM, fastboot de-bricking for the semi-knowledgeable, sideloading, custom flashing............. Right? RIGHT?

    • Re: (Score:2)

      by rduke15 ( 721841 )

      Mod parent up! That is exactly what I fear. The motive is not to protect the user from some government which couldn't care less about what's on my phone, but to prevent me from rooting my own device and get rid of all the crap I don't want on my phone.

  • "The move is likely to draw criticism from law enforcement officials in the U.S. who have argued over the past year that the increasing use of encryption on devices and online communications affects their ability to investigate crimes."

    ...the move is also more likely to hinder U.S. law enforcement from ABUSING their power... so you'll forgive me if I'm a little salty in saying...

    " You kinda brought this on yourselves. "

Slashdot Top Deals

news: gotcha

Close