A lot of discussions within IT organizations are about security, and how the approved security policies must be executed and implemented. Traditionally it is not the same group of the staff that has mandated the security policies that has to implement tools and processes to have them executed. But I have seen how this “disjointed camp” trend is slowly becoming better in many organizations.

The focus of this posting is to highlight some of the options available that I have run across recently on the question of Windows Mobile security and encryption. In particular what Windows Mobile 6.1 brings and potential issues you might encounter depending on your security policies and requirements.

Native Device and File Encryption

Starting in the Windows Mobile 6 release there was native support for device and file encryption. In Windows Mobile 6.1 this was further enhanced with additional features to handle storage cards inserted into the device. This could be triggered from Exchange 2007, from System Center Mobile Device Manager (SCMDM) in a Group Policy Object (GPO), or even from a 3rd party tool on the device like Andreas Helland wrote (see http://mobilitydojo.net/2008/11/19/update-dojocrypt-goes-10/). Basically specific registry keys needs to be flipped to activate the appropriate features.

The encryption code is built into the Windows Mobile operating system so there is low over head.  The encryption on the storage card is upon write, so existing data on the card is not encrypted unless re-written. In WM 6.1 you can also specify exclusions/inclusions of directories . This can be handy to only encrypt e-mail or critical folders with line-of-business applications.

Data Recovery

Some companies require that the encrypted data can be retrieved. This may go against the reasoning behind encryption you say, but depending on your security mindset and corporate data ownership a necessary evil.  Say some important employees have important data on an encrypted storage card or device and you need to access the data, either for support or legal reasons, with or without their co-operation.

On desktops and servers there are some processes to accomplish this with encryption Key Escrow or Recovery using storage of the encryption key elsewhere. This of course brings other security risks into effect. I know the Windows Vista/Windows 2008 BitLocker technology for example accomplishes this through the Active Directory.

But on the native Windows Mobile 6 and 6.1 operating system this was not prioritized as a necessary component of the latest OS release as it would have probably required more work and back-end integration. But who knows what the future could bring if enough enterprise customers ask for it! (hint hint, this is where you have a say back to Microsoft!)

Thus if you wipe a Windows Mobile device, either from Exchange 2007 or System Center Mobile Device Manager (MDM) or other means and the encrypted storage card that was previously encrypted within the device was taken out beforehand, there is no way to read the encrypted data on the card again. It can only be read on the device it was encrypted with.

Jason Langridge’s blog entry here lays it out nicely: http://blogs.msdn.com/jasonlan/archive/2007/03/16/storage-card-wipe-and-encryption-what-s-the-deal.aspx 

- and a reference from the Windows Mobile product team themselves from their encryption FAQ:
http://blogs.msdn.com/windowsmobile/archive/2007/03/26/windows-mobile-6-storage-card-encryption-faq.aspx

Key Recovery

If your security policies require encryption key recovery processes, you may need to look at 3rd party solutions. These will of course bring an additional cost, but may also add additional security features.

Some or most solutions work around the issue by creating their own encrypted file “volumes” and backup the known key used. Thus not using the default file encryption implementation.

Possible products and links: 

Aiko Solutions SecuBox: http://www.aikosolutions.com/products/secubox-for-pocket-pc/articles/secubox-encryption-vs-windows-mobile-6-encryption/
GuardianEdge Smartphone Protection: http://www.guardianedge.com/products/smartphone-security.php
CheckPoint Pointsec Mobile: http://www.checkpoint.com/products/datasecurity/mobile/index.html 
McAfee SafeBoot: http://www.mcfee.com 
Mobile Armor DataArmor: http://www.mobilearmor.com/dataarmor.php 
Credent Mobile Guardian: http://www.credant.com/products/cmg-enterprise-edition.html 
WinMagic SecureDoc Mobile Edition: http://www.winmagic.com/solutions/securedoc-pda.html
PGP Mobile: http://www.pgp.com/products/mobile/index.html

No default workaround

Some good technical explanation and background from my colleague and resident expert Mr Dave Field (CISSP) from Enterprise Mobile on the technical aspects of using the native Windows Mobile 6.x encryption and why a workaround isn’t currently possible with the default implementation of encryption:

“The problem is that both storage card encryption and device main memory encryption is performed using keys that are auto-generated and auto-encrypted by DPAPI.  The DPAPI system key and user key are encrypted using device-specific entropy.  The user key on WM 6.1 used for encryption adds the device lock PIN/PW as entropy.  So, even if you went and found the keys in memory and uploaded them to the infrastructure, you wouldn’t be able to decrypt them using some shared password.  There is no function available to decrypt the key and provide the output.  DPAPI only decrypts the  key into memory as part of encryption/decryption operations.  DPAPI has no archiving function and is not tied into Active Directory.  When using EFS or even enrolling a certificate, the keys can be archived using active directory. 

Even if we found the registry keys for the auto-generated DPAPI keys and stored them centrally. We couldn’t re-use them elsewhere if we replaced them and used the same user PIN/PW on the new device. This is because there are a number of device characteristics used for entropy as well as the user PIN/Password.  The entropy points are not advertised for the obvious reasons…”

Wrap-up

Please comment if you have different experiences, feedback or interesting views on these issues!

References of possible further interest on this topic:

Why Device Lock PIN/Password must be configured with Windows Mobile 6.1 Device Encryption:
http://blog.enterprisemobile.com/2008/06/why-device-lock-pinpassword-must-be-configured-with-windows-mobile-61-device-encryption/
Windows Data Protection API (DPAPI): http://msdn.microsoft.com/en-us/library/ms995355.aspx
Older Mobile Encryption paper: http://www.sans.edu/resources/student_projects/200612_001.pdf
Keep Mobile Devices Safe With Encryption (Nov 2007):
http://www.informationweek.com/news/mobility/security/showArticle.jhtml?articleID=202803981&pgno=2&queryText=&isPrev=

|\\arco..
mnielsen (at) enterprisemobile.com