Slashdot Mirror

← Back to Stories (view on slashdot.org)

Next Android To Enable Local Encryption By Default Too, Says Google

Posted by timothy on from the keep-it-to-yourself-bub dept.

An anonymous reader writes The same day that Apple announced that iOS 8 will encrypt device data with a local code that is not shared with Apple, Google has pointed out that Android already offers the same feature as a user option and that the next version will enable it by default. The announcements by both major cell phone [operating system makers] underscores a new emphasis on privacy in the wake of recent government surveillance revelations in the U.S. At the same time, it leaves unresolved the tension between security and convenience when both companies' devices are configured to upload user content to iCloud and Google+ servers for backup and synchronization across devices, servers and content to which Apple and Google do have access.

88 of 126 comments (clear)

  1. Good by praxis · · Score: 1

    Already the industry is realizing what it needs to do.

    1. Re:Good by Threni · · Score: 1

      Realizing there's a commercial opportunity to take advantage of, you mean?

    2. Re:Good by zlives · · Score: 1

      i guess they are tired of paying lawyer fees to pretend to fight the usgov

    3. Re:Good by mlts · · Score: 1

      Encryption transforms are computationally cheap. A MC68000 could do DES-48 with FDE [1] without a noticeable slowdown, so an ARM chip which is several decades ahead would have zero problems with the array shifting of AES.

      [1]: As per a program called Access Managed Environment by Casady & Greene, which would DES encrypt the entire hard disk. It was arguably the most thorough encryption program I've seen, offering encryption for removable media, folders, files, even tape, with various methods of recovery (master password, floppy disk, etc.)

    4. Re:Good by praxis · · Score: 2

      and when user's complain their battery lasts much shorter as the CPU is busy encrypting and decrypting constantly, then they'll switch the default back... and when user's complain that they flip flop too much, they'll make it a giant setup screen option where new user's can complain about which option is on top.

      iOS has encrypted most of its data most of the time already and iOS has not had significantly worse battery life than Android in the past. What's the crux here is not the addition of encryption, it's the location of the encryption key.

    5. Re:Good by Mike+Buddha · · Score: 4, Informative

      iOS, like Android, only encrypts all data if a user opts to put a pin in. iOS8 might be different, but all prior version of iOS only encrypted when a pin was entered.

      --
      by Mike Buddha -- Someday the mountain might get him, but the law never will.
    6. Re:Good by skids · · Score: 1

      There is actually a sort of sad irony/schadenfreude to be had here, if I could just get myself to stop chronically sobbing in a quivering ball in the corner about the general state of IT security.

      --
      Someone had to do it.
    7. Re:Good by Rosyna · · Score: 2

      Incorrect. iOS always encrypts all data with a master key based of secret data in the CPU. If you choose a pin/passcode, it is salted.

    8. Re:Good by Dr_Barnowl · · Score: 3, Insightful

      In addition to the notes that this is a minimal burden on most modern CPUs, Android L will offer much better battery life - on the same devices - owning to it's new execution environment, which will more than offset the additional cost.

      I think it's a sop though - the problem, as demonstrated so well recently to a host of famous women, is not that your local device is terribly vulnerable. After all, we're talking one of the few pieces of data storage that most people will have on their person most of their waking hours.

      The real problem is cloud storage. While much has been made of the tactics used to gain access to them, note that any sysadmin on the cloud services responsible likely has the same level of access. You'll only have "private" cloud when your device carrys a private encryption key that the service is not privy to - and this isn't going to happen on the big services (excepting MEGA, allegedly), because the reason they let you store your stuff on their cloud for free is because they can mine it for information. And could you really trust a "private" cloud client anyway? Who says the software doesn't leak your private key back to the author?

      If you want private data, Free Software is really the only answer, and having your own private hardware would help too.

    9. Re:Good by Sloppy · · Score: 1

      Already the industry is realizing what it needs to do.

      Yep. In the wake of Snowden, people need to feel better. Performing encryption on a computer that you can't trust, is the best of both worlds and gives everyone what they need.

      Users will be put at ease, manufacturers can check the "encryption" bullet point, and thanks to the computer working for someone other than the user, various other parties who "need" the data will be able to quietly get the keys without an unpleasant confrontation with the user. Everybody wins.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    10. Re:Good by praxis · · Score: 2

      If you read page nine of the iOS Security Guide, you'll learn that device storage is always encrypted with a unique key, regardless of the device lock settings.

    11. Re:Good by praxis · · Score: 1

      Already the industry is realizing what it needs to do.

      Yep. In the wake of Snowden, people need to feel better. Performing encryption on a computer that you can't trust, is the best of both worlds and gives everyone what they need.

      Users will be put at ease, manufacturers can check the "encryption" bullet point, and thanks to the computer working for someone other than the user, various other parties who "need" the data will be able to quietly get the keys without an unpleasant confrontation with the user. Everybody wins.

      Trust is not a binary. If it were, I would say I don't trust anything that I don't fully control (like the compiler trust issue), become extremely paranoid and have no sane life. I choose to have some trust in some things and live a normal life.

  2. If you believe this by zeigerpuppy · · Score: 5, Insightful

    You need your head read. Google has shown time and again that it does not care about your security. There is no need to trade off convenience for security in cloud backup. Encrypt locally and send the data encrypted to backup. This would be great but i bet that Google also holds they keys and decrypts on their end. Google says it wouldn't be able to use your data for their massive data mining and information theft machine if it were properly encrypted. This is why the data sits on their servers unprotected by encryption, they are the antithesis of your guardians of security. If you value your data, turn off all Google services and manage your own backups.

    1. Re:If you believe this by sribe · · Score: 1

      Encrypt locally and send the data encrypted to backup.

      But then you cannot make the data available to the user through web-based apps...

    2. Re:If you believe this by Noah+Haders · · Score: 1

      this is true. I get my icloud email through a web app, but I can't get imessages through a web app. pop3/imap were not designed with this level of security.

    3. Re:If you believe this by steelfood · · Score: 4, Interesting

      I know everybody talks about encryption, but the word itself is just the tip of security. What's the key size? What's the algorithm? What data is encrpyted? Is it even relevant to talk about local encryption with respect to metadata (which is just as if not more useful to the NSA than the actual data). What about backups? Is it a snapshot of the encrypted contents each time? Or does the backup use a different encryption key, and the data transferred securely? There are so many layers to security (including the user), the "encryption" buzzword is meaningless without full context.

      My guess is, Google's not encrypting anything they're really interested in. They're probably not nearly as interested in your pictures or your contact list as say, Facebook. That's data they may currently collect, but ultimately throw away. They're probably more interested in the websites you go to, the links you used followed to get there, the links you followed from that site, the people you actually contact (text, chat, etc.), the geographical location of that person as well as your location, the date and times of your conversations, the contents of your conversations, etc. Local encryption does not apply to any of that data.

      In fact, local encryption doesn't even matter much with regards to securing your phone's data. Your phone is probably leaking the encrypted data through one if not more applications. Facebook, Candy Crush, Twitter, etc. largely negate the effects of local encryption. The only thing it will do is keep your private information out of the hands of someone who picked up your lost phone and decided to keep it (or sell it).

      --
      "If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
    4. Re:If you believe this by sabri · · Score: 2

      I know everybody talks about encryption, but the word itself is just the tip of security.

      Rknpgyl gung. "Rapelcgrq" qbrf abg nyjnlf zrna "Frpherq".

      --
      I'm not a complete idiot... Some parts are missing.
    5. Re:If you believe this by swillden · · Score: 2

      You need your head read. Google has shown time and again that it does not care about your security. There is no need to trade off convenience for security in cloud backup. Encrypt locally and send the data encrypted to backup. This would be great but i bet that Google also holds they keys and decrypts on their end. Google says it wouldn't be able to use your data for their massive data mining and information theft machine if it were properly encrypted. This is why the data sits on their servers unprotected by encryption, they are the antithesis of your guardians of security. If you value your data, turn off all Google services and manage your own backups.

      There are two different threat models to consider. Device encryption protects against one, but not the other.

      The purpose of device encryption is to protect your data from someone who obtains physical possession of it, because it was lost, stolen, confiscated, etc. The goal really isn't so much to protect it from law enforcement or the NSA -- if the NSA is interested in your data, they'll get it, period -- but against people who might want to, for example, steal your bank account information, etc.

      Device encryption obviously does nothing to keep your data secret from someone you actively send the data to. If you have Google's backup services enabled on your phone, then it will back up a bunch of stuff. I don't know everything that's backed up, but I think Wifi configuration is, your list of apps are, the list of accounts on your phone, your contacts, and similar. Separately from device backup, you can also have the Google+ app upload your photos and videos automatically, and you can also configure the device to report your location, in various ways and for various services (there are several controls). Whatever you have backed up is (a) not protected by device encryption and (b) cannot be secure from whoever you backed it up to unless you have some sort of encryption key which the holder does not.

      It's also clear that anything that is stored by Google and which isn't encrypted with some key not available to Google is also accessible to the US government and local law enforcement, assuming they have the legal right to demand it from Google. Device encryption does not do anything to defend against that. This is all obvious and not in dispute. It also doesn't make device encryption worthless, it just means that it defends against different threat.

      Also, I have to say that from my perspective as a security engineer at Google you couldn't be more wrong about Google's concern for user security. Actually, if you look at the company's track record on security technology creation and deployment, I think that point is unarguable. Perhaps what you really meant to say is that Google doesn't care about your privacy, which is different from (but connected to) security. From my perspective, I think that's also wrong. It seems to me that what Google wants to do is to get your permission to make a trade, your data for targeted advertising in exchange for Google's services, and if you don't want that trade, Google wants to enable you to opt out of it (hence all of the opt out tools, privacy dashboard, etc.). Obviously, if Google is not careful to protect users' privacy, no one will be willing to make that trade, so Google is very, very careful.

      (Disclaimer: I'm a Google engineer, but I'm speaking for myself, not in an official capacity.)

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    6. Re:If you believe this by swillden · · Score: 3, Interesting

      I know everybody talks about encryption, but the word itself is just the tip of security. What's the key size? What's the algorithm?

      It uses Linux dm_crypt. Here's the source code that configures it, and protects the dm_crypt master key: https://android.googlesource.c...

      What data is encrpyted?

      The /data partition, which holds everything which isn't part of the system image. An easy way to understand the distinction is to note that on unrooted Android devices everything but /data is mounted read-only. So any data that is stored after the device leaves the factory is in /data, and is therefore encrypted, unless it's written to removable media (SD card).

      Most of the rest of your post is speculation assuming that Google is intensively mining everything backed up. I'm quite certain that's not true, but I probably shouldn't comment in more detail.

      The only thing it will do is keep your private information out of the hands of someone who picked up your lost phone and decided to keep it (or sell it).

      Yes, that's what device encryption is for.

      (Disclaimer: I'm an Android security engineer. I'm speaking for myself, not for Google.)

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    7. Re:If you believe this by skids · · Score: 1

      Also, I have to say that from my perspective as a security engineer at Google you couldn't be more wrong about Google's concern for user security. Actually, if you look at the company's track record on security technology creation and deployment, I think that point is unarguable.

      From my perspective as a WiFi network administrator, for years you've been accepting any old certificate for WPA-Enterprise PEAP authentication and not allowing the users to configure certificate the subject_match option that have been available in the underlying wpa-supplicant software all this time. Nor is there any process for oboarding for using local PKIs for WPA-Enterprise. You don't even lock in the first encountered cert until the wifi profile is deleted as apple does. Despite persistently repeated independently filed starred bug reports about it. So I find that a bit hard to swallow.

      --
      Someone had to do it.
    8. Re:If you believe this by AmiMoJo · · Score: 1

      To what data are you referring? Google holds keys for some stuff like email, which is sent in plaintext anyway and which they need to offer webmail access. They claim not to have the keys to synced browser data though, and apart from some innuendo and "of course they do" you offer no evidence to the contrary.

      Unlike Apple, Google can't recover your backups if you are completely locked out of your account and don't know the password. That suggests that they really don't have the key.

      Besides which, local encryption on your phone is designed to frustrate thrives and other people trying to rape your phone like the police. It also makes wiping easy and effective when you want to sell it.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    9. Re:If you believe this by swillden · · Score: 1

      Yeah, Android's support for enterprise has been weak. That's been a pain point for Google's own enterprise security team, though it's not really surprising because Android has been focused on the consumer space. The "Android for Work" (announced at I/O) is fixing that.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    10. Re:If you believe this by skids · · Score: 1

      Yeah, well, outside of a corporate IT despotism there is nearly no such thing as a "consumer space" at all. You can usually convince management to kick off everything that simply won't do WPA enterprise to get rid of the hassle of AAA web portals, but excluding Androids is not going to happen, so you fire up wpa-enterprise and let the chips fall where they may and try not to worry that all the Androids can get themselves phished. So it's been a more than just a "pain" but an actual security threat to millions of educational sector users. For several years.

      --
      Someone had to do it.
    11. Re:If you believe this by swillden · · Score: 2

      Yep. Google addresses it internally by requiring two-factor auth and using Device Policy to enforce pasword, lock timeout, etc. requirements. Oh, and not letting Android devices on the corporate network, only on the partitioned guest network. It is a problem, no argument there.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    12. Re:If you believe this by DeVilla · · Score: 1

      There you go! Encode it all in Polish or Swedish and no one will be able to decode it! Njrfbzr!

    13. Re:If you believe this by mjwx · · Score: 1

      I know everybody talks about encryption, but the word itself is just the tip of security.

      Rknpgyl gung. "Rapelcgrq" qbrf abg nyjnlf zrna "Frpherq".

      Ahh, the Clthulu algorithm

      --
      Calling someone a "hater" only means you can not rationally rebut their argument.
    14. Re:If you believe this by mjwx · · Score: 1

      Woah, woah, woah. Dont go contradicting his baseless rant against Google with facts.

      --
      Calling someone a "hater" only means you can not rationally rebut their argument.
  3. Really? by ArcadeMan · · Score: 2, Interesting

    Google has pointed out that Android already offers the same feature as a user option and that the next version will enable it by default.

    Why isn't it already the default setting?

    --
    Get free satoshi (Bitcoin) and Dogecoins
    1. Re:Really? by BarbaraHudson · · Score: 3, Interesting

      Because some of us really don't care if some droid somewhere is poking around in the text massages in our droids.

      And anyone stupid enough to take nude selfies, maybe they need to learn that selfies are neither an art nor an art form? Take a lesson from Mother Nature - clouds leak (it's called rain).

      I don't encrypt my phone data because I don't see any benefit for my own use, just more hassles. Just like I don't encrypt my on-disk or on-usb-key data. If/when I come into a situation where I need to, I will, but really, so far that hasn't happened.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    2. Re:Really? by Jane+Q.+Public · · Score: 1

      There's a huge problem with Android device encryption.

      Unlike Apple's usual forms of encryption, once an Android device is encrypted, it is not reversible. There is no way to UN-encrypt it, except to back up all your programs, flash your original unencrypted OS back to the phone, then restore the programs. And that requires unlocking and rooting the phone.

      There are LOTS of problems caused by that.

    3. Re:Really? by apraetor · · Score: 2

      You're right that most user data doesn't *need* to be encrypted, strictly speaking. As for nude selfies and whatnot -- if you don't like them, don't take them; just because you don't like them doesn't mean that people who WANT to take them deserve any less privacy, though. It might be dumb to have them on a device/account that can be so easily cracked, especially if you're a public figure, but that doesn't absolve the hacker of any wrongdoing.. they've still intentionally victimized someone.

    4. Re:Really? by swillden · · Score: 4, Informative

      Google has pointed out that Android already offers the same feature as a user option and that the next version will enable it by default.

      Why isn't it already the default setting?

      (Android Security Team member here... though these are my own perceptions and opinions, not an official statement.)

      Two reasons:

      First, because it's not completely trivial to make it work correctly, all the time, every time, on hundreds of different devices. Android uses dm_crypt, so the foundation is solid, well-proven code, but that doesn't mean there aren't tricky corner cases. With the huge number and variety of Android devices out there, you can be certain that if there's a way it can go wrong, it will. So, conservatism suggests it's a good idea to make it optional for a while and shake out any issues. It's been optional for three years now, and is in use on many devices (I don't know how many; I'd guess tens of millions, though), so it's time to take the next step.

      Second, performance was a problem. Not run-time performance -- AES is really fast -- but the initial encryption required reading and writing many gigabytes so it took a long time just to do that much I/O. Encrypting by default means that either the device has to be encrypted in the factory, which would be a major production bottleneck, or else users would have to wait 20 minutes for their phone/tablet to start up just after they unbox it. That's a bad user experience. For L this was optimized so it only encrypts blocks that are in use. Since on a new device very little of the data partition is in use, very little has to be encrypted. That makes the initial encryption very fast (a few seconds).

      There's actually another device encryption-related improvement coming in L. I'd love to describe it in detail since I worked on parts of it, but the article doesn't mention it so I'll hold off.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Really? by BarbaraHudson · · Score: 2

      So many people have learned the hard way that sharing nude pics or a racy video with just ONE person can lead to the whole world having it. As the beer commercial says, "Ex" says it all ...

      Quote from a 1950 movie, Born Yesterday:

      He always used to say, "Never do nothing you wouldn't want printed on the front page of The New York Times."

      It's still good advice today. We're inundated with examples of what can happen. In too many cases, the victim is guilty of contributory negligence, at the very least. Example: "What do you mean, 1-2-3-4-5 isn't a good password?"

      Dark Helmet: 1-2-3-4-5? That's the stupidest combination I've ever heard of in my life! That's the kinda thing an idiot would have on his luggage!

      Banks have already established that your funds aren't covered if you use a stupid, easy-to-guess PIN.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    6. Re:Really? by skids · · Score: 1

      The biggest conceptual mistake people make about encryption is that it is only for protecting read access. It's also for protecting against write access. Specifically to your live sessions, so that you don't merrily think you are talking to your bank when you're actually talking to a thief.

      --
      Someone had to do it.
    7. Re: Really? by Anonymous Coward · · Score: 1

      so use a complex password. It will allow a large pass phrase (and if you stick with numbers, it will just put up a number pad). Plus the device will wipe itself after so many tries, and if you think you can do it off line... Well, with complex passwords the device is protected by aes256 and good luck with that.

    8. Re:Really? by apraetor · · Score: 1

      I completely agree with your sentiment that it's really dumb to take the pictures in the first place if you aren't prepared for the risk, but that doesn't detract from the wrongness of actively stealing someone's photos. An Internet "leak" of photos isn't like a leaky pipe, they don't just appear on their own -- someone took them and shared them without the victim's permission. Negligence on the part of the victim doesn't diminish the culpability of the perpetrator; the victim may have contributory negligence in the civil courts, but stealing someone's photos, no matter how easy they made it, is still theft. Kinda like how a sexual assault victim's choice of clothing in no way mitigates the vile criminality of what was done to them.

    9. Re:Really? by BarbaraHudson · · Score: 1

      Nothing I wrote in any way gives an impression that I support, in any shape, manner or form, a "blame the victim" mentality. However, contributory negligence is a fact of life, and in no way is the same as saying "you deserved to get raped because of how you dressed."

      Picking weak, easy-to-guess passwords is contributory negligence. Ask any bank. You're using a service with certain rules, including the responsibility to choose a reasonably secure password. There's no similar rule in our society saying "It's my responsibility to dress a certain way or I'm acting in a contributory negligent way when someone gropes me in the subway." Different "problem domain." Different expectations.

      It doesn't make it right, whether it's the groper or the hacker. But pretty much every service has in their TOS a warning about choosing a non-trivial password, and many won't even approve one that's too weak.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    10. Re:Really? by mjwx · · Score: 1

      Because some of us really don't care if some droid somewhere is poking around in the text massages in our droids.

      Pretty much this.

      If the law is interested in what I had for dinner last night, they dont really need to go through my text messages to get it.

      Really important things I will not keep on my phone.

      --
      Calling someone a "hater" only means you can not rationally rebut their argument.
    11. Re:Really? by Zebedeu · · Score: 1

      Since you're in the security team, could you comment on why Android requires you to set up some sort of lock security just in order to have a VPN configured (even if it's not in use)?

      That never made any sense to me. I believe it assumes corporate use of a VPN, which makes sense that it should be secure (you don't want an unidentified party with free access to your company's internal network), but for many users it's just a way to encrypt potentially unsafe connections, such as when you're connected to some random WiFi hotspot while travelling.
      And even if you assume a sensitive VPN, the user has the option of not saving the password, so that any attacker would be unable to connect to it anyway.

      In any case I don't think it's the VPN setting's position to be enforcing security on domains outside of its control. That'd be like Android forcing me to set a PIN just because I have the Facebook app installed - "you probably have private data in that app, so we're protecting you from yourself".

    12. Re:Really? by swillden · · Score: 2

      Android security team, eh? Are you the guy who thinks that my phone implicitly trusting the Chinese government, Turktrust, et al is perfectly reasonable, while at the same that constantly complaining about my own personally verified CA is "WorkingAsIntended"?

      No.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    13. Re:Really? by swillden · · Score: 1

      I'm not sure what the motivation for that decision was. I think some of the coming work will make it less painful, though I can't provide any detail.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    14. Re:Really? by WuphonsReach · · Score: 2

      The primary reason to password protect and encrypt the phone is to protect against the mundane threat of someone who steals your phone, then tries to leverage that to gain access to your financial accounts or other accounts.

      If you travel on any form of public transit, it's a risk. (Pickpockets, muggers, etc.)

      Granted, most thieves are only after the phone for its hardware value. But others will dig into the phone and see what sort of personal information they can glean (emails, bank details, list of contacts, passwords) and then try and sell that to identity thieves.

      For modern phones, storage encryption has minimal impact on battery life.

      Having to enter a 4-10 digit number every time you unlock the phone is a minor hassle. However, there are tricks where you can tell the phone to only lock (after 15 minutes) if it can't see a certain bluetooth / wifi signal.

      --
      Wolde you bothe eate your cake, and have your cake?
    15. Re:Really? by WaffleMonster · · Score: 1

      Since you're in the security team, could you comment on why Android requires you to set up some sort of lock security just in order to have a VPN configured (even if it's not in use)?

      You know what makes even less sense than forcing people to use lock screens even if not saving VPN access credentials?

      Having infrastructure with keychain and all of that in place and then not using it in browser and Android email client to secure stored credentials.

      Even worse email client cannot be configured to prompt for passwords when checking/sending mail... you *have* to store your password.

    16. Re:Really? by Jane+Q.+Public · · Score: 1

      It's only part of the problem. The REAL big part of the problem, is that Android (so far) has insisted that your encryption password and unlock code be the same.

      So if you encrypt your phone with a secure password, like upper-and-lower-case, numbers, non-alphanumeric, and 10 characters long, then every time your phone is locked and it rings, you have to enter the entire damned thing before you can answer.

      Understandably, not many people want to do that. It's a huge pain in the ass.

      I don't have a problem so much with encryption being irreversible, but it should be separate from your unlock code.

  4. Re:Don't use a google account with Android. by Anonymous Coward · · Score: 3, Funny

    All I see from your comment is that you're also not using the Google spellchecker.

  5. Re:Don't use a google account with Android. by bobbied · · Score: 1

    And if you think I'd ever willingly put non encrypted data in any sot of could you're dreaming.

    I thought this was about ON THE HANDSET encryption?

    Which leads you to the key hiding problem.... Keys need to be plain text to be used, so they are in memory when you have a device that is encrypted. Which leads you to the problem of how to get a sufficiently complex key into the device on boot? Providing keys is where most crypto systems start to break down, and people do stupid stuff like reduce everything to a 4 digit pin or some such nonsense...

    --
    "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
  6. Re:Need to encrypt phone calls by BradMajors · · Score: 2

    Not legal. Under CALEA telephone service providers must enable law enforcement monitoring of calls.

  7. Re:Why bother when Carrier IQ and friends exist ? by Anonymous Coward · · Score: 2, Interesting

    You're right. Maybe Apple/Google cannot decrypt a phone that has been seized, but they can certainly be compelled by the government to push an OS update that enables a backdoor in a phone that is in active use.

  8. Re:Why bother when Carrier IQ and friends exist ? by Noah+Haders · · Score: 2

    what good is a phone when you are unable to speak?

  9. Are they going to fix the bugs? by wronkiew · · Score: 5, Interesting

    That's great that Google is going to enable device encryption by default. But are they going to fix the usability and security problems for Android L?

    If you enable device encryption on Android, you can no longer back up and restore your data over USB or through third party tools. You can create encrypted backups over USB, but you can't restore them because of bugs in the ADB tools. The only way to back up and restore is by uploading your data to Google's cloud servers, where your data is much more likely to be purloined than if you had just left your device unencrypted in the first place.

    When you enable encryption, you set a password. The encryption password becomes your lock screen PIN and there is no way to change it. So, which are you going to choose? A secure encryption password that you'll spend 15 seconds entering on the tiny keyboard every time you want to unlock your phone? Or a useable PIN that is trivial to crack if an attacker gets your encrypted data?

    It's clear someone added device encryption to Android to check it off the list and didn't intend for anyone to use it. I hope their product team realizes this before they bring it to a wider audience.

    1. Re:Are they going to fix the bugs? by Anonymous Coward · · Score: 1

      I agree with all your points. There are workarounds, for example third party backup based of rsync, but you got everything right with the annoyances. It's also tough to backup or rescue a system when you are encrypted.

      For people reading this you might check the play store for "Cryptfs Password", it allows you to set an encryption password different than your unlock PIN. You will need to be rooted.

    2. Re:Are they going to fix the bugs? by wronkiew · · Score: 1

      My complaints only apply to non-rooted devices.

    3. Re:Are they going to fix the bugs? by AmiMoJo · · Score: 3, Informative

      I have a Nexus 5 with a long boot time encryption password and a shorter unlock pin. Seems it was already fixed.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    4. Re:Are they going to fix the bugs? by zlogic · · Score: 2

      The encryption password becomes your lock screen PIN and there is no way to change it.

      Wrong, the encryption password has to be entered when booting the phone only. It's even different screen (ugly Android 1.6-style buttons painted black).
      I have a device with corporate policies enforced and have 3 codes to enter:
      - Encryption password
      - SIM PIN
      - Lock PIN.
      When device becomes locked after inactivity, I only need to use the lock PIN.

    5. Re:Are they going to fix the bugs? by wronkiew · · Score: 2

      I'd be interested to know how that was done.

      The cryptfs password/lock PIN issue is an open bug reported here.

    6. Re:Are they going to fix the bugs? by zlogic · · Score: 1

      Whoops, you're absolutely right. Just did a test and confirmed that indeed the pin changes the encryption password as well. Shame on me :(

  10. When will Apple silently remove the encryption? by Anonymous Coward · · Score: 1

    It is nice that Apple added encryption to iOS 4 including the encryption of email attachements. But it seems like it was a mistake to depend on it since the protection was silently removed from iOS 7. Does additional encryption in iOS 8 really matter if the feature can be silently removed with an future revision?

    I would prefer that data be encrypted by the application regardless of the OS so I can count of the behavior remaining consistent across OS upgrades.

  11. piffle by koan · · Score: 1

    Apple and Google (Android) are blowing smoke.

    --
    "If any question why we died, Tell them because our fathers lied."
  12. Re:Why bother when Carrier IQ and friends exist ? by Somebody+Is+Using+My · · Score: 2

    Do Android phones automatically update to the latest version? iPhones do not, as far as I am aware, and require the user to manually initiate the download and installation of the newest iOS firmware; this - of course - requires the user to be logged in already, at which point the data is accessible anyway.

    In other words, it sounds like this proposed vulnerability involves you being on the other side of the airlock hatchway already.

  13. Passcode Options by man_ls · · Score: 1

    Unless something has changed with a recent system update, last time I checked the local device encryption for Android disabled the Gesture and PIN input, leaving Password as the only option. I don't exactly care to enter a full-on alphanumeric password every time I take my phone out of stand-by, so the feature is of limited use.

    I prefer to use TextSecure. This hooks into the SMS and MMS handlers and redirects them from the internal store, to an encrypted store with an application passphrase. Keeps my phone easy to open up, but keeps the only data I have an interest in protecting safe.

  14. show stopper by multi+io · · Score: 4, Informative
    The device encryption feature is apparently designed to always use the lock screen password. So you're forced to have such a password, which you have to enter every time the device comes out of sleep mode, AND (much worse) it breaks essential apps like SkipLock that want to disable the lock screen under certain conditions, e.g. when you're within range of a known WiFi network, thereby relieving you of the need to enter your PIN about 5,000 times a day while you're sitting on your couch at home.

    See also https://code.google.com/p/andr...

    Unfortunately, this is a total show stopper for full device encryption.

    1. Re:show stopper by swillden · · Score: 2

      I probably shouldn't go into too much detail but, yes, the Android team has thought about and addressed that issue with L.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    2. Re:show stopper by Geeky · · Score: 2

      I've seen talk of automatically unlocking when connected to specific bluetooth devices or by location (which looks like it might require GPS?). That's handy, but I haven't seen anything about specific wifi networks. I don't want GPS running all the time because of the battery drain, but would like my phone unlocked on my home wifi. Preferably out of the box without needing a third party app that wants all sorts of permissions.

      Off topic, but for me the biggest issue with (non-rooted) Android is the permissions model that forces all or nothing acceptance for permissions. I want certain apps, but want to refuse them access to, say, SMS messages. I can't do that. The permissions manager feature appeared briefly in, I think 4.3, but then disappeared. That alone is the thing that has me considering jumping ship to Apple.

      --
      Sigs are so 1990s. No way would I be seen dead with one.
    3. Re:show stopper by swillden · · Score: 1

      Sorry, I can't comment on future changes, planned or possible.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:show stopper by Geeky · · Score: 1

      Well hopefully it's not too long to wait until L comes out and the first one will be answered. As for the second, it's just irritating that I can't get apps that just connect to their respective services. Not much chance of it, but it'd be great if the likes of Twitter and Facebook released cut down versions that only connected to them and didn't demand access to contacts, SMS etc. It's a refreshing change when an app requires no special permissions, or at least none that aren't obvious for its primary role.

      --
      Sigs are so 1990s. No way would I be seen dead with one.
  15. Which android version? by mveloso · · Score: 1

    Well, it doesn't do any good right now if it's on an android version that nobody uses. What about Pre L versions?

    And won't this really be a carrier option? And what about that sharing data part?

    1. Re:Which android version? by sd4f · · Score: 1

      I guess that means it's going to be a gradual phase in. Two years from now, 25% of devices, if history is any indicator.

  16. Re:Don't use a google account with Android. by praxis · · Score: 1

    And if you think I'd ever willingly put non encrypted data in any sot of could you're dreaming.

    I thought this was about ON THE HANDSET encryption?

    Which leads you to the key hiding problem.... Keys need to be plain text to be used, so they are in memory when you have a device that is encrypted. Which leads you to the problem of how to get a sufficiently complex key into the device on boot? Providing keys is where most crypto systems start to break down, and people do stupid stuff like reduce everything to a 4 digit pin or some such nonsense...

    Why not generate the key on the device and store it in a secure piece of hardware? That's been a pretty standard solution for a while now. I kind of imagined Android would also do the same.

  17. Re:Don't use a google account with Android. by bobbied · · Score: 1

    So, riddle me this batman... If you store the key on the device and read it automatically on boot, how's that protect you? Or are you saying that it's on an external device so I now have to keep the "key" around to boot my phone? One offers zero protection, the other consumers will hate.

    See this is what usually happens...The consumer doesn't want two devices to manage, they want one. We implement strong encryption using long keys, then we store these keys someplace "on the device" and protect them with a 4 digit pin. Consumers demand it. So we've really reduced the protection level of all that nifty encryption to that of a 4 digit encryption key.

    Sort of like what happened to WEP.... It used good encryption (in fact we STILL use the same encryption for the most part) it just bungled the key management side of things to make it useable by consumers. (OK, they did some other stuff wrong too, but the problem was key management..)

    So, I'm not saying that having a "boot key" device, simiar to an RSA token isn't a bad idea, I'm saying that most users won't stand for having something separate from their phone that they need to power it on, nor will they suffer though entering sufficiently long and complex passwords.

    --
    "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
  18. Re:Need to encrypt phone calls by pedrop357 · · Score: 1

    They are not required to deny/forbid the use of encryption on phone calls.

  19. Need to encrypt phone calls by pedrop357 · · Score: 1

    Doesn't need to be only wifi. BUT, if the provider had the key they would have to decrypt the call or turn over the key on request.

    Nothing requires the provider to interfere with me making an end-to-end encrypted call to another similar phone user. There are reliability issues that would need to be addressed, but it can be theoretically be done

    It would basically need PKI or a variant and we know how stupid people are when it comes to accepting unsigned or new certificates. I can only imagine the stupidity induced outrage that would arise when they were told that the bypasses they chose to use left their phone less secure.

    The NSA and other TLAs would work hard to compromise any central public key repository, leaving something like direct exchange or NFC the only way to really securely share public keys for the people who cared.

  20. Encryption is the least of that problem! by DigitAl56K · · Score: 2

    The only way to back up and restore is by uploading your data to Google's cloud servers, where your data is much more likely to be purloined than if you had just left your device unencrypted in the first place.

    As an Android fan, let me just say that these problems do not just stop with encryption. Unless you root your phone, you can't back it up properly because Google doesn't let you have access to your own files on your own f'ing device. Apparently nobody sees a problem in the fact that users are forced to make the decisions to either run stock or be able to access all their files. I'm sure it's to reduce piracy or something, but it's a nightmare. Unless your apps keep their data in an accessible folder or you let them keep all your settings in the cloud (if they even support that), just upgrading your handset to this years Nexus is going to mean data loss.

    I get that it makes the security stronger, but Android badly needs some kind of super-user mode that makes the entire filesystem accessible to selected apps.

  21. They will be required by July 2015 by Overzeetop · · Score: 1

    California law will require that handsets be able to be remotely disabled by the user. This is one of the easiest ways to do that - to encrypt the phone so that there is no way to operate it without entering the passcode. No resets, no workarounds. Both Google and Apple know that this is the chance to get it into the only x.0 release before that deadline.

    It's not high and mighty, it's just getting into compliance. IMHO, it's a good thing, but it's not some special high road either one is taking.

    --
    Is it just my observation, or are there way too many stupid people in the world?
    1. Re:They will be required by July 2015 by Anonymous Coward · · Score: 1

      Encrypting the phone just denies you access to the data. If you want to be about to use the phone, but are fine with losing the data, then encryption does nothing.

  22. Re: Need to encrypt phone calls by Anonymous Coward · · Score: 1

    all the law says is that they have to be able to tap into the phone call. It doesn't say that the people have to be talking in English,Swedish, French,Klingon, or clicks and squeals. In other words, encrypt your conversations, the law only says the telecos have to let them record. It doesn't say the recording has to be comprehensable to the eavesdropper.

  23. Android has long had this option, Apple marketing by raymorris · · Score: 1

    Android has had this option since approximately forever.

  24. Re:Encryption by ledow · · Score: 1

    Agreed.

    But, please, what makes you think that Apple, or even Samsung, aren't doing exactly the same?

    Apple can install stuff on your device when it feels like it. In fact, you have even less control over an Apple devices and its whims. You'll happily plug in your Exchange details into the Apple device, you have no idea what it is or isn't doing with that. Apple doesn't even have permission systems. You either install, or not. And Apple spyware is just as - if not more - rampant.

    So, your concern is really about modern devices, not anything to do with the meat of the story - encryption.

    P.S. With Android, you can see the source, and build from clean source, without any Google services whatsoever if you want. People have done it for you. Almost every big-selling Android phone is supported. You can get root access and check everything you like. And then encryption really means something.

  25. Re:Encryption by Rosyna · · Score: 1

    Apple doesn't even have permission systems.

    Apple doesn't have a permission system? Have you used iOS? It has an excellent on-demand permission system. An app wants both location, camera, and microphone access? But you don't want it to have location access? Deny it! Only want it to have microphone access sometimes? OK!

  26. Different things... by joh · · Score: 2

    As others already said, iOS had mandatory full device encryption (that you even can't disable) since 2009, when the iPhone 3G added hardware for that. What was added now is a different thing (encryption of single apps data with the key dropped from memory as soon as the device is locked).

    Full device encryption is not enough since the key needs to be in memory as long as the device runs (or no process will be able to access the file system when the device is locked).

    Also Apple's full device encryption uses a key saved in a safe enclave in the SoC, while Google's uses the PIN or password you setup for unlocking your device. If you use a PIN, this is easily brute-forced. If you use a strong password you have to type this in every time you want to use your phone. With a swipe pattern you can't use encryption at all.

    Still, it's a start. I would like to see some performance tests though, encryption in software isn't free.

    1. Re:Different things... by Maltheus · · Score: 1

      If you set up your swipe pattern first, and then encrypt from the command line, you can have a strong password for boot with a swipe to bring it out of sleep.

  27. I've got by kilodelta · · Score: 1

    An Android 4.1.2 that allows me to encrypt the entire storage on the phone. So it's nothing new.

  28. Re:Why bother when Carrier IQ and friends exist ? by WuphonsReach · · Score: 1

    Do Android phones automatically update to the latest version?

    It varies by phone and carrier. The HTC One (m8) that I have was updated this week to a new Android version. I had to approve the install and could have declined, but I did at least get an updated version.

    OTOH, my Asus tablet... is probably still running the original Android that it shipped with.

    --
    Wolde you bothe eate your cake, and have your cake?
  29. Re:Encryption by Geeky · · Score: 1

    With Android you have to accept all permissions an app wants or not install it. On iOS apps have no permissions other than internet access and have to ask for permission. The permission can be refused, and the app still works just without the feature being requested - e.g. refuse location access and the app can't offer you location based features, obviously.

    This granularity is not available with Android.

    --
    Sigs are so 1990s. No way would I be seen dead with one.
  30. CALEA doesn't apply to _everyone_ by Anonymous Coward · · Score: 1

    That's why you do it in another layer, without a service provider being involved. OS and application developers aren't telephone service providers.

    Verizon-to-government: "Here's the data you asked for."

    Government: [pats gun, grinning] "Oh, I didn't ask for it..."

    Verizon: "Just a polite euphemism."

    Government: "This is ciphertext. Um, CALEA, remember?" [strokes gun handle, stares]

    Verizon: "Sir, this binary snow is the plaintext. The ciphertext that we transported was this [more snow], and we reversed the encryption that we had added, to get you the data I just gave you. The user or his agent must have originally encrypted the data before they passed it to us. Someone else might be able to get that key, but I run the network, not the user's computer."

    Government: "But the someone-else isn't governed by CALEA."

    Verizon: "Look, you have the gun. Quit pretending you care who is governed by what. I sincerely and truthfully told you whom threatening can result in getting the key. Go get 'em, tiger!"

  31. Re:Don't use a google account with Android. by Miamicanes · · Score: 1

    ARM TrustZone can do it quite effectively... which brings about the opposite problem. The key isn't under the user's direct control, and can't be recovered by the user. The same evil can be used to encrypt proprietary binaries so they can't be pulled off and used with AOSP-derived ROMs. It doesn't matter how nominally-open the operating system is if the hardware it's running on is a black box without public documentation or drivers.

    Robust encryption whose key is under YOUR direct control (as the device's owner and end user) is a very good thing. Robust encryption that uses keys known only to the device itself is just another insidious form of DRM aiming to lock down and control the entire user experience.

    It's shit like this that's forcing me to leave AT&T and go to T-Mobile so I can have a rootable Galaxy Note 4 with unlocked bootloader. Yeah, in theory, I could buy the T-mo variant and use it on AT&T... but AT&T's new pricing structure unsurprisingly manages to be at least $10/month more than I'm spending now... and that's WITH their alleged BYOD discount. And on the slight chance they allowed me to insure a T-mobile Galaxy Note 4, I'd be completely fucked if I had to use that insurance, because they'd almost certainly replace it with a bootloader-locked AT&T version that's the entire reason for hating them in the first place.

  32. Re:Don't use a google account with Android. by praxis · · Score: 1

    So, riddle me this batman... If you store the key on the device and read it automatically on boot, how's that protect you?

    There are ways to store a key on the device and not need to read it automatically on boot. Page nine of the iOS Security Guide from September 2014 describes how Apple solves the problem.

  33. Re:Encryption by WaffleMonster · · Score: 1

    But, please, what makes you think that Apple, or even Samsung, aren't doing exactly the same?

    I assume they are.

    Apple can install stuff on your device when it feels like it. In fact, you have even less control over an Apple devices and its whims.

    What does apple have to do with TFA? For the record Apple's actions ignoring factual inaccuracies in your comments are also inexcusable as are Microsofts...etc. It doesn't matter who's doing it.

    So, your concern is really about modern devices, not anything to do with the meat of the story - encryption

    Pointing out encryption is meaningless when you don't have control over your own devices is relevant.

    P.S. With Android, you can see the source, and build from clean source, without any Google services whatsoever if you want. People have done it for you. Almost every big-selling Android phone is supported. You can get root access and check everything you like. And then encryption really means something.

    Great for the technically inclined, not so great for everyone else.

  34. They can keep it by Anonymous Coward · · Score: 1

    After reading the FA today, I enabled encryption on my i9300 (after doing a backup, of course)

    About an hour later, I had my phone back -- sluggish to do everything. And I had to enter a pin every time to unlock, not just at boot as promised (I'd be OK with that -- I can use the Android Device Manager if I lose my phone). Then I went for a TWRP restore -- and TWRP couldn't read my existing partition even after I entered my passkey, so I guess there's some mixup there... I restored from my sd card and it's like I did a factory reset -- all my user data is gone. I guess I shouldn't be surprised.

    The point is that encryption is all good and well, but if a quad-core 1.2 gHz device becomes sluggish with it on, I'm not altogether sure that I want it that badly. Especially when I can just remote-wipe with the device manager.