Mobile Smartphones and Encryption

[Chris Green <cmgreen () UAB EDU>]

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