Communications

Improve Security with Windows Mobile 6

Matt Fontaine

At a Glance:

• On-device security
• Exchange Server security
• Network security

Mobile devices increase the productivity of workers around the world, giving them access to corporate information and keeping them connected even while they’re away from the

physical office. The productivity increases are real: just turn on the mobile device and get to work.

On the other side of that coin are the IT professionals who are challenged with the difficult task of keeping the virtual office secure and stable. From their perspective, every mobile device is a potential network security leak to be plugged and a potential data theft liability. Building a more secure deployment of mobile devices is crucial, but must also be balanced with providing a seamless and intuitive user experience.

Microsoft® Windows Mobile® 6 and its predecessor, Windows Mobile 5.0 with the Messaging and Security Feature Pack (MSFP), include many features that help you secure corporate infrastructure with minimal difficulty—and with minimal inconvenience for your users. Using Microsoft Exchange Server as the messaging platform further increases the security options available. In this article, I demonstrate how you can use Windows Mobile, Exchange Server, and some network security best practices as a foundation for protecting your company’s mobile devices.

Mobile Communication Architecture

There are three layers to consider when planning or upgrading a mobile deployment: the device, the message server, and the network (see Figure 1). At the device level, key challenges include allowing only authorized access to the device and preventing unauthorized applications on the device. Windows Mobile helps prevent unauthorized access to the device itself through PIN authentification and password protection, device timeout locking, and the ability to "wipe" or erase the device’s memory either locally or remotely if it is lost or stolen. Data encryption of the communication channel and removable storage is supported. Preventing unauthorized applications such as viruses or spyware from being installed or accessing critical parts of the device is also essential. Management role definition, application access tiers, code signing settings, security settings, and security certificates combine to help achieve device-level protection.

Figure 1** Layers of mobile communication **

The next security layer is the messaging server, such as Exchange Server 2003 with Service Pack 2 (SP2) or Exchange Server 2007. This layer includes both message security—the technology by which messages are transmitted securely to and from devices—as well as the interaction between the message server and the mobile device via Exchange ActiveSync®. Exchange Server is not required to use Windows Mobile devices, but using Exchange offers cost, scalability, performance, and administrative advantages.

Good device-level and messaging server security practices are key, but protecting the network layer is also critical. By configuring your corporate network according to best practices and implementing strong security protocols, you can help prevent damage to the network even if one or more mobile devices are compromised.

On-Device Security Policies

The first line of defense against security breaches is the Windows Mobile-powered device itself. The Windows Mobile operating system provides extensive device-level security services supporting authentication, storage card encryption, virtual private networking (VPN), Wi-Fi encryption, and secure sockets layer (SSL) services. Device-level security involves managing who has access to a device and its data, controlling which applications can run on the device, and establishing how data is transmitted to and from the device. In general, administrators have a good deal of flexibility in setting and enforcing security policies on both Windows Mobile 5.0 with MSFP and Windows Mobile 6.

User access is managed through a PIN or password authentication. A device can be set to lock automatically after a period of inactivity or after being turned off, requiring a user to unlock the device again to use it (see Figure 2). The specifics of user access control are set by security policies, which can be changed depending on the administrator’s security role.

Figure 2** Setting password policies **

Security policies define global levels of security for the mobile device (see Figure 3). Who can set and change these security policies is determined by security roles. The Manager role, usually reserved for mobile operators, provides complete control over security policy settings. The Enterprise role is used by Exchange to manage some device policies, which are configured by the Exchange administrator. Depending on your agreement with the device provider, you may be able to customize security policies for your company.

Figure 3 Security policies for mobile devices

Customizable authentication methods used by Windows Mobile are controlled by Local Authentication Plug-Ins (LAPs), which interact with the Local Authentication Subsystem (LASS). This technology allows Exchange Server to control the device configuration at a granular level—for example, by enforcing password length and strength requirements or enabling simple PIN authentication.

Windows Mobile 6 has an expanded set of LAP functions that are configured using Exchange Server 2007. You can enable PIN pattern recognition (for example, denying use of simple patterns such as "1111" or "1234"), configure password or PIN expiration periods, allow users to request a PIN reset based on certain conditions, or keep a PIN/password history to prevent users from re-using old PINs or passwords when they are called upon to create a new one (see Figure 4).

Figure 4** Enforcing PIN and password usage **

Protecting Data on Devices

In the event that an incorrect PIN or password is entered more times than the limit set by the administrator, the local device-wipe feature hard-resets the device, erasing its memory—including user authentication credentials. The limit is set as part of the security policies in Exchange Server. After every two incorrect entries, the device prompts the user to enter a structured key string to continue. This prevents the device from being wiped accidentally because of random key presses. Remotely wiping the storage card is also possible when using Windows Mobile 6 and Exchange Server 2007.

Locking down a device isn’t much good if someone leaves a 2GB storage card filled with sensitive corporate data in a taxi. Fortunately, you can use Windows Mobile 6 to deal with this problem as well. It can encrypt storage card data so that only the device that wrote to the storage card can read it. As with many other enhanced security features of Windows Mobile 6, Exchange Server 2007 can be used to provision this security feature over the air. Storage card encryption is largely transparent to the user. Exchange Server 2007 lets the administrator choose whether users can change their storage card encryption settings.

Whether or not applications can run on a Windows Mobile device is based on three levels of permission: Privileged, Normal, and Blocked. Privileged-level applications (signed by a certificate in the Privileged certificate store) can write to the registry and system files, and can also install certificates. As with a desktop PC or server, the more applications that can alter the operating system environment, the greater the chance of compromising that environment. Reducing the number of applications with Privileged access is generally good practice. Most applications only need to run at Normal level (apps that are either signed by a certificate in the Unpriv certificate store or unsigned applications that the user has agreed to run), which allows them to execute but prevents access to system files. Blocked applications are just that—they are blocked and cannot run due to incorrect signing or user action.

Devices can have either a one-tier or two-tier security access configuration. With a one-tier access configuration, unsigned applications are either run with Privileged access or are blocked and simply cannot run. A two-tier access configuration will run unsigned applications at normal level if policy checks successfully or if the user allows the application to run. Depending on device settings, the user can be prompted as to whether to execute an unsigned application or not.

Digital certificates—one of the most commonly used forms of personal, device, and application authentication—are a crucial piece of Windows Mobile security on the device, server, and network levels. The Windows Mobile operating system stores several types of certificates in different certificate stores on the device. With regard to applications, certificates determine which ones can be installed and run. For an application to run on a Windows Mobile-powered device without the user being prompted, it must be signed with a certificate proving that it was accepted by the Microsoft Mobile2Mobile program. Applications are granted permission levels based on which certificates they have associated with them.

For network authentication, each mobile device comes with a number of trusted commercial root certificates issued by a Certificate Authority (CA) as shown in Figure 5. The messaging server (for example, Exchange Server) verifies the authenticity of a device’s root certificate before establishing an SSL connection with that device. If your company uses custom certificates, you may be able to install them on the Windows Mobile-powered devices you purchase, or you may have to create new certificates. I’ll discuss this further in the Network Security section of this article.

Figure 5** Managing digital certificates **

ActiveSync and Internet Explorer® Mobile can use SSL to help secure data transmission between the device and a corporate Web server. This is true whether the connection exists to synchronize Microsoft Exchange data, configure the device, or download applications. SSL encrypts the communication channel with 128-bit RC4 or 3DES ciphers so data cannot be read by outside parties. Windows Mobile also supports VPN, which uses packet encryption to provide security similar to a dedicated line while accessing a server over the Internet.

Exchange Server Security

While Windows Mobile-powered devices don’t require Exchange Server to function, the two systems have been designed to work closely together and present a robust end-to-end mobile messaging and productivity solution. Since the release of Windows Mobile 5.0 with MSFP, ActiveSync has been enhanced to allow remote management of Windows Mobile device settings. It provides an easy yet powerful means to propagate and enforce global security settings across most Windows Mobile devices.

ActiveSync runs on IIS, the application/Web server component of Microsoft Windows Server 2003. IIS provides built-in security that helps protect ActiveSync itself from attacks arriving through the network. Because Microsoft Office Outlook® Web Access (OWA) is also based on IIS, you can use the same security certificates for both ActiveSync and OWA.

When ActiveSync is used to propagate an Enterprise policy, that policy is delivered to devices the next time they are synchronized with Exchange Server. Users must accept the changes or they are not allowed to connect to the server. Many networks deal with a wide range of devices, including legacy hardware that is unable to accept sophisticated security policies. If necessary, you can exempt certain devices, such as legacy hardware, from the security policy requirement so they can continue to connect.

Exchange Server 2003 SP2 and Exchange Server 2007 have somewhat different security policy control capabilities. Exchange Server 2003 SP2 can be used to specify a minimum password length from 4 to 18 characters, require both numbers and letters in a password, and set how long a period of inactivity is allowed before a device locks. This version of Exchange Server can also set how often security settings are pushed to devices, as well as allow the aforementioned exemptions for legacy devices.

With the release of Exchange Server 2007, the ActiveSync mobile device management capabilities have been enhanced to include all the Exchange Server 2003 SP2 capabilities, plus the following:

• Allow or disallow simple passwords (such as "1234" or "1111")
• Enable or disable attachment downloads
• Require storage card encryption
• Set maximum attachment size
• Enable recovery of a device password by the user via OWA
• Enable access to Universal Naming Convention (UNC) and Microsoft Windows SharePoint® Services (WSS) files

With Exchange Server 2007, IT professionals have the flexibility to tailor policies to each user or device, to manage policies for groups of users, as well as to exempt specific users from security policies altogether.

Remote Access Wipe

In addition to the local device wipe detailed earlier, you can wipe a Windows Mobile powered device remotely using Exchange Server 2003 SP2, Exchange Server 2007, or OWA. Remote wipes, which take place upon synchronization, can be performed even if you’re not using ActiveSync security policies. A remote wipe hard reset cannot be stopped from the device. Data, settings, and security keys are overwritten with repeated zeros, making it extremely difficult to recover any data not part of the core operating system.

Network Security

Network security is just as important to mobile security as the device and messaging server components. It is also the part of the mobile infrastructure that is most clearly in your control. Even if one or more mobile devices happen to get compromised, configuring your corporate network according to best practices and implementing the right security protocols can help prevent damage to the network.

Windows Mobile works well with a variety of network types. Using standard Internet security protocols and firewalls, you can design a solution that suits your needs for performance, stability, and security.

When messaging servers are kept within the corporate network, they can be protected by an edge firewall that acts as a buffer between the Internet and the corporate servers. Microsoft Internet Security and Acceleration (ISA) Server 2004 or ISA Server 2006, both of which have features designed especially for this purpose, inspects all incoming packets to determine their identity before passing them along to the Exchange servers, and then sends outbound information back to the client via the Internet.

Configuring ISA Server requires that you enable SSL encryption and designate port 443 as the SSL Web listening port for Exchange Server traffic. This minimizes exposure to the Internet by limiting it to a single port. Also, all clients should be required to establish an SSL link before connecting via ActiveSync.

ISA Server can pre-authenticate users of Web applications like OWA to help prevent unauthenticated users from reaching the application servers. ISA Server 2006 improves the SSL bridging model of ISA Server 2004 by acting as the SSL termination point for Windows Mobile-powered devices. This allows Windows Mobile-powered devices to authenticate to the Exchange server, without ever making a direct connection with it, instead relying on ISA Server 2006 to pass traffic back and forth. And since the recommended location of ISA Server 2006 is in the perimeter network, this allows an extra layer of security between the public Internet cloud and the Exchange Server front end.

Authentication

There are two basic flavors of authentication from which to choose: basic and certificate-based. Basic refers to a standard name-and-password-enabled, SSL-based connection between a Windows Mobile client and the Exchange front-end server. It still requires a certificate because Exchange Server looks for a matching root certificate on the device before authenticating. Windows Mobile and IIS allow you to use the broad array of encryption methodologies associated with SSL.

Certificate-based authentication, which is available in both Windows Mobile 5.0 with MSFP and Windows Mobile 6, uses Transport Layer Security (TLS) rather than SSL basic authentication. In addition to the root certificate, TLS requires that each user have a certificate with public and private keys. Because TLS uses an encryption key (up to 2,048 bits) instead of a password, this protocol offers stronger authentication.

With Windows Mobile 6, to enroll a user certificate using Desktop Enroll requires that the device be docked with a desktop that is in the same domain as the certificate enrollment server. The user authenticates the enrollment using a password, smart card, or other method, and then connects the device to a desktop PC. The user then accesses the certificate system through the desktop, which, in turn, installs the certificate on the mobile device. Desktop Enroll can serve a variety of Windows Mobile security purposes, including certificate renewal, as well as distribution of ActiveSync authentication certificates, SSL/TLS authentication certificates, 802.1x Wi-Fi certificates or S/MIME digital signing certificates.

Security protocols such as SSL protect message data while in transit, but do not encrypt them once they land on the Windows Mobile device or the Exchange server. S/MIME is a secure form of the familiar MIME e-mail standard that supports digitally signed and/or encrypted e-mail. This provides an additional layer of protection over and above SSL transport layer encryption.

Wrapping Up

It takes attention to each of the many layers that make up a solution to create an infrastructure that is sufficiently secure. Windows Mobile, Exchange Server, and Microsoft network security products like ISA Server work together to allay much of the pain of managing mobile infrastructure. This helps take some of the pressure off IT departments, shifting the focus away from the security challenges created by mobile devices and onto the productivity increases they enable.

Special thanks to Kathy Esser, Katharine Holdsworth, Sarah Norton, and Chip Vollers for their assistance in the creation of this article.

Matt Fontaine is a technology writer for BuzzBee Company.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.