Re: [android-security-discuss] Re: Data-at Rest Encryption Dan Hein Tue Aug 03 22:00:10 2010
I agree, not only for corporate environments, but for mobile payment and NFC applications as well: (Pay as You Go Takes on Whole New Meaning) http://on.wsj.com/bQbmfE (Day in the life with NFC: MIT Mobile Experience Lab) http://mobile.mit.edu/emvideo/thickbox/90/400/250/field_implementation_video/vimeo/2028724 Beyond corporate environments, a key issue facing more wide-spread mass market adoption is the clunky or expensive nature of current identification and authentication mechanisms. A main issue with encryption in the mobile space is the need for one of the following: PIN entry (clunky) biometric authentication (expensive) dongle, token, or smart card (expensive and another thing to keep track of) For example, see: http://www.androidcentral.com/quick-app-lockpicker (Did you see that?! Let me paraphrase: 'It was annoying so I just hacked around it'! Doh!) On of the main barriers facing more widespread adoption of FDE, or to a lesser degree, selective encryption of individual files is the need to provide (something you know/are/have) to identify authorized users. You must provide an external identification input to seed and salt a hash or otherwise decrypt, or otherwise re-generate one or more bulk decryption keys (so you can actually access your data again). Without an external input, the designer is forced to store the key somewhere on the device, which is not acceptable (memory space of a typical device may be 2^32 to 2^34 but the key search space to brute force AES-256 is 2^256 ); you can therefore scan memory for the key much easier than brute force guessing, which reduces the effective security of the encryption. I do have an idea to balance the expense of biometrics with the clunky nature of PIN entry however. The compromise hinges on the ability for users to seamlessly locate their phones and perform remote wipe. At rest encryption, or FDE only "kicks in" when network connectivity is lost or the device enters airplane mode, thus minimizing the clunky nature of PIN entry. In effect, the user is only required to enter a PIN in situations where they would NOT be able to remotely locate the device. When booting for the first time or coming out of airplane mode users would be required to enter a PIN (or optionally scan a QR-based authentication ID with the camera). As to the original topic, FDE: To a large extent, BlackBerry seems to have already solved the problem of data at rest and data in transit encryption; and they've been at it for some time. http://docs.blackberry.com/en/admin/deliverables/3940/file_encryption_STO.pdf For Android, it's a matter of timing--financial applications for mobile banking, NFC, payment exchange, and increased public awareness will drive mass market demand for better authentication mechanisms (or cloud solutions providing locate/lock/wipe). I think manufacturers will be reluctant to add component cost for hardware required to support more seamless identification methods until these financial applications reach a critical mass. Here too, I'm primarily discussing the US market. I know many financial applications are already deployed and used routinely in other parts of the world; but still not en-masse on Android. To some degree, what device manufacturers and Google Android engineers do on the platform as a whole will depend in no small part to Verizon, AT&T, and T-Mobile as they work with financial services companies to deploy NFC payment systems. For example, it doesn't make sense for Google or any one of the many OHA manufacturers spend time or add cost for solutions that will not be widely used (or demanded) if the mobile operators come up with some totally unrelated system; (i.e. a NFC ID card you 'stick' to your phone for example). If operators such as Verizon and AT&T (heaven forbid) actually go the route with a 'sticky' RFID card you 'slap' on your phone, it's going to be nowhere as slick as an integrated solution. Statistics show one of the main threats in the mobile space are lost and stolen phones, period. With a 'sticky RFID' solution, the operators are likely to offer a 'call this number if lost-or-stolen', but that's a pain without a remote location portal; e.g. perhaps I just misplaced my phone and need to find it. Additionally, a 'stick on' solution does nothing to secure the data stored on the device itself (i.e. the main point of the original post in this thread). In terms of priority, I'm of the opinion that engineering time would be best spent (in the near term) unifying disparate apps currently providing remote phone location and remote wipe services. For example, making lock/location/wipe ubiquitous across services instead of being limited to one popular email, calendar, and contact management service such as ActiveSync (albeit that one probably catches most users). I'm not alone: http://code.google.com/p/android/issues/detail?id=6358 I have seen various applications (ActiveSync in Froyo, wave-secure, etc) offering these capabilities in one form or another. The problem is, many of the add-on approaches in this space can be circumvented as shown by my earlier case-in-point: http://www.androidcentral.com/quick-app-lockpicker. A comprehensive threat analysis and system-wide security review is needed to interweave these capabilities into the platform in a way that they cannot easily be disabled if that is what a corporate IT policy dictates. Links to biometric and token based solutions: http://www.enterprisemobiletoday.com/features/security/article.php/3894751/Smartphones-to-Get-Biometric-Identity-Platform-for-Mobile-Security.htm http://na.blackberry.com/eng/ataglance/security/products/smartcardreader/ <http://docs.blackberry.com/en/admin/deliverables/3940/file_encryption_STO.pdf> On Tue, Aug 3, 2010 at 12:13 PM, Duane Blanchard <[EMAIL PROTECTED]>wrote: > Very interesting posts. I agree with both of you that this should be a > native function of the Android OS, but as Shane points out, it isn't > precluded by the OS. I'm too new still to Android and infosec to know, > but it seems to me that something akin to Sophos' SafeGuard Easy, a > full-disk encryption tool, could be implemented for Android. > > Does Touchdown encrypt contact and calendar info? I looked at the > site, but I couldn't find an answer. > > Looking for more info, I found these pages which show that others are > also hoping/asking for this: > http://krypted.com/ubuntu/looking-into-google-androids-internals/ > > I also found this page which seems to say that FDE is of little enough > value as to be dying, with which I adamantly disagree: > > http://www.infoworld.com/d/security-central/full-disk-encryption-isnt-quite-dead-359 > > This article points out that FDE and folder/file encryption systems > have difference costs in terms of cycles, and that while FDE ensures > that users can't mistakenly leave something unencrypted that should > be, the files are only encrypted on the disk, and not during transport > via e-mail, FTP, etc. > http://www.csoonline.com/article/505556/full-disk-encryption-dos-and-don-ts > > I guess I don't get why there isn't a solution for both conditions. > Some system in which resident files/folders are encrypted by the FDE, > but when a file/folder is being transmitted, it is both unencrypted by > the FDE, as happens now, but then copied to a buffer or scratch disk > and automatically encrypted and signed by the FES before being > attached. The copy on the scratch disk would of course then be > securely wiped. I suspect that there may not even be a need to create > that copy, but I really am too new to all of this. > > Any thoughts/explanations? > > Thx, > > D > > > > > On Mon, Aug 2, 2010 at 9:22 AM, Shane <[EMAIL PROTECTED]> wrote: > > There are 2 applications I have found so far. 1. Good Mobile > > Messaging Server http://www.good.com/enterprise/mobile-messaging > > 2.Touchdown, http://www.nitrodesk.com/dk_touchdownFeatures.aspx > > > > That being said, I would like to see this become native on android OS. > > If anyone has any other suggestions please share. > > > > Shane > > > > On Jul 9, 2:10 pm, steve <[EMAIL PROTECTED]> wrote: > >> I am a Droid user and potential developer. The Fortune(tm) 10 company > >> I work for is primarily a BB and now becoming an iPOD shop, with no > >> plans to use anything Android because it currently does not measure up > >> to security requirements. The latest corporate computer standard > >> calls for all mobile devices to support ROM level Data-at-Rest (DAR) > >> security, as well as remote wipe. We spend millions upgrading all our > >> laptops. With literally tens of thousands of handheld mobile devices > >> in just my company, and millios more out there, there is a huge > >> opportunity for Android. How long will it take for Android to support > >> this important enterprise need? > >> > >> Steve > > > > -- > > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > > To post to this group, send email to > [EMAIL PROTECTED] > > To unsubscribe from this group, send email to > [EMAIL PROTECTED]<[EMAIL PROTECTED]> > . > > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To post to this group, send email to > [EMAIL PROTECTED] > To unsubscribe from this group, send email to > [EMAIL PROTECTED]<[EMAIL PROTECTED]> > . > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
- [android-security-discuss] Re: Data-at Rest Encryption Shane 2010/08/02
- Re: [android-security-discuss] Re: Data-at Rest Encryption Duane Blanchard 2010/08/03
- Re: [android-security-discuss] Re: Data-at Rest Encryption Dan Hein 2010/08/03 <=