An quick updated post from the one I posted previously on this.. One of these sessions is live at TechEd and the rest are being broadcasted live on TechNet starting next week. All are being presented by colleagues of mine here at Enterprise Mobile.

· Webcast: TechNet Webcast: Windows Mobile 6.1 and Mobile Device Manager 2008: The Gateway to Your Corporate Network (Level 200)
Tuesday, April 7, 2009
10:00 A.M.–11:00 A.M. Pacific Time
Attendee Registration URL: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032407362&culture=en-US
Description: “So, you are using Microsoft System Center Mobile Device Manager 2008 and Windows Mobile 6.1. Now what? You probably know that Mobile Device Manager can manage, secure, and install software on your phones. But did you know Mobile Device Manager also gives your users the potential to control the PC at their desk and access everything they need on the corporate network, including file shares, Microsoft Office SharePoint Server, instant messaging, and internal Web pages. In this webcast, we present the best practices for a Mobile Device Manager installation that provides users with access to everything they need in the corporate network through their phone and (just as important) denies access to resources mobile users don’t need. We review the basics of Mobile Device Manager and IP security (IPsec) virtual private networks (VPNs), and we discuss the tools that users can take advantage of so they can work wherever they would like using their phone. Discover how Mobile Device Manager eliminates the need to expose your organization’s Microsoft Exchange Server to the Internet.”

· Webcast: TechNet Webcast: Windows Mobile Digital Certificate Management (Level 300)�
Thursday, April 9, 2009
11:00 A.M.–12:00 P.M. Pacific Time
Attendee Registration URL: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032409997&Culture=en-US
Description:  “Digital Certificates and public/private key technology is core to Windows Mobile platform security.  In this session, you’ll learn about how certificates are used to provide authentication, access control and encryption for the OS, applications and networking..  You’ll also learn best practices and “gotchas” for managing certificates on the device.   The speaker is an expert on Windows Mobile Certificate management and certificate-related features in the OS.  Therefore, come ready to ask any questions you may have:  enrollment, import, SSL, root certificates, email security, application security, etc.”

· Webcast: TechNet Webcast: Deploying Mobile Device Manager 2008 is easier (and cheaper) than you think (Level 300)
Tuesday, April 17, 2009
11:30 A.M.–1:00 P.M. Pacific Time
Attendee Registration URL: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032410692&culture=en-US
Description: “System Center Mobile Device Manager (SCMDM) is a complex product with a lot of dependencies which must all be in place in order for it to work correctly. This session, which takes almost 2 years of hands-on experience of deploying implementing SCMDM in the field, steps through how to successfully (and cost effectively) implement this product in the enterprise. The objective of this session is to address the misconception that SCMDM is hard to implement while showing how MDM eliminates almost all of the overhead associated with Blackberrys while retaining and elevating both manageability and security.”

· TechEd 2009 “Chalk Talk” in the WM area:  Management Lockdown of Windows Mobile Devices
Tuesday, May 12, 2009
10:15 A.M.-11:30 A.M. Pacific Time
Description:  “You can completely secure a Windows Mobile device without deploying expensive third party applications. In this session we’ll show you how bar viruses, malicious and unsupported code from installing and running on the device. In addition, we’ll look at various out-of-the-box devices and analyze their threat surface. Last, we’ll describe all Windows mobile application security threat surfaces and how to manage all of them.”

Register them now and get it on your calendar!

|\\arco..

A quick heads up on some interesting new Microsoft webcasts coming up early next month on Windows Mobile Device Management and Security that may be of interest to many of you:

TechNet Webcast: Windows Mobile 6.1 and Mobile Device Manager 2008: The Gateway to Your Corporate Network (Level 200)
Tuesday, April 7, 2009
10:00 A.M.-11:00 A.M. Pacific Time

TechNet Webcast: Management Lockdown of Windows Mobile Devices (Level 300)Thursday, April 9, 2009
11:30 A.M.-12:30 P.M. Pacific Time

Register now and get it on your calendar!

|\\arco..

Windows Mobile security best practices are a key component of Enterprise Mobile’s expertise and services, but recently we’ve been much more vocal about it! First off, there’s the excellent WM Application Security White Paper that my colleague Dave Field just published. Here’s a brief synopsis:

This technical paper recommends how enterprises can take advantage of the powerful security features of Windows Mobile to defend against malicious and unsupported application use. Taking a very pragmatic approach, the paper describes how various features work and how to implement them to protect devices based on Windows Mobile 5.0, 6.0 and 6.1.

Go ahead, download the WM Application Security White Paper now, I highly recommend it for any IT professional who’s interested in Windows Mobile security. Dave has put incredible detail into this paper, making it invaluable for an organization who is currently using (or planning to deploy) Windows Mobile devices and applications.

Next up, there’s an interesting Network World article by John Cox about Mobile browser security that Dave and I are quoted in.  The article focuses on the impact that a new generation of mobile web browsers will have on how enterprise IT organizations handle mobile device security.  John sums up the three key areas that enterprises should focus on:

IT departments, according to experts, need to focus on three areas: assessing the security architecture and features in the mobile browser and the underlying operating system; working with users on smart and safe browsing practices; and creating a solid handheld device management system.

In fact, choosing a mobile platform with a strong and flexible security model in hand with a solid device management system can help you minimize the headaches that users have to endure. With those first two handled, educating users on smart and safe browsing practices is something that is applicable to both traditional desktop web browsers as well as the new crop of full-featured mobile browsers. Read the full article, titled “Mobile browsers bring new security headaches” now for more information.

This is a brand new feature of SP1 of great interest in an enterprise implementation. This mimics the similar Exchange and Windows Mobile device functionality, but without the need for any Exchange requirements. With this feature end users who have forgotten their device password or PIN, can recover (without wiping the device) and set a new device password or PIN. In this posting I will dive a little deeper and show how this all works on both the server and client side.

Overview

As nicely stated in the MDM Password Reset Client v1.0 download overview:

“MDM Password Reset Client provides a .cab file that you install on Windows Mobile 6.1 devices enrolled in MDM so that users can use the password reset feature in MDM. Password reset in MDM 2008 Service Pack 1 (SP1) enables a user who has forgotten his or her Windows Mobile device password to reset it by using MDM.

Password reset is supported on Windows Mobile 6.1 devices, starting with version 6.1.4. To use the feature, you must install the .cab file on the user’s Windows Mobile device as well as enable the feature in MDM by using Group Policy.

To reset the device password, the user chooses the password reset option, resets the device password, and then enters a one-time recovery password on the device to complete the process. The recovery password is stored on MDM servers and retrieved by the user when she or he has forgotten the device password.”

What is required?

Even though the client patch description mentioned above states it is first supported on Windows Mobile 6.1.4 or above device, the patch appears to install on some of my 6.1.1 devices. But “your mileage may vary” (YMMY) as they say..  The patch, available here, can be manually installed, but with MDM handy why not deploy it it out directly!  Please note the installation failures on the devices that are below the 6.1.1 levels.

You also need the SCMDM 2008 SP1 installation on the back-end. Especially the changes on the DM server, SQL tables, and Self Service Portal (SSP) if you wish to use that for retrieving the reset password.

How it works:

After the client patch on the devices is installed and the device locked with a PIN, triggers a local generation of a password reset key. After 2 cycles of traffic to and from the Device Management server, that recovery password will have uploaded to the SCMDM side and be available for use.  This can be verified with a cmdlet or on the MDM console by seeing that the “Display Recovery Password” action is no longer grayed out on the right hand side of the screen when a managed device is selected:
 

More details can also be found here on the overall user experience of this feature: http://technet.microsoft.com/en-us/library/dd252841.aspx

Client Functionality

These are actual screen-shots of a managed device that has the client patched installed.

In a locked state, the “Reset Password” option is no longer grayed out. Suggesting that the password reset key has been uploaded and ready to use:

After the “Reset Password” option is selected, a confirmation that the user can indeed retrieve the recovery password from an administrator or help desk.

It will then let the user create a new password. Using the same requirements that might have been enforced to the device.

Now the user must contact the administrator or help desk. In this example the administrator clicks on the “Display Recovery Password” in the MDM console and is shown the 20 digit Recovery Password that the device has uploaded into the MDM database.

The user must type in the 20 digit recovery password to validate the new password.

If there is a match with the recovery password stored on the device, the new password is granted and the device is unlocked!

Instead of the MDM console, the MDM Self Service Portal (SSP) could have been used. It also has a “Display Recovery Password” button at the bottom which will display the 20 digit recovery password:

The Password Recovery feature in the SSP is selectable by the administrator to be made available on the web site just as the Device Wipe and Device Enrollment features. Please see more information available here: http://technet.microsoft.com/en-us/library/dd261796.aspx.

Password Recovery References

SCMDM Cmdlets: http://technet.microsoft.com/en-us/library/dd261726.aspx
SCMDM User Experience: http://technet.microsoft.com/en-us/library/dd252841.aspx
Windows Mobile 6.x AKUs: http://myitforum.com/cs2/blogs/mnielsen/archive/2009/01/31/windows-mobile-6-x-akus.aspx
Windows Mobile 6.1.x Upgrades and Build Levels: http://myitforum.com/cs2/blogs/mnielsen/archive/2009/01/24/windows-mobile-6-1-x-upgrades-now-available.aspx

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

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

A lot of Enterprise Software for Mobile devices utilizes SSL for security.  SSL is the de facto choice because it can traverse NATs and routers whereas many VPNs cannot.

So, you’ll need to purchase an SSL certificate for your web server and any Windows Mobile clients should have the root of your SSL certificate in the device’s root certificate store. 

The problem comes when the root certificate is not already in the device root certificate store by default.  You can add certificates to the root store (this got a lot easier in Windows Mobile 6.0).  But, this will likely require a user trying to perform the task or the support tech will need to “touch” the device.  And, if the device is cold reset, you have to perform this task all over again.  It is much easier just to use an SSL server certificate from a Public Certificate Authority  that chains to a root certificate that’s already resident on the device.

Unfortunately, Windows Mobile has no root certificate updating service as included in Windows XP and Windows Vista.  With Windows Mobile, you get the root certifcates that were added when the image was built.

If you are using Windows Mobile 5.0 devices, you should not use GoDaddy or Comodo root certificates for the most part.   Here is a table showing which versions of Windows Mobile includes which Public CA certificates:

Another consideration is the use of wildcard certificates.  As you probably already know if you are reading this, a wildcard certificate allows the use of a wildcarded DNS name prefix such as “*.acme.com”.  You can use the same SSL certificate for many different web servers that all have assigned DNS names that end in “.acme.com”.  It is important for SSL security that the server’s internet DNS name matches the subj or subj alt name on the certificate.  So, if you wildcard th prefix in the certificate, you can use one cert for a lot of servers.

Windows Mobile started supporting wildcard certificates in Windows Mobile 6.0.  If you have Windows Mobile 5.0 devices, you should take a look at the offering from Digicert.  They allow you to pre-populate the subj alt name of the certificate with a list of server names.  This ends up giving you something approaching wildcard certificate features.  However, you do need to know the internet DNS names of all the web servers you’ll be using.  See more details on the Digicert site. Note that digicert is not shown on the list above because they actually chain back to the Entrust root.

Dave Field, CISSP, MCP
Device Management and Security Architect
Enterprise Mobile, Inc.

UPDATED: Oct 5, 2008: Updated v1.1 .ADM file with corrections and additional settings. Download here.

One of the most powerful things about Microsoft System Center Mobile Device Manager (SCMDM) is the ability to manage all of your Windows Mobile 6.1 or above devices through Active Directory (AD) Group Policy Objects (GPOs). A large percentage of the corporate market is already using GPOs to manage their desktop, notebook and server environments.

The GPO technology was introduced in Windows 2000 Server. Before that there were System Policies in Windows NT 4.0. There is already a fair amount of documentation and knowledge around extending GPOs to your own needs. But here I will go into some aspects more important around making use of SCMDM and supporting Windows Mobile in an enterprise running AD.

In this article I will go through how you can extend your own GPOs to have additional settings not available out of the box in the default Windows Mobile GPO template supplied by Microsoft in SCMDM 2008. I will expect that you already know how to access and use the default SCMDM GPO settings.

Windows Mobile Registry Keys

GPOs work by manipulating how registry keys are changed and written on the client machines. This is no different on Windows Mobile, compared to other Windows platforms at this point in time.

I will save the discussion on where to find and research Windows Mobile registry locations. But will point out that many are bound to specific OS levels, OEM and hardware requirements. So what works on one WM device may not work on another. So I can’t stress enough the aspect of testing such settings before a larger deployment to end-users.

For this article I have asked my colleague, Chris De Herrera, to suggest some registry keys to use:

Improve text rendering performance by increasing the GLYPH Cache to 32k (decimal):

[HKEY_LOCAL_MACHINE\System\GDI\GLYPHCACHE]
“limit”=dword:00008000

Internet Explorer Mobile homepage settings:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\AboutURLs]
“home_0409″=”file://\\windows\\default_0409.htm“
“version_0409″=”file://\\windows\\about_0409.htm“
“blank”=”res://webview.dll/blank.htm”

Configure Communicator Mobile:

[HKEY_CURRENT_USER\Software\Microsoft\Communicator\System Settings]
“ServerInternal”=”sip.yourcompany.com”
“Server”=”sip.yourcompany.com:443″

Furthermore I have also researched the following registry keys which may be helpful in corporate environments:

ClearType Activation:

[HKEY_LOCAL_MACHINE\System\GDI\ClearType][HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings]
“ClearTypeText”=dword:1[HKEY_LOCAL_MACHINE\System\GDI\ClearTypeSettings]
“OffOnRotation”=dword:0

Browser History:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
“DaysToKeep”=dword:00001E

Default Search Page:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
“Search Page”=http://m.live.com/search/Results.aspx?q=%&mid=8001

Internet Explorer User Agent:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent]
“Default”=”Mozilla/4.0″
“Platform”=”Windows CE”
“Version”=”MSIE 6.0″

Menu Animations:

[HKEY_LOCAL_MACHINE\SYSTEM\GWE\Menu]
“AniType”=dword:0

Windows Animations:

[HKEY_LOCAL_MACHINE\SYSTEM\GWE]
“Animate”=dword:0

Error Reporting:

[HKEY_LOCAL_MACHINE\System\ErrorReporting\DumpSettings]
“DumpEnabled”=dword:0
[HKEY_LOCAL_MACHINE\System\ErrorReporting\UploadSettings]
“DontUpload”=dword:1[HKEY_LOCAL_MACHINE\System\ErrorReporting\UploadSettings]
“ConnectionFlags”=dword:0

Today Screen Text:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\DeviceBeta]
“Today”=”EnterpriseMobile”

Display Time/Date in Taskbar or disable for battery indicator:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell]
“TBOpt”=dword:3
“ShowTitleBarClock”=dword:1

Permit Bluetooth and IrDA File Transfer:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Obex]
“IsEnabled”=dword:1

Please be aware that most of these settings require a soft reboot of the device before they become effective. The SCMDM policy agent should prompt you for a reboot of the device when an updated policy is synchronized from the Device Management Server.

Creating .ADM Files

Using the information published here about the correct registry key prefix to use for GPOs on Windows Mobile I created my own .ADM file with my sample registry keys listed above and a few other samples currently available.

You can download it here. I have noted in my sample the references used.

Look for a new folder called “Windows Mobile Settings-Extended” in the Computer Configuration section of the Group Policy Object Editor.

 
The single main trick was to prefix the native Windows Mobile registry keys with the <SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry> path.

So the native:
<HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\AboutURLs> became the longer:
<SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\Software\Microsoft\Internet Explorer\AboutURLs>.

Note the collapsed HKEY_LOCAL_MACHINE hive into the named HKLM. This also works for the HKEY_CURRENT_USER hive into HKCU.

Further Information on .ADM Files

Please see the reference links below for more details on the syntax used in the example .ADM file. The syntax and commands are not the easiest in the world of IT.

I also found a ADM file editor, called ADM Template Editor from a small company in Australia that may be useful if you are planning to write and manage a large number of custom .ADM/.ADMX files.

Again, please test the policies on the OS platform, level, and hardware you wish to broadly deploy your Windows Mobile settings out to.

Look for more articles soon on useful Windows Mobile registry keys and GPOs!

References:

• Microsoft articles on writing GPOs:
  • How to Write a Simple .Adm File for Registry-based Group Policy
  • KB225087: Writing Custom ADM Files for System Policy Editor
  • KB816662: Recommendations for managing Group Policy administrative template (.adm) files
• Creating a New Group Policy Object for (Windows Mobile) Devices
• SCMDM Technical Article: Deploying and Configuring Communicator Mobile with MDM
• SCMDM Technical Article: Name Resolution Considerations for Company Web Site Access
• ADM Template Editor: (Recommended, one of the few I believe out there!)

|\\arco..
mnielsen(at)enterprisemobile.com
http://marco.blogsite.org

It is a well know fact that a lot of enteprise IT pros require data encryption for mobile devices.  The Windows Mobile operating system has included support for the Data Protection API (DPAPI) since Windows Mobile 2003.  And DPAPI forms the basis for Windows Mobile file encryption used with removable storage cards (Windows Mobile 6.0) and main memory (Windows Mobile 6.1). 

DPAPI provides easy-to-use functions for encryption and decryption.  A number of applications use DPAPI.  The thing that makes DPAPI easy to use for developers is that they don’t have to wite all the key generation and key management code that typically goes with any encryption solution.  DPAPI uses a master key that is stored in the memory of the device.  When an application calls DPAPI, the same master key is used to generate symmetric keys for all encryption and decryption operations.  In this way, the application does not have to generate or manage the encryption key used.  For a thorough description of DPAPI see the MSDN article covering Windows Data Protection

Of course, this begs the question, “How is the master key protected?” Read the rest of this entry »