Re: Mobile Smartphones and Encryption

[Chris Green <cmgreen () UAB EDU>]

Adam,

I agree with the theory side of disk encryption and it depends on what they have to protect. I'm really pursuing what 
is workable general purpose policy?

How many characters are users willing to type as part of their security? An informal survey where no policy is 
enforced: 4N,0,5N,0,8AN,5N,0,0,0 where N  = numeric; AN = alphanumeric

BlackBerry seems incredibly well designed from a security standpoint and how they do device updates while the device is 
locked.   What I'm really looking for is someone looking at the knobs and making decisions on relative strength.  (19 
rounds of SHA256) * N**M doesn't seem like a lot of work when N is 10 and M is 4.  Things look a lot better when M is 
12 and N is 36.  Pursuing this a bit more, it does appear fairly difficult to image a blackberry/windows device with a 
password using the native protocol for imaging that interacts with the device at the software layer.  They may have 
even hid their 64bit salts + keys in a TPM-like chip.

> From a security perspective, is anyone successfully adopting 12 character passwords on devices that are commonly used 
> on one hand?  Do you segment your user population into unique mail systems/stores based on job duties and role this 
> policy out to a subset of users?  Have you rolled this out as a common policy?

Some background from our side, we are in the midst of a long-term project consolidating email systems in a highly 
distributed IT environment.  I'm really looking for a way to be as friendly as possible to people (and realizing some 
very big security/economic wins) while still pursing proper security policies.  There's always the non-compliance risk 
of "Here, use my gmail account b/c it sends to my iphone".  Yes, there are other problems that exist when that can 
happen but one thing at a time.  There's also the "if you have IMAP for historical purposes, it's not that different of 
a client" risk.

I'm having a difficult time tracking down public copies of people's policies that address this issue.  In higher ed, 
that usually means that people are either ignoring the issue or haven't reached a consensus.   That's really where I'm 
trying to wade right now:  what decisions are being made in the space?  Feel free to reply off list and I'll 
consolidate/de-identify if necessary.

Thanks,
Chris

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Adam 
Carlson
Sent: Monday, December 07, 2009 1:23 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Mobile Smartphones and Encryption

Chris,
        Depending on the types of risks you want to address, screen locks
and remote wipes are usually insufficient without disk encryption.
All you have to do to prevent a remote wipe is remove the SIM card
which usually can be done in a matter of seconds (which is longer
than it takes to realize your phone is gone and issue the remote wipe
command).  The Blackberry actually has a feature that will cause it
to go into a remote wipe countdown if it cannot phone home, which is
a nice feature.
        Unless you have disk based encryption, getting physical control of a
mobile device is pretty much game over from a security standpoint.

        Blackberry devices managed by a Blackberry Enterprise Server are
secure because they implement all of the necessary controls to
protect the data.
        Windows mobile phones with 3rd party disk encryption software can
implement similar features when managed by an exchange server but it
is typically harder to manage because you are relying on 3rd party
software to implement some of the controls.

Some other random caveats:

Blackberry devices that utilize IMAP and aren't managed by a
BES/Exchange will cache their credentials on RIM's servers in order
to deliver your email (not good in my opinion).

The iPhone "encryption" is a marketing ploy which is easily defeated
because the encryption key is stored on the device and can be easily
retrieved.  Apple says the encryption is not meant to protect the
data and is instead meant to speed up the remote wipe (because they
just have to delete the encryption key and the data becomes
unrecoverable).  Unfortunately, as I said, this is easily defeated by
popping out the SIM card and reading the encryption key from the
device with readily available software. (terrible design and grossly
confusing to the end user)

If you are truly going for a secure and manageable implementation and
are willing to spend the money, the Blackberry with BES server is
still by far the best choice.  Windows mobile with disk based
encryption is similar but harder to manage.  Everything else is a
very distant third at which point, you shouldn't worry about security
too much.

(Also in response to Lee's response, Blackberry devices can
supposedly encrypt external flash cards, you just have to set it up
correctly and it won't automatically encrypt any data that isn't
transferred to the card via the Blackberry (which makes sense):

docs.blackberry.com/en/admin/deliverables/3940/file_encryption_STO.pdf

Haven't tried it myself, but that is what they claim ;).

)

Chris Green wrote:
> Let's assume that there's support for smartphones being deployed in your user community ;-).  Phones are often lost 
> at inopportune times. Various accounting issues often mean that people bring their own cell phone rather than having 
> one assigned. Security features (in order of support), generally seem to be:
>
>
>
> 1.       screen locking (Optional on most devices),
>
> 2.       remote device reset (Supported on quite a few devices, may require 3rd party software and may not know if it 
> is successful). [
>
> 3.       and device encryption (supported on few devices, BlackBerrys (BlackBerries?)  being a notable exception). 
> [See footnotes 1,2]
>
> Screen Locking with some kind of code seems like a no-brainer recommendation although it does interfere with the most 
> common use-case of "find the contact HOME and let leave a message have their phone".
>
> Remote Device Reset seems like very good thing to require as well as you can lose the device and still be relatively 
> assured that the data got wiped if it's a known good device and you had cell phone signal.  Exchange 2007/Active Sync 
> even puts this as an very nice end user feature in "Options -> Mobile Devices -> Wipe All Data from Device" and give 
> you a way to know the time of last sync.
>
> Device Encryption, which is being relied on in many places to avoid the need to disclose regarding a lost device, 
> seems a very difficult sell and/or impossible implementation on all smart phones.    While 12 character minimum 
> passphrases may be accepted by a user base for a laptop device,  I wonder if you could realistically enforce that.  
> Auditing for out of compliance devices seems especially challenging.  Particularly with a strong possibility of 
> things like Desktop Connectors.
>
> What mobile device policies are people deploying to balance security requirements with end-user acceptance and 
> adherence?
>
>
>
> Footnotes:
>
> 1 - Blackberry Password Guidelines
> 2 - Blackberry Encryption Key generation from passphrase
> [1] "Guidelines for setting the internal memory encryption level
>
> When the content-protected BlackBerry device decrypts a message that it received while locked, the BlackBerry device 
> uses the ECC private key in the decryption operation. The longer the ECC key, the more time the ECC decryption 
> operation adds to the BlackBerry device decryption process. Choose a content protection strength level that optimizes 
> either the ECC encryption strength or the decryption time.
> If you set the content protection strength to Stronger (to use a 283-bit ECC key) or to Strongest (to use a 571-bit 
> ECC key), consider setting the Minimum Password Length IT policy rule to enforce a minimum BlackBerry device password 
> length of 12 characters or 21 characters, respectively. These password lengths maximize the encryption strength that 
> the longer ECC keys are designed to provide. The BlackBerry device uses the BlackBerry device password to generate 
> the ephemeral 256-bit AES encryption key that the BlackBerry device uses to encrypt the content protection key and 
> the ECC private key. A weak password produces a weak ephemeral key." -- 
> http://docs.blackberry.com/en/admin/deliverables/3940/file_encryption_STO.pdf
>
> [2] "Appendix E: Ephemeral AES encryption key derivation process"
>
> The BlackBerry device uses an ephemeral 256-bit AES encryption key to encrypt the content protection key and the ECC 
> private key. The BlackBerry device derives the ephemeral 256-bit AES encryption key from the BlackBerry device 
> password using the following process:
> 1. The BlackBerry device selects a 64-bit salt (random data to mix with the BlackBerry device password). This is 
> intended to keep two identical passwords from turning into the same key.
> 2. The BlackBerry device concatenates the salt, the password, and the salt again into a byte array 
> (Salt|Password|Salt).
> 3. The BlackBerry device hashes the byte array with SHA256.
> 4. The BlackBerry device stores the resulting hash in a byte array called a key.
> (key) = SHA256(Salt|Password|Salt)
> 5. The BlackBerry device hashes (key) 18 more times. It stores the result into (key) each time. For example, for i=0 
> to 18, the BlackBerry device does the following:
> (key) = SHA256(key)
> i++
> done
> 6. The final hash creates the ephemeral key.
>
>
> --
> Chris Green
> UAB Data Security, 205-975-0842

-- 
Adam Carlson
Chief Security Officer
Information Technology
Residential and Student Service Programs
Tel: 510-643-0631
Email: ajcarlson () berkeley edu

"Most of the things worth doing in the world had been declared
impossible before they were done." ~Louis D. Brandeis