Slashdot Mirror


Ask Slashdot: Managing Encrypted Android Devices In State and Local Gov't?

An anonymous reader writes "I am a systems administrator for a mid size state agency. We currently offer Blackberries to our staff, but we are migrating to Android devices in the near future. Since phones have sensative data (email, documents, etc.), what is a good choice for encrypting that data? Options abound, like OS-level encryption from Motorola and Samsung, 3rd party apps from GoTrusted and even a LUKS port for Android. Does anyone have experience managing encrypted Android devices? What are the important features I should be looking at? Many thanks in advance." (And, for that matter, are there good options for doing the same with iPhones? Other options to consider?)

20 of 138 comments (clear)

  1. Don't encrypt by Anonymous Coward · · Score: 5, Insightful

    If the state isn't doing anything wrong, it doesn't have anything to hide.

    1. Re:Don't encrypt by masternerdguy · · Score: 5, Insightful
      It doesn't just have to do with hiding immoral actions (btw we don't even know what agency he works for -- he could be fracking parks and recreations), it also prevents tampering.

      I encrypt the disks on my computers not to hide anything, I will gladly decrypt my disk for the FBI if they ever asked, but to prevent outside tampering. Without encryption, an adversary can just load up a linux live cd and tamper with anything they want with root access. By encrypting the entire disk I can prevent that sort of tampering. They can still boot a live cd, but they can't tamper with the installed operating system or the data.

      Besides, there is a metric ton of personal information on any smart phone. How would you like Joe the Laptop Thief to get access to your Google account, or possibly even login information for your online banking?

      --
      To offset political mods, replace Flamebait with Insightful.
    2. Re:Don't encrypt by Calos · · Score: 3, Insightful

      Sorry, but no, not everything the government has should be open for anyone to obtain and peruse. Take this as an example, or several other blunders made by the UK government or its contractors. This has some data and discussion on the US. Personally, I'm more concerned with the general lack of responsibility for these kind of breaches in both the public and the private sector.

      Don't get me wrong, I agree with your ideal. But ideals can rarely if ever become reality. And they're not always the blessing that they would seem to be.

      --
      I vote based on politicians' actions, unless contrary to my preconceptions. Often wrong, never uncertain. #iamthe99%
    3. Re:Don't encrypt by Last_Available_Usern · · Score: 5, Insightful

      What about personally identifiable information? Should SSN's be flying around unencrypted? Just because encryption is used to conceal wrongdoing doesn't mean it's always used for that purpose.

    4. Re:Don't encrypt by aristotle-dude · · Score: 3, Funny

      > he could be fracking parks and recreations

      Gee thanks. It'll take a long time to get that mental image out of my head.

      No doubt, they should not allow exploration for natural gas deposits inside of parks.

      --
      Jesus was a compassionate social conservative who called individuals to sin no more.
    5. Re:Don't encrypt by AmiMoJo · · Score: 4, Insightful

      I encrypt because I do have things to hide. I'm a normal person. Everyone has things they want to keep private. You wouldn't be happy getting your bank statements on the back of a postcard, would you?

      Hiding stuff is normal. Everyone needs privacy. There is nothing wrong with it.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    6. Re:Don't encrypt by Man+Eating+Duck · · Score: 3, Funny

      s/authentification/authentication/g. I'm ashamed, and shall go to bed after finishing my beer :)

      --
      Are you a grammar Nazi? I'm trying to improve my English; please correct my errors! :)
  2. iPhone by masternerdguy · · Score: 3, Informative

    Considering that any meaningful encryption (I will assume you want some sort of volume group/full disk encryption) will require root access and probably a custom kernel module, you will need android. Personally I would download the source code and hack it myself, add in the encryption and other features I want, and then flash the modified ROM onto a device of choice. You can't do that on an iPhone. It worked for SELinux.

    --
    To offset political mods, replace Flamebait with Insightful.
    1. Re:iPhone by bz386 · · Score: 5, Informative

      Android has builtin encryption starting with ICS.

    2. Re:iPhone by jmorris42 · · Score: 4, Insightful

      Nice propeller spinning but forget all that crap and lets get real.

      If you want to enforce privacy of information you do two simple things.

      YOU DON"T F*CKING ALLOW IT TO WALK OUT THE FRONT DOOR.

      YOU DON"T ALLOW IT TO BE MOVED TO DEVICES OUTSIDE OF YOUR DIRECT CONTROL.

      So just say no to BYOD, let em screech and bitch all they want. Tell em straight up, if your can't work without your precious iPad then go find an employer who doesn't need to deal with laws enforcing privacy. And good luck with that in this crappy economy. Just say no to portable devices, period, unless there is a truly compelling need. Data collection and off site archiving come to mind.

      Otherwise admit you really don't care about privacy at all and get on with it and, again, you don't need to spend a lot of money on tech that won't actually work when it comes to crunch time with end user idiots.

      --
      Democrat delenda est
    3. Re:iPhone by rhsanborn · · Score: 4, Insightful

      This is why IT people have such a bad reputation. Yes, portable devices are a security risk. Our job, as IT professionals, is to come up with solutions. On the same bent, I suppose you'd also cut the link to the Internet. Wait, you obviously haven't, because you're posting on Slashdot. But you came up with clever ways to protect your system from the Internet? Then why don't you start working on coming up with ways to secure mobile devices.

      The obstructionism is well intentioned, but we have an obligation to try to support the needs of the business. Staff are more mobile, and the business is benefiting by having people more connected and better able to make decisions, even when they aren't sitting in front of a PC. So, let's make it secure.

    4. Re:iPhone by Yaztromo · · Score: 4, Informative

      Considering that any meaningful encryption (I will assume you want some sort of volume group/full disk encryption) will require root access and probably a custom kernel module, you will need android.

      iOS devices have AES 256 encryption baked right into the hardware inside the DMA path between flash storage and the main system memory. It's always enabled, and can't be disabled by users, administrators, or anyone else. No custom kernel modules required -- XNU already has built-in AES 256 support, and the platform already implements it for each and every device.

      Yaz

  3. Re:BlackBerry = Security by snowraver1 · · Score: 3, Interesting

    Has anyone here tried blackberry mobile fusion? Is it good?

    --
    Copyright 2010. All rights reserved. This comment may not be copied in any way including, but not limited to caching.
  4. Use Apple. by Anonymous Coward · · Score: 4, Funny

    Their phones don't offer any enterprise-level collaboration features whatsoever. No features, no security risk!

  5. If they're going to have Active Sync... by nighthawk243 · · Score: 4, Informative

    If you're using active sync, you can make it part of the sync policy to wipe the phone when it is marked lost. We do that quite a bit.

  6. Sandbox Application by rogueippacket · · Score: 3, Interesting

    Try something like Good for Enterprise - allow your employees to bring their own devices (this is the trend, don't try to dodge it) if they wish, and just provide them with an activation key for the application. The days of "work device" and "personal device" are over - users will use one device for both, and issuing a crippled device which only performs one of these tasks is quite draconian. The sandboxed application ensures all critical information is secure, while giving your employees the segregation between life and work they desire.

  7. You have no security. by Animats · · Score: 3, Insightful

    Assume that your carrier, cloud provider, and handset manufacturer all have access to everything on the phone.

    With Blackberry, you could run your own server, and nothing in the public infrastructure had access to unencrypted data. With Android, Google has a direct tap into your data. Encryption won't help when the layer that reads the keys is under the control of the provider.

  8. Re:state agency will take the best deal not the be by dsvick · · Score: 3, Insightful

    I would think that the fact the OP is taking to the time to ask the question and even went so far as to ask for help with things he realizes he might not even know enough to ask is pretty good evidence that they are taking security seriously. Granted, he probably has to get it approved if it a pad app, but the cost of that should be pretty small compared to the cost of the phones themselves.

  9. iOS has encryption and management built-in by plsuh · · Score: 4, Informative

    I'm a former Apple engineer, current independent consultant, so I'm not going to address the Android side. That's a lot more complicated -- I'll stick with talking about the iOS info that I know about.

    That said, wow, there's a lot of snarky comments but not a lot of information posted.

    iOS has full-device hardware encryption built-in on the iPhone 3GS and later, activated as soon as you set up a passcode. This top-level encryption layer is for quick device wipes, not for data protection. Each user data file is then encrypted on top of that using its own unique key, then set into a protection class by the app developer:

      - Complete Protection - decrypted only when the device is unlocked; file key is removed from memory when the device is locked.

      - Protected Unless Open - decrypted when the device is unlocked; if file is open when the device locks, the file stays open/decrypted.

      - Protected Until First User Authentication - decrypted on first unlock, stays decrypted until reboot

      - No Protection - file system encryption only; no per-file encryption key

    Apple has really been on developers cases to tighten down the data protection classes for their apps on iOS.

    In addition, iOS has a huge number of remote management options. Apple provides a basic management tool called Profile Manager in Lion Server, and there are third-party Mobile Device Managers (MDMs) that take the basics and go even further. You can force complex passcodes, pre-configure e-mail accounts, restrict usage of features, and so on. The enterpriseios.com site has a pretty complete listing.

    One of the cool things about using iOS MDM is that all of the configuration profiles are tied to the management profile that gets installed when the device is first enrolled with the MDM. If you're in a BYOD situation and a user leaves on bad terms, the IT department can retract the management profile, which automatically retracts all of the other configuration profiles. This will delete corporate e-mail accounts, remove in-house apps (and their data!), take away VPN and 802.1X access, and so on, without erasing the person's device entirely. All of the pictures the person took are still there, not blown away as they would be after a complete device wipe.

    Anyway, a few links that may help you out:

    http://www.apple.com/iphone/business/integration/
    http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
    http://www.enterpriseios.com/
    http://consultants.apple.com/index.php - look for consultants with the Mobility specialization
    https://help.apple.com/advancedserveradmin/mac/10.7/ - go into "Manage Users" --> "Profile Manager" on the right

    Hope this helps.

    --Paul