Re: Mobile Smartphones and Encryption

[Lee Weers <weersl () CENTRAL EDU>]

A company recently discovered that the Blackberries do not encrypt the
storage card.  On older generations of phones you can do a device reset,
but it will not delete the storage card until Windows mobile 6.0.  I'm
not sure about Blackberries.

 

Thank you,

 

Lee Weers

Central College

Assistant Director for Network Services

641-628-7675

 

From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Chris Green
Sent: Monday, December 07, 2009 11:37 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] Mobile Smartphones and Encryption

 

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_ST
O.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