Loading...

android-security-discuss@googlegroups.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

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.