Security for Windows Mobile Messaging in the Enterprise Date: February 2007 Applies to: Windows Mobile 5.0 with MSFP Windows Mobile 6 Exchange Server 2003 SP2 Exchange Server 2007 The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2007 Microsoft Corporation. All rights reserved. Microsoft, ActiveSync, Outlook, SharePoint, Windows, Windows Mobile are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Table of Contents Introduction ............................................................................................................................. 1 Naming Conventions .......................................................................................................... 1 In This Document ............................................................................................................... 2 Other Resources ................................................................................................................ 2 Security Risks in the Mobile Enterprise ................................................................................... 3 The Windows Mobile Security Architecture ............................................................................. 4 Security on the Device ............................................................................................................ 7 Permissions........................................................................................................................ 7 Security Configuration ........................................................................................................ 7 Security Roles .................................................................................................................... 8 Security Policies ................................................................................................................. 8 Certificates and Authentication ........................................................................................... 9 Certificate Stores ......................................................................................................... 10 Installing Certificates on a Windows Mobile 6 Powered Device .................................. 11 Security Services ............................................................................................................. 12 Security Settings and Exchange Server Active Sync ....................................................... 14 Device Wipe ................................................................................................................ 14 Lock a Device .............................................................................................................. 15 Authentication with LAS and LAP ................................................................................ 15 Security on the Exchange Server .......................................................................................... 19 Exchange Server and Exchange ActiveSync ................................................................... 19 Internet Information Services ....................................................................................... 19 Device Management Using Exchange Server .................................................................. 19 Exchange ActiveSync Administration Tools ................................................................ 20 Security Policies on Windows Mobile Devices Managed by Exchange Server ................ 20 Setting Device Security or Mailbox Policies from Exchange Server ............................ 21 Local and Remote Device Wipe .................................................................................. 25 Security within the Corporate Network .................................................................................. 27 Network Configuration ...................................................................................................... 27 ISA Server ................................................................................................................... 28 Data Encryption with SSL................................................................................................. 28 Using Firewalls: Exchange Server Minimizes the Need for Open Ports ...................... 29 Direct Push Firewall Timeouts and DoS threats to the Corporate Network ................. 29 Authentication for Mobile Devices on the Corporate Network .......................................... 30 Basic Authentication on the Exchange Server ............................................................. 31 Certificate-based Authentication .................................................................................. 31 Managing Device Certificates........................................................................................... 32 Adding Certificates to Windows Mobile 5.0-based Devices ......................................... 32 Adding Certificates to Windows Mobile 6 Powered Devices ........................................ 32 Increasing E-Mail Security................................................................................................ 33 Support for Information Rights Management ............................................................... 34 Using S/MIME with Windows Mobile Powered Devices .............................................. 34 Conclusion ............................................................................................................................ 35 Security for Windows Mobile Messaging in the Enterprise Introduction One of the most difficult tasks facing enterprise network administrators is finding methods and technologies that can help prevent malicious attacks on their systems from sources located both inside and outside the corporate firewall. Securing servers, client computers, and mobile devices becomes even more vital as workers and contractors connect from multiple wired and wireless networks that may employ varying levels of security. Employees can inadvertently put their businesses at risk by connecting to mission-critical systems over mobile networks and applications and unintentionally transmitting viruses or corrupt data. In addition, passing critical corporate data through an outside network operations center may increase the risk of compromise or unavailability. With the right technologies and network architecture in place, however, network administrators can dramatically improve the security and management of mobile device connections. The key to a successful deployment is carefully planning how to handle permissions and security rights for these mobile workers. Microsoft® products offer a broad set of security technologies to help you construct a sound defense against information security threats. This paper describes the security technologies available to protect Internet e-mail and wireless communications for devices running on Microsoft Windows Mobile™ 5.0 software with the Messaging and Security Feature Pack (MSFP), and on Windows Mobile 6. Windows Mobile-based devices integrate with existing Windows networks and conform to existing network security policies by using many of the same Microsoft security features found in Windows desktop and laptop computers. The technologies described in this paper apply generally to devices running Windows Mobile 5.0 with MSFP and later software. Understand, however, that actual on-device support for these security technologies may vary, depending on the mobile device in use and how it has been configured by the original equipment manufacturer (OEM) and mobile operator. Readers should be familiar with Windows networking technology for enterprise deployments and with Microsoft certificate technology and they should have an understanding of mobile devices. Naming Conventions This document supports both Windows Mobile 5.0 and Windows Mobile 6. With the introduction of Windows Mobile 6, Microsoft changed its naming conventions to better align the brand and products with the realities of today’s mobile device marketplace. The historical form-factor based distinction between Windows Mobile powered Smartphone and Windows Mobile powered Pocket PC Phone is blurring dramatically, and the terminology has been changed to better reflect the evolution of the industry. The following table summarizes the changes. Windows Mobile 5.0 and earlier Windows Mobile 6 Windows Mobile for Pocket PC Windows Mobile 6 Classic Windows Mobile for Pocket PC Phone Edition Windows Mobile 6 Professional Windows Mobile for Smartphone Windows Mobile 6 Standard 1 Security for Windows Mobile Messaging in the Enterprise In This Document This paper covers the three main components of the Windows Mobile Security architecture: Security on the Device describing the code and features resident on a Windows Mobile device Security on the Exchange Server providing details about the ActiveSync protocol and the security policies that can be managed from Exchange Server Security on the Network outlining the features of a secure mobile messaging network, including ISA Server, Internet Information Services server, and protocols for data encryption and device authentication This document supports the IT Professional in a large enterprise corporation who has the resources and the mission to deploy a highly secure, controlled mobile messaging solution in his or her existing corporate network configuration. In this scenario, the IT Professional deals with both front door and back door devices. The front door devices are new devices that will likely be purchased in large quantities directly from an OEM or Mobile Operator. In this case, the IT Professional will be in a position to request specific features and work with the device provider to create a unique device configuration that meets corporate requirements. The back door devices are ones that are brought into the corporate environment by individuals or groups who have procured the devices from a retailer or have additional requirements that prevent them from using the front door devices. The challenge for the IT Professional is to control both front door and back door devices within the same secure solution. This document provides the IT Professional with technical information needed to understand the Windows Mobile Security model from both the device and the server perspectives. With this data, he or she will know what security levels and features are available on front door and back door Windows Mobile powered devices and how Exchange ActiveSync interacts with each of them. Large corporations choose to direct the ongoing device configuration, called provisioning, that can alter the security level and other features on an already functioning device. The companion white paper, Security Model for Windows Mobile 5.0 and Windows Mobile 6 provides deeper technical information to use as a resource for provisioning and managing Windows Mobile powered devices. IT Professionals can achieve a high degree of security and device management by using devices running Windows Mobile 5.0 with MSFP and later software with Exchange Server’s ActiveSync management protocols in Exchange Server 2003 SP2 or Exchange Server 2007 which can be deployed without special configuration. Other Resources Security Model for Windows Mobile 5.0 and Windows Mobile 6 http://www.microsoft.com/technet/solutionaccelerators/mobile/default.mspx Security for Windows Mobile Messaging in the Enterprise Security Risks in the Mobile Enterprise Windows Mobile devices and software offer many benefits to the enterprise, including lower operating costs and greater productivity. However, organizations that deploy mobile enterprise solutions need to make security a priority. The following illustration shows the variety of security threats to a corporate network that supports mobile devices. Device loss or theft. Losing a device to mishap or theft can cause lost productivity, data loss, and potential liability under data-protection laws. Thousands of mobile phones and networked handheld devices are lost or stolen every year. As sales of mobile devices increase, the negative effects of device loss and theft are sure to increase accordingly. Loss of sensitive data. Some organizations consider mobile devices a security risk only if they have a business application installed. Other organizations consider the loss of calendar and contact information a security risk. Consider the potential consequences if an executive’s e-mail inbox or calendar, full of meetings and briefings, were retrieved by a competitor. Contact information can also cause problems if it falls into the wrong hands, as recent highprofile incidents have demonstrated. Organizations need to protect all data on their employees’ mobile devices. Unauthorized network penetration. Because many mobile devices provide a variety of network connectivity options, they could potentially be used to attack protected corporate systems. Attackers who gain access to a mobile device may be able to impersonate a legitimate user and gain access to the corporate network. Unauthorized Bluetooth or Wi-Fi access. Many mobile phone users employ hands-free Bluetooth headsets, potentially leaving hackers a hole for BlueSnarfing data on the device or BlueBugging to gain control of the device. Ad hoc wireless network connection can also lead to unauthorized device access. Intercepted or corrupted data. With so many business transactions taking place over mobile devices, there is always concern that critical data could be intercepted along the path through the Internet cloud, via tapped phone lines or intercepted microwave transmissions. 3 Security for Windows Mobile Messaging in the Enterprise Malicious software. Viruses, Trojan horses, and worms are familiar threats to traditional workstations and laptops. While mobile devices have not yet become a significant target, there is a growing consensus among security experts that mobile devices will be targeted. Even malicious software not designed to deliberately inflict damage may have unintended consequences such as data disclosure or corruption. Unsupported or unsigned applications. Older applications that are no longer supported, while they may still work, are dangerous because they may be vulnerable to attack by new viruses. If an unsigned application is installed on a device, it could make changes to a device that would jeopardize its security. Unauthorized device connectivity. An employee connecting a personal device to the Exchange Active Sync may bypass security settings and applications required on a corporate device. The Windows Mobile Security Architecture The Windows Mobile security architecture protects corporate data and communications while utilizing the enterprise's existing infrastructure investment. This architecture puts organizations in control of their own security and data. Unlike competing solutions, corporate data are not required to go through a third-party network operations center, which has associated risks of downtime and information compromise. In addition, Windows Mobile devices can communicate with enterprise communication services using industry-standard protocols that run on virtually all mobile operator networks, eliminating geographical restrictions on service availability. The following figure shows a high-level view of the Windows Mobile security architecture, including Windows Mobile-powered devices, Exchange Server, and existing corporate network components. The Windows Mobile security architecture offers the following features to help protect devices and the enterprise network against a variety of threats and risks: Threat or Risk Microsoft Security Features WM 5.0 WM 5.0 with MSFP WM 6 Access to data because of device theft or loss Strong device password protection X X X Device lock requires a password or PIN to access the device when it is turned on X X X X X Local device wipe occurs after a specified Security for Windows Mobile Messaging in the Enterprise number of incorrect login attempts Remote device wipe erases data and prevents unauthorized use Exponential back-off if incorrect passwords are entered X X X X Local storage card wipe erases data and prevents unauthorized use X Remote storage card wipe erases data and prevents unauthorized use X Storage card encryption prevents unauthorized use X Custom Local Authentication Subsystem (LAS) and Local Authentication Plug-in (LAP) provide the infrastructure for authentication by sophisticated third-party hardware and software methods. X Password policy enforcement, such as required password for synchronization Access to data during transmission X Secure Sockets Layer (SSL) encryption of all data transmitted between the device and the corporate mail server X X X X X X X Advanced Encryption Standard for SSL channel encryption in 128- and 256-bit cipher strengths. Encrypted data passes through a single SSL port on the firewall X X X Supports Information Rights Management protection of e-mail. Cryptographic implementations certified by US Federal Information Processing Standard (FIPS) 140-2, and are protected against a variety of potential threats. Supported algorithms include: Unauthorized penetration into corporate network Advanced Encryption Standard (AES) DES and 3DES, Secure Hash Algorithm (SHA-1), RSA public-key encryption and decryption. Flexible client authentication: SSL TLS, Exchange ActiveSync, Certificate-based, RSA SecurID-protected Users can add root certificates without compromising device management security and without being a manager of the device 5 X X X X X X X X X Security for Windows Mobile Messaging in the Enterprise Unauthorized penetration into mobile device Security policies control over-the-air access to device Device corruption Security policies control acceptance of unsigned attachments, applications, or files X X Bluetooth discovery mode can be prohibited to guard device integrity (Supported by Windows Mobile 6 Standard only) Two-tier access for code execution control — executable runs if it is signed; permissions indicate access. (Supported by Windows Mobile-based Smartphone and Windows Mobile 6 Standard only) One-tier access for code execution control — executable runs if it is signed. X X X Attachments for download can be denied or size-restricted Malicious software or viruses on mobile devices X X X Office Mobile applications do not support macros, so viruses cannot leverage them to do damage X X X Code execution control allows the device to be locked so that only applications signed with a trusted certificate can run X X X Security for Windows Mobile Messaging in the Enterprise Security on the Device Windows Mobile-powered devices offer built-in support of security services including authentication, message encryption, virtual private networking (VPN), and SSL. The security model on the device uses a combination of security policies, security roles, and certificates to address device configuration, remote access, and application execution. Security policies are used to configure security settings on the device. The policies are then enforced through roles and certificates. You can achieve many levels of defense using security-through-identity and security policies. Although initial security policies are configured and provisioned by the OEM and Mobile Operator, the system administrator can manage some of them through Exchange Server ActiveSync. These security concepts are described in this section: Permissions Security Configuration Security Policies Certificates and Authentication Security Services Security Settings and Exchange Server ActiveSync For details on changing security settings through Exchange Server, see Security on the Exchange Server. Permissions Application execution is based on permissions. Windows Mobile-powered devices have a twotiered permission model, or applications can be blocked: Privileged Applications running at the privileged level have the highest permissions; they can they can call any API, write to protected areas of the registry, and have full access to system files, for example. Few applications need to run in privileged mode. Privileged applications can threaten the integrity of the device by changing the operating system environment. Normal Most applications should run in normal mode; they cannot call trusted APIs or write to protected areas of the registry. System files are read only. Blocked Blocked applications do not run because they are not allowed to execute. An application could be blocked because it is not signed by an appropriate certificate, because the user blocks it after being prompted, and so forth. Security Configuration The security policy of a particular device determines how the device handles application signatures and permissions. The first part of the security policy is known as access tiers; devices can have one-tier or two-tier access. One-tier access — A device with one-tier access focuses only on how an application should run based on whether the application is signed with a certificate in the device certificate store; there is no concern with permission restriction. All Windows Mobile powered devices can be configured to support one-tier access. 7 Security for Windows Mobile Messaging in the Enterprise Two-tier access — A device with two-tier access restricts application start and run-time permissions. Applications signed with a certificate that the device recognizes execute with no further checks. Unsigned applications require further policy checks to determine if they can run; if allowed to run, they run with normal permissions. Windows Mobile Version 5.0 Smartphone and Windows Mobile 6 Standard can be configured with two-tier access. This one-tier and two-tier access model works with the next two parts of the security policy: Whether unsigned applications can execute. Whether the user should be prompted before an unsigned application executes. For a deeper discussion of security configuration, see Security Model for Windows Mobile 5.0 and Windows Mobile 6. Security Roles Security roles allow or restrict access to device resources. For example, roles are used to determine whether a remote message is accepted, and if it is, what level of access it is allowed. The Manager role allows complete control over the device. The Enterprise role allows IT administrators to manage specific device settings, such as wiping a device, setting password requirements, and managing certificates. The User role allows the device owner to query device information, manage files and directories, and change settings such as the home screen and sounds. In Windows Mobile 6, the owner can also manage user certificates and designated certificate stores. For a deeper discussion of security roles, see Security Model for Windows Mobile 5.0 and Windows Mobile 6. Security Policies Security policy settings on Windows Mobile powered devices can be configured to define levels of security. For example, policies determine whether to accept unsigned messages, applications, or files. Security policy settings provide flexible control over the level of software security. These policies are defined globally and enforced locally in their respective components at critical points across the device architecture. By default, only someone with Manager role permissions on the device can change most of the security policies. Using Exchange ActiveSync, network administrators have the Enterprise role and can change the policies listed below. Additionally, a network administrator who is granted Manager role permissions by the OEM or Mobile Operator can change security policies on the device by provisioning it. Provisioning is updating the device after manufacture; this may or may not include bootstrapping a device. Provisioning a device involves creating a provisioning XML file that contains configuration information, and then sending the file to the device. Configuration Service Providers then configure the device based on the contents of the XML file. For example, to take advantage of the Bluetooth security policy to limit bonding or beaming with unknown outside Bluetooth devices, you can either ask your OEM or Mobile Operator to configure the policy on your front door devices or you can provision them by using the Bluetooth Configuration Service Provider. For more information about the provisioning process and the security policies that can be changed by provisioning, see Security Model for Windows Mobile 5.0 and Windows Mobile 6. The following table shows how the network administrator can protect the device by setting security policies using Exchange Server. Security roles define who can change each policy; the default role is listed. Security for Windows Mobile Messaging in the Enterprise Protection Microsoft Security Policy Block unauthorized penetration into device Applies to Windows Mobile 5.0 with MSFP If the device has a password, specify that the user must unlock it before information is synchronized to the desktop. Or, allow the user to authorize synchronization on the desktop. (4133) In Windows Mobile 6, this policy is deprecated; use 4146 instead. Default role: Manager, Enterprise Applies to Windows Mobile 6: Allow or deny the user permission to change mobile encryption settings for removable storage media. (4134) Default Role: Manager, Enterprise Specify whether or not the user must authenticate on the device when connected if device lock is active (4146) Default role: Manager, Enterprise Protect sensitive data in case of device theft or loss Applies to Windows Mobile 5.0 with MSFP and later Specify whether a password must be configured on the device. (4131). Default role: Manager, Enterprise For a complete list of features that can be changed with Exchange ActiveSync and information about how to change the policy settings, see Security on the Exchange Server. Certificates and Authentication Digital certificates play a critical role in device security and network authentication. Certificates are electronic credentials that bind the identity of the certificate owner or the device to a public and private pair of electronic keys used to encrypt and digitally sign information. Signed digital certificates assure that the keys actually belong to the specified application, device, organization, or person and that they can be trusted. Digital certificates are used on Windows Mobile devices in two essential roles: In code signing, determining whether an application can be run on the device and if so, the permissions (privileged or normal) with which it will run. In authentication, presenting trusted credentials for connecting to a corporate Exchange email server or network or verifying the identity of a remote server. For example, in order for an application to be installed and run on the device, the application must present a digital certificate that proves it was accepted and signed by a trusted source, such as the Mobile2Market program. In an authentication example, before an SSL connection can be established with the network server, the mobile device must present a certificate from its root store that is recognized and accepted by the server. Mobile2Market is the Microsoft certification and marketing program for mobile applications for independent software and hardware vendors. This program, in conjunction with privileged certificate authorities, allows application developers to distribute their applications across the vast majority of Windows Mobile-powered devices while working with a single certificate authority and maintaining just one signed version of their application. 9 Security for Windows Mobile Messaging in the Enterprise Certificates shipped on Windows Mobile Powered Devices By default, Windows Mobile-powered devices are shipped with a variety of certificates: Trusted root certificates from major certificate vendors that can be used for authentication purposes. Mobile2Market and other trusted certificates that designate applications that are signed for use on Windows Mobile devices. Additional certificates that may be added by the OEM or network carrier. For a list of certificates currently shipping with Windows Mobile powered devices, see Certificates for Windows Mobile 5.0 and Windows Mobile 6. Certificate Stores The certificates in a Windows Mobile device are located in the certificate stores in the registry. The certificate Root and Certificate Authentication (CA) stores on Windows Mobile 5.0 devices are locked to everyone except those with Manager role permissions to ensure the integrity of the digital certificates. In Windows Mobile 6, the certificate stores have been expanded with separate User Root and CA stores to allow device users with the less-powerful User role permissions to add or to enroll for trusted digital certificates. The system Root and CA stores remain locked without Manager or Enterprise role permissions. Security for Windows Mobile Messaging in the Enterprise The following table shows the certificate stores and their uses and permissions. Certificate store Physical Store Description Privileged Execution Trust Authorities HKLM Contains trusted certificates. Applications signed with a certificate from this store will run with privileged trust level (Trusted). Unprivileged Execution Trust Authorities HKLM Contains normal certificates. On a one-tier device, an application signed with a certificate in this store will run with privileged trust level (Privileged). On a twotier device, applications signed with a certificate from this store will run with normal level (Normal). SPC HKLM Contains Software Publishing Certificates (SPC) used for signing .cab or .cpf files and assigning the correct role mask to the file installation. Root (system) HKLM Contains root certificates, which can be certificates signed by Microsoft, the OEM, or the Mobile Operator. These certificates are used for SSL server authentication. They cannot be changed without Manager role permissions. Users with Manager role can add certificates in this store. Root (user) HKCU Applies to Windows Mobile 6: Contains root certificates that can be installed by someone with User role permissions. CA (system) HKLM Contains certificates from intermediary certification authorities. They are used for building certificate chains. Users with Manager role can add certificates to this store. Applies to Windows Mobile 6: Certificates are added to this store by Microsoft, the OEM, or the Mobile Operator. CA (user) HKCU Applies to Windows Mobile 6: Contains certificates, including those from intermediary certification authorities, which can be installed by the device user with User role permissions. They are used for building certificate chains. MY HKCU Contains end-user personal certificates used for certificate authentication or S/MIME. Installing Certificates on a Windows Mobile 6 Powered Device In Windows Mobile 6, the Enterprise IT Professional can create a CAB file with a certificate appropriate for use within the corporation. The User role allows the user to use this CAB file to add the certificate to the user Root and CA stores on the device. The certificate installer on Windows Mobile 6 devices will install certificates delivered in the following file formats: 11 Security for Windows Mobile Messaging in the Enterprise PFX/.P12 – Public-Key Cryptography Standards #12 (PKCS #12) format files that include personal certificates with private keys as well as certificates that install into the intermediate and root certificate stores. CER – Base64-encoded or DER-encoded X.509 certificates that install into the intermediate and root certificate stores. P7B - Public-Key Cryptography Standards #7 (PKCS #7) format files that install multiple certificates to any certificate store on the device. The files can be delivered to the device by using desktop ActiveSync, removable storage card, email attachment, or Mobile Internet Explorer file download. Windows Mobile 6 Professional devices also allow download from a file share. When the file is opened from the file explorer, the certificate installer processes and installs the file automatically. For more information on adding certificates to mobile devices, see Managing Device Certificates in Security within the Corporate Network. Security Services Windows Mobile implements the following security services as part of the core operating system. Service Description Cryptographic services Cryptography helps provide privacy and authentication. Windows Mobile offers the following cryptographic services: Encryption, to help provide privacy and authentication between two communicating parties that have exchanged a shared secret. Hashing, to help ensure data integrity of information sent over a nonsecure channel such as the Internet and to help protect user credentials on the device. For example, with Basic Authentication, the user credentials are hashed while stored on the device. Digital Signature, to help authenticate another party, or information sent by that party, without prior exchange of a shared secret. Cryptographic algorithms are used to provide these services. The algorithm implementation is certified as compliant with the US Federal Information Processing Standard (FIPS) 140-2, level 1. This certification asserts that the Windows Mobile cryptographic implementations work properly and that they are secure against a variety of potential threats. Supported algorithms include the US Government standard Advanced Encryption Standard (AES) in 128-, 192- and 256-bit key lengths, single and triple DES, the Secure Hash Algorithm (SHA-1), and RSA public-key encryption and decryption. For more information about FIPS, see Cryptographic Services and FIPS Compliance in Windows Mobile 5.0 and Windows Mobile 6. Authentication services Authentication services can be used by application developers to authenticate clients. Services include security services or client certificates for user authentication, credential management, and message protection: Security services for user authentication. Credential management. Message protection through a programming interface called Security Support Provider Interface. Windows Mobile provides integrated support for remote access networking and authentication, including Windows NT® LAN Manager Challenge/Response protocol version 2 (NTLMv2), SSL 3.1, Private Security for Windows Mobile Messaging in the Enterprise Communications Technology (PCT), Point-to-Point Protocol (PPP), and the Wireless Transport Layer Security (WTLS) class 2 for accessing secure Wireless Access Protocol (WAP) sites. For more information, see Device Protection through Authentication. Virtual private networking support Built-in support for virtual private networking, using Layer Two Tunneling Protocol with Internet Protocol Security (IPSec) encryption (LT2P/IPSec) or Point-to-Point Tunneling Protocol (PPTP) in combination with strong passwords using the Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2). Third-party VPNs may be installed. For more detailed information about VPNs, PPTP, or IPSec/L2TP, see this Microsoft Web site. http://go.microsoft.com/fwlink/?LinkID=82573&clcid=0x409. Wi-Fi encryption Support for the Wireless Protected Access (WPA and WPA2) and Wireless Network Encryption Types Wired Equivalent Privacy (WEP) encryption standards for use with 802.11a/b/g wireless LANs. Following are some of the product compatibility standards for wireless local area networks (WLAN) based on the IEEE 802.11 specifications: WEP provides data confidentiality services by encrypting data sent between wireless nodes. WPA provides enhanced security for wireless networks and is based on a subset of the IEEE 802.11i standard. Applies to Windows Mobile 6: Storage card encryption WPA2 provides a stronger encryption mechanism through Advanced Encryption Standard (AES) with key sizes of 128 and 256 bits. Applies to Windows Mobile 6: Support for encryption of data stored in removable storage cards. Storage card encryption supports Advanced Encryption Standard (AES) in 128 bit cipher strength. The following list shows the storage card encryption support: Encrypt data written from the mobile device to removable media. The data will be encrypted for use on the encrypting device only. If unencrypted data is transferred to the storage card by another device (Phone, PC), the content is not encrypted by the device. ActiveSync file explorer provides desktop access to encrypted data files. Enable over-the-air (OTA) provisioning of encryption by using Exchange or other OTA device management solution. OEMs and Mobile Operators can provision the encryption policy during a cold boot of the device. Encryption is transparent to applications and users, not including performance impacts. Storage card encryption can be managed by Exchange 2007 policies. The user can also manage the mobile encryption configuration through the control panel. Secure Sockets Layer (SSL) support Internet Information Services (IIS) and Internet Explorer Mobile implement SSL to help secure data transmission when a user connects to a server to synchronize Microsoft Exchange data, configure the Windows Mobile- 13 Security for Windows Mobile Messaging in the Enterprise powered device, or download applications. The SSL protocol allows Web servers and Web clients to communicate more securely through the use of encryption. When SSL is not used, data sent between the client and server is open to packet sniffing by anyone with physical access to the network. To authenticate using SSL, Basic or Microsoft Windows NT LAN Manager (NTLM) authentication is used. If it is necessary to support Basic authentication, for instance for Web browsers that do not support NTLM, it is recommended that SSL be used as well so that the user's password is not sent in plain text. For information about configuring a web server to use SSL, see the Step-byStep Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2 at http://go.microsoft.com/fwlink/?LinkId=81200 For information about using SSL in a network configuration, see Security within the Corporate Network. Applies to Windows Mobile 6: Advanced Encryption Standard (AES) AES is now available for SSL channel encryption. AES is the encryption standard for the U.S. Federal Government and NSA, the National Security Agency. Note At present, AES cannot be used with Exchange ActiveSync (EAS) because EAS is built on IIS which does not currently support AES. AES is available for SSL channel encryption in 128 and 256 bit cipher strengths. NSA has approved 128, 192 and 256 bit AES ciphers as sufficient to protect classified information up to the SECRET level. TOP SECRET information requires use of either 192 or 256 bit AES ciphers. With AES encryption, Windows Mobile 6 offers the same level of security approved by NSA for TOP SECRET information, the highest level of security the U.S. government requires. Windows Mobile exposes these security services so that applications can make use of them; for example, the built-in Outlook Mobile client can use SSL (and, by extension, various cryptographic algorithms) for POP and IMAP accounts. Security Settings and Exchange Server Active Sync In addition to security policies that can be changed in Exchange Server ActiveSync, system administrators can change several other security settings. For information about how to set these settings on the Exchange Server, see Security on the Exchange Server. Device Wipe Wiping the device locally or remotely has the effect of performing a factory or “hard” reset; all programs, data, and user-specific settings are removed from the device. The Windows Mobile device wipe implementation wipes all data, settings, and private key material on the device by overwriting the device memory with a fixed bit pattern, greatly increasing the difficulty of recovering data from a wiped device. Note Device wipe in Windows Mobile 6 powered devices includes wiping the removable storage card. Security for Windows Mobile Messaging in the Enterprise Local device wipes are triggered on a device with device lock enforced if a user incorrectly enters a PIN more than a specified number of times (the policy default is 8 times, but the administrator can adjust this value). After every two missed attempts, the device displays a confirmation prompt that requires the user to type a confirmation string (usually “A1B2C3”) to continue. This prevents the device from being wiped by accidental key presses. Once the PIN retry limit is reached, the device immediately wipes itself, erasing all local data. Local device wipe is accomplished by using both the Password Required Policy (4131) and the DeviceWipeThreshold registry key. The registry key value indicates the number of times an incorrect password can be entered before the device's memory is securely erased. Note Microsoft recommends that you also use the Desktop Unlock Policy (4133) to enforce authentication from the device. If authentication is not forced from the device and the user instead authenticates from the desktop, any password attempts made from the desktop will not count against the number of incorrect attempts that will cause the device to be wiped. Remote wipes occur when the administrator issues an explicit wipe command through the Exchange ActiveSync management interface. For more information about local and remote device wipe and the Exchange Server, see Security on the Exchange Server. Lock a Device Applies to Windows Mobile 6 Device Lock is the interaction of the following features: Enhanced PIN Strength Password and PIN Expiration Sequences and Patterns in Passwords and PINs Password History Locking a device after a period of inactivity is accomplished by a registry key setting. Note The user can later decrease an established setting. For example, if the system administrator sets the inactivity time to 15 minutes, the user can decrease this time out to less time by using the device lock control panel. Authentication with LAS and LAP Local Authentication Subsystem (LASS) allows flexible integration of Local Authentication Plugins (LAPs). LASS provides the infrastructure for authentication by sophisticated third-party hardware and software methods, including biometrics, Smartcard use, a hardware button combination, or user signature. LASS can also be used to specify event-based policies to authenticate users. For example, device lock can be triggered programmatically, not just when a device is turned on. A LAP is an authentication mechanism that plugs into LASS. Windows Mobile 5.0 and later contains a built-in password LAP. OEMs and ISVs can build custom pluggable authentication modules. The Microsoft LAP provides two types of password enforcement that can be configured with policies on the server: a minimum password length, and either a strong alphanumeric password or simple PIN. Note If a third-party solution is added to the Device Unlock behavior, the behavior of the device may change for the end user and it may be a less secure solution. If possible, 15 Security for Windows Mobile Messaging in the Enterprise OEMs and Mobile Operators should ask third-party vendors and Enterprise Administrators whether they prefer authentication on the desktop or on the device. Applies to Windows Mobile 6: The following table describes the additional LAP functionality in Windows Mobile 6. Security feature Description Enhanced PIN Strength Enhanced PIN Strength in Windows Mobile 6 uses Microsoft LDAP, which can be configured to prevents users from choosing a PIN that contains a simple pattern or has too few digits. The feature will: Enable a policy that requires end users to choose a PIN that does not contain a repeating sequence, such as 1111. Enable a policy that requires end users to choose a PIN that does not contain a sequence with a predictable difference between values, such as 1234 or 1357. Provide a mechanism for IT administrators to configure policies via a third-party device-management solution. Requires Microsoft Exchange Server Version 12.0. Password/PIN Expiration Password/PIN expiration permits setting the expiration time of a password or PIN on a device using the Microsoft Default LAP. The new feature will: Provide a policy that requires end users to choose a new password or PIN after a configured time period (in seconds). Provide a mechanism for IT administrators to configure policies via a third-party device-management solution. Requires Microsoft Exchange Server Version 12.0. User PIN Reset User password/PIN on a device using the Microsoft Default LAP can be reset using an Authentication Reset Component (ARC). Unlike the other features, the use of the ARC with a custom LAP is supported. The ARC is a pluggable component and an OEM may create an ARC for use with a custom LAP or the default LAP. The feature will: Provide the ability for the end user to request a reset from their administrator or by using Outlook Web Access. Support infrastructures that use certificate authentication or rely on credentials to authenticate a user to the system. Support OEM customization of the LAP. Support OEM replacement of the ARC. Requires Microsoft Exchange Server Version 12.0. When a user runs setup the first time, the recovery PIN is created on the device and transmitted to the Exchange server where it is stored. The recovery PIN is used to encrypt the Master Key. 1. The following steps show the recovery process: The user creates a new PIN to unlock the device. 2. When creating the new PIN, any PIN history and strength policies are applied. The device lock policies are applied to the new password before the user is allowed to continue with the User PIN Security for Windows Mobile Messaging in the Enterprise Reset process. 3. The user obtains the recovery PIN through Outlook Web Access or by calling a Helpdesk. 4. The user enters the recovery PIN and then enters the new PIN created in the first step of this process to unlock the device. 5. The recovery PIN is considered compromised so it is discarded following the User PIN Reset process and setup must be run again on the device to create a new recovery PIN. Password History Password History uses the Microsoft Default LAP to maintain password history and securely store passwords on the device to prevent reuse of a password. The feature will: Enable a policy that requires end users to choose a new password or PIN that is different from a previous password. Provide data about the number of stored passwords to the end user if the new password matches a previous password. Provide a mechanism for IT administrators to configure policies via a third-party device-management solution. Requires Microsoft Exchange Server Version 12.0. 17 Security for Windows Mobile Messaging in the Enterprise This page left intentionally blank Security for Windows Mobile Messaging in the Enterprise Security on the Exchange Server Exchange Server provides enterprise-grade e-mail, calendaring, and related services. It also includes built-in support for over-the-air synchronization of e-mail, calendar, contact, task, and security policy data through Exchange ActiveSync. Exchange ActiveSync works directly with the Windows Mobile operating system so you can avoid the added cost of middleware or service fees. Exchange ActiveSync also offers a highly scalable platform for mobility, allowing you to enjoy the productivity benefits of mobile messaging. Exchange Server and Exchange ActiveSync Exchange ActiveSync is built on the HTTPS and WBXML standards; it is a component in Exchange Server 2003 and Exchange Server 2007, and is enabled out of the box on all user mailboxes without any additional software or servers. Because Exchange ActiveSync uses standard transport protocols, you don’t need to buy special data plans from your mobile operators; you can use standard data plans for global mobile access. If your organization currently exposes Outlook Web Access (OWA), you already have the infrastructure in place to support a mobile deployment using high-grade, 128-bit SSL encryption. Because Exchange ActiveSync is implemented as an application that runs on Internet Information Services (IIS), it can be secured using the same certificates you’re already using for OWA, which saves you time and money. Exchange Server 2003 SP2 and Windows Mobile 5.0 devices with MSFP or later enable the use of direct push technology. Using direct push, mobile clients retain an open connection over an encrypted channel to the Exchange server. As data is updated on the Exchange server, it can be sent directly to the device. Direct push provides a push e-mail experience, without the need for third-party server, software, or networks. When you install Exchange Server 2003 SP2 or higher on an Exchange server, direct push is automatically enabled. The direct push algorithm dynamically adjusts its connection time to maximize battery life and minimize bandwidth usage. Administrators can adjust the timeout on their firewalls to help influence the adjustment process according to the type of devices in use and the volume of arriving messages. For more information about the direct push technology, see Mobile Operator Guide to Messaging and Security Feature Pack for Windows Mobile 5.0-based Devices available at the following Microsoft Web site: http://www.microsoft.com/technet/solutionaccelerators/mobile/default.mspx. Internet Information Services Internet Information Services is the Web and application server component of Microsoft’s infrastructure system. IIS 6.0, the version included with Windows Server 2003, is a mature and very widely deployed Web server that incorporates a number of protective security features. For example, the HTTP service listener is integrated into the Windows kernel so that it cannot be compromised by user-mode extensions and applications. In addition, IIS works in conjunction with the Windows TCP/IP stack to protect applications it hosts against several kinds of TCP denial-of-service attacks. Exchange ActiveSync is actually implemented on top of IIS and used to gain access to Exchange data items. As a result of building Exchange ActiveSync on top of this widely deployed, proven web server Exchange ActiveSync leverages the platform security features to help protect against network-borne attacks. Device Management Using Exchange Server With Exchange Server, an IT Professional has built-in device management capabilities which can allow mobile devices to adhere to the organization's security policies. This native device 19 Security for Windows Mobile Messaging in the Enterprise management support helps create lower costs because you do not need to manage separate servers. Exchange ActiveSync Administration Tools In Exchange 2003 SP2, the Exchange ActiveSync Mobile Administrative Web tool was provided as a download, enabling administrators and Help Desk personnel to monitor and control Windows Mobile devices, such as performing a remote wipe on any devices reported as lost or stolen. With Exchange Server 2007, mobile device management is integrated into the Exchange Server Management Console and the self-service capabilities exposed via Outlook Web Access. Exchange Server 2007 also has built in support for Windows PowerShell, to administer Exchange from the command line. The IT Professional can administer mobile powered devices in Exchange ActiveSync with the Exchange Management Shell. Security Policies on Windows Mobile Devices Managed by Exchange Server Some built-in security features on Windows Mobile devices can be controlled from Exchange Server, allowing you to establish enforced security policies from the server. These policies are set on the Exchange server and delivered to the client through Exchange ActiveSync. The security settings on the device are established when the user receives and accepts the policy information from the server. The following security settings on Windows Mobile-powered devices can be managed through Exchange Server: Exchange Security or Mailbox Policies Exchange Server 2003 SP2 Exchange Server 2007 Require a password to access the device and configure it X X Set a minimum password length X X Require an alphanumeric password X X Specify how many minutes of inactivity before the device locks X X Wipe the device remotely X X Wipe the storage card remotely X Allow access to non-provisionable (pre-MSFP) devices X X Set the policy refresh interval X X Allow or disallow attachments to be downloaded x Set maximum attachment size X Enable encryption on the removable storage card X Set password expiration date X Enable password recovery X Prevent patterned PIN (1111 or 1234) on device X Specify how many failed password attempts before device wipe Specify how many failed password attempts before storage card X X X Security for Windows Mobile Messaging in the Enterprise wipe Allow or disallow access to files on Universal Naming Convention shares X Allow or disallow access to files on Sharepoint® Services sites X For more information about security policies and security roles, see Security Policies in Security on the Device. In Exchange Server 2007, the system administrator can define and name multiple sets of security policies and apply them to individual users or to different user groups in Active Directory. When a mobile device security policy is defined on the server, it is automatically sent to each device the next time the user of the device starts synchronization. On the initial receipt of the policies, the user can choose to accept or decline the policy, although if they don't accept, they will not be able to synchronize with the system. Once the policies are accepted, the only way to disable them is to do a hard reset on the device. During a hard reset, changes made to the registry or object store will not persist. Another feature allows the administrator to specify that users with older devices without security policy capacity may still connect to the network. This enables administrators to allow connections from older devices until those devices can be replaced, while still providing policy controls for devices that fully implement Exchange ActiveSync. If you have Manager role permissions on your corporate mobile devices, you can also change device policies by using over-the-air provisioning. See Adding Certificates to Windows Mobile Powered Devices in Security Model for Windows Mobile 5.0 and Windows Mobile 6. Setting Device Security or Mailbox Policies from Exchange Server The capabilities and tools for managing Exchange ActiveSync devices have evolved from Exchange Server 2003 SP2 to Exchange Server 2007. Either product provides control necessary for critical security policies on client devices. In the following discussion, the two server releases are presented separately. Device Security Policies in Exchange Server 2003 SP2 The system administrator can use the Exchange System Management Console to set password length and strength, and to control the inactivity period and number of failed password attempts before a device is wiped. Note The term password, as used in this discussion, refers to the password or PIN a user enters to unlock his or her mobile device. It is not the same as a network user password or a SIM pin. The following illustration from the Exchange System Manager interface in Exchange Server 2003 SP2 shows the Device Security Settings. When you choose Enforce password on device, the rest of the options become available. 21 Security for Windows Mobile Messaging in the Enterprise The security policies that can be controlled with Exchange ActiveSync in Exchange Server 2003 SP2 include the following: Option Description Minimum password length (characters) Specifies the required length of the user's device password. The default is 4 characters. Range is 4 to 18 characters. Require both numbers and letters Password must contain both numbers and letters (strong alphanumeric password). The default is numbers only. Inactivity time (minutes) Specifies how many minutes of inactivity are allowed before the device locks, requiring the user to log on again. Not enforced unless selected. If selected, default is 5 minutes. Wipe device after failed (attempts) The device memory will be wiped after multiple failed logon attempts. Not enforced unless selected. If selected, default is 8 attempts. Refresh settings on the device (hours) Specifies the time interval for the security policies to be pushed to the device. Not refreshed unless selected. If selected, default is every 24 hours. Allow access to devices that do not fully support password settings. Allows devices that do not support the security policies (non-MSFP devices) to synchronize with Exchange Server. Not selected by default. If not selected, these devices will receive a 403 error message when they attempt to synchronize with Exchange Server. Security for Windows Mobile Messaging in the Enterprise Device Security Policies in Exchange Server 2007 When you install the Client Access server role in a Microsoft Exchange 2007 organization, Microsoft Exchange ActiveSync is enabled by default. You can configure Exchange ActiveSync for a user or a group of users with the Exchange Management Console or the Exchange Management Shell; both methods provide wizards to simplify the process. The following illustration from the Exchange Server 2007 ActiveSync Mailbox Policy wizard shows the mailbox policy options that can be configured and assigned to individuals or groups of mailbox users. Mailbox policies that can be controlled with Exchange ActiveSync with Exchange Server 2007 include the following options: Option Description Allow non-provisionable devices Allows older devices (those that do not support the Autodiscover service) to connect to Exchange 2007 by using Exchange ActiveSync. Allow simple password Enables or disables the ability to use a simple password such as a 4-digit PIN. Simple patterns (1234, 1111) are always blocked. Require alphanumeric password Requires a strong alphanumeric password containing numeric and non-numeric characters. Allow attachments to be downloaded to device Enables attachments to be downloaded to the mobile device. 23 Security for Windows Mobile Messaging in the Enterprise Require encryption on storage card Applies to Windows Mobile 6: Enables encryption on the removable storage card. Remotely wipe storage card Applies to Windows Mobile 6: Wipes the storage card, unless it is write-protected. Require password Enables the device password Password expiration (days) Applies to Windows Mobile 6: Enables the administrator to configure a length of time after which a device password must be changed. Policy refresh interval Defines how frequently the device updates the Exchange ActiveSync policy from the server. Maximum attachment size Applies to Windows Mobile 6: Specifies the maximum size of attachments that are automatically downloaded to the device. Maximum failed password attempts Specifies how many times an incorrect password can be entered before the device performs a wipe of all data including storage card. Time without user input before password must be re-entered (in minutes) Specifies the maximum length of time a device can go without user input before it locks. The user can specify a shorter time. Minimum password length Specifies the minimum password length. Enable password recovery Applies to Windows Mobile 6: Enables the device password to be recovered from the server. UNC file access Applies to Windows Mobile 6: Enables access to files stored on Universal Naming Convention (UNC) shares. WSS file access Applies to Windows Mobile 6: Enables access to files stored on Microsoft Windows Sharepoint Services sites. In addition to the security and mailbox policies described above for both versions of Exchange Server, you can specify individual users who you want to exempt from the settings you have configured. This exceptions list is useful if you have specific, trusted users who do not require device security settings. However, when using this feature bear in mind that executives or other key employees who might request exemptions most likely have highly valuable data on their devices and should not necessarily be exempted from security policies. When coupled with the Windows Mobile remote device wipe mechanism, these security policies provide an effective means of preventing an attacker from recovering data from a device. In addition, these security policies do not have the performance or battery life overhead of solutions that encrypt all data on the device as it is created or moved. Security for Windows Mobile Messaging in the Enterprise Local and Remote Device Wipe When a mobile device is lost or stolen, the potential security risk can be significant. Mobile devices often contain sensitive business data, including personally identifiable information of employees and customers, sensitive e-mail messages, and other items that could have a negative impact on the business. Exchange ActiveSync addresses this risk by providing two levels of device wipe capability for Windows Mobile 5.0-based devices with MSFP or later. Wiping the device locally or remotely has the effect of performing a factory or “hard” reset; all programs, data, and user-specific settings are removed from the device. The Windows Mobile device wipe implementation wipes all data, settings, and private key material on the device by overwriting the device memory with a fixed bit pattern, greatly increasing the difficulty of recovering data from a wiped device. Note Device wipe in Windows Mobile 6 includes wiping the removable storage card. Local device wipes are triggered on a device with device lock enforced if a user incorrectly enters a PIN more than a specified number of times (the policy default is 8 times, but the administrator can adjust this value). After every two missed attempts, the device displays a confirmation prompt that requires the user to type a confirmation string (usually “A1B2C3”) to continue. This prevents the device from being wiped by accidental key presses. Once the PIN retry limit is reached, the device immediately wipes itself, erasing all local data. Remote wipes occur when the administrator issues an explicit wipe command through the Exchange ActiveSync management interface. With OWA 2007 and Exchange Server 2007, the device user can also initiate a wipe command if they have lost their device. Remote wipe operations are separate from local wipes, and a device can be wiped remotely even if Exchange ActiveSync security policies are not in force. The wipe command is pushed as an out-of-band command, so that the device receives it on its next synchronization. The device sends an acknowledgement message when it receives the wipe command, alerting the administrator that the wipe has occurred. The device user cannot opt out of the remote wipe. Exchange ActiveSync Security Policies for Exchange Server 2003 SP2 For more information on the process of using and configuring Exchange ActiveSync security policies from the Exchange Server, please see the Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2, available from http://go.microsoft.com/fwlink/?LinkId=54738. Exchange ActiveSync Security Policies for Exchange Server 2007 For more information on the process of using and configuring Exchange ActiveSync security policies from the Client Server Access role of Exchange Server 2007, see Managing Client Access available from . 25 Security for Windows Mobile Messaging in the Enterprise This page left intentionally blank Security for Windows Mobile Messaging in the Enterprise Security within the Corporate Network The Windows Mobile security architecture provides components and tools that can utilize your existing corporate network infrastructure. You can build a secure communications environment using standard Internet protocols on any of a variety of network configurations, deploying firewalls and authentication protocols that fit your needs, whether your company is large or small. Network Configuration Microsoft’s recommended network configuration places all Exchange servers within the corporate network; the Internet Security and Acceleration Server (ISA server) acts as the advanced firewall in the perimeter network that is exposed to Internet traffic. This adds an additional layer of security to your network. All incoming Internet traffic bound to your Exchange servers – for example, Microsoft Office Outlook Web Access (OWA) and remote procedure call (RPC) over HTTP communications from Microsoft Office Outlook 2003 clients – is processed through an ISA Web listener. When the ISA server receives a request from an Exchange server, the ISA server authenticates the connection and performs packet inspection to ensure that requests are real and then proxies the request to the appropriate Exchange servers on your internal network. The Exchange servers on your network then return the requested data to the ISA server, which sends the information to the client through the Internet. During installation of the ISA server, Microsoft strongly recommends that you enable Secure Sockets Layer (SSL) encryption, and designate 443 as the SSL port. This leaves the 443 port open as the “Web listener” to receive Internet traffic. Microsoft also recommends that you set up basic authentication for Exchange ActiveSync, and that you require all clients to successfully negotiate an SSL link before connecting to Exchange ActiveSync site directories. If you follow these recommendations, the Internet traffic that flows into and out of the 443 port will be more protected. When configured in Web-publishing mode, ISA Server 2006 will provide protocol filtering and hygiene, denial of service (DoS) and distributed denial of service (DDoS) protection, as well as pre-authentication. The following illustration shows the recommended Exchange Server 2003 or 2007 deployment for mobile messaging with ISA Server 2004 or 2006. For more information on alternative network configurations, see Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2 at this location: http://go.microsoft.com/fwlink/?LinkId=81200 27 Security for Windows Mobile Messaging in the Enterprise ISA Server The Internet Security and Acceleration Server product family is Microsoft’s line of enterprisegrade firewalls. ISA Server is a key part of Microsoft’s overall security strategy; it provides edge network filtering and security along with full compatibility with the complete set of Microsoft server products, including Exchange Server, SharePoint, and Windows Server. In mobile messaging deployments, ISA Server offers some specific benefits that make it a good fit for Windows Mobile and Exchange: ISA Server protects against most unauthenticated denial-of-service attacks, safeguarding Outlook Web Access and Exchange ActiveSync servers from attack and intrusion ISA Server 2004 can act as an endpoint to decrypt and inspect inbound traffic, passing only legitimate traffic to the destination endpoint. This capability, known as SSL bridging, adds valuable extra protection to OWA and Exchange ActiveSync deployments. ISA Server 2006 adds a new feature that terminates the SSL connection from the mobile device at the ISA server and allows the mobile device to authenticate a client connection, using Kerberos-constrained delegation to the Exchange server. This improves security because traffic can be inspected at ISA and then passed to the Exchange server for processing. ISA Server can pre-authenticate users of Web-based applications (including OWA) to ensure that unauthenticated users never make any kind of connection to the application server. ISA Server includes easy-to-use wizards that allow administrators to easily publish access to select Exchange services, SharePoint servers, or other Web-based applications. The wizards ease the process of publishing these services, while at the same time reducing the chances of making a configuration mistake that might reduce security. ISA Server integrates with familiar management tools like Microsoft Operations Manager, and it can be run on a Windows server or on appliances available from a variety of vendors. Because of these benefits, many Windows Mobile customers choose to deploy ISA Server as their primary network firewall. However, it is important to note that ISA Server is not required to securely deploy Windows Mobile devices. Any firewall that can pass HTTPS (TCP port 443) traffic from the firewall to the Exchange server can be used to secure Exchange ActiveSync traffic. Data Encryption with SSL The Secure Sockets Layer (SSL) protocol is a time-tested and mature security protocol that is widely used to protect Internet communications against tampering and interception. The SSL protocol allows two endpoints to establish a connection with confidentiality (provided by encryption) and integrity protection (provided by digital signatures and the optional use of mutual client-server authentication). SSL must be applied to a communications protocol; for example, an SSL-protected Hypertext Transfer Protocol (HTTP) connection can be used to secure communications between a user’s Web browser and a server on the Internet. This combination, known as HTTPS, is the primary security mechanism used to provide secure browser-based access to Web sites, including major banks, credit card companies, e-commerce sites, and a wide range of other services. However, SSL can also be used with other communications protocols, including SMTP, the Session Initiation Protocol (SIP) used by Microsoft Live Communications Server, and application-specific protocols. In the Windows Mobile security architecture, SSL plays an important role in protecting device communications. The default method for establishing Exchange ActiveSync connections requires the use of SSL to encrypt the connection between the mobile device and the Exchange server. Because Exchange ActiveSync uses HTTP as its base communications method, this provides effective security — as evidenced by the wide use of HTTPS to protect billions of high-value commercial transactions across the Internet — while requiring only one port to be opened on the enterprise firewall. Windows Mobile fully supports ordinary HTTPS connections, both through its Security for Windows Mobile Messaging in the Enterprise application programming interfaces (APIs) and in the Windows Mobile edition of Internet Explorer. This support allows line-of-business applications and user browsing to be protected using the same robust security mechanism as Exchange ActiveSync traffic. SSL includes a method for a client and server to negotiate an encryption algorithm and strength; this is designed to allow an arbitrary client-server pair to find the strongest encryption that both endpoints support. Both Windows Mobile and the Windows Server Internet Information Services (IIS) application server can take advantage of a broad set of cryptographic algorithms for use with SSL. In Windows Mobile 6, this includes support for AES which is available for SSL channel encryption in 128- and 256-bit cipher strengths. You can gain additional protection by enabling the use of only FIPS 140-2 compliant algorithms with SSL. Note At present, AES cannot be used with Exchange ActiveSync because EAS is built on IIS which does not currently support AES. For more information about SSL on Windows Mobile devices, see Secure Sockets Layer (SSL) support in Security on the Device. For more information, see Cryptographic Services and FIPS Compliance in Security Model for Windows Mobile 5.0 and Windows Mobile 6. Using Firewalls: Exchange Server Minimizes the Need for Open Ports From a security standpoint, one of the biggest advantages of using Exchange ActiveSync and Windows Mobile is the fact that all communications between the device and the Exchange server take place over a single TCP/IP port: TCP port 443, used for SSL-secured HTTP traffic. The following figure shows a typical configuration with the open ports and idle session time. This greatly simplifies enterprise firewall configuration, because only a single port needs to be opened from the Internet to the Exchange ActiveSync server, and that port will probably be open in any case because it’s the same port used for OWA. Direct Push Firewall Timeouts and DoS threats to the Corporate Network When using direct push, the firewall session interval on the corporate network must be set to 30 minutes to allow the mobile device and the Exchange Server to communicate freely. If the firewall closes the session prematurely, mail would be undeliverable until the client reconnects, and the user could be unsynchronized for long periods of time. Setting the firewall session timeout equal to or greater than the idle timeout on the mobile operator's network ensures that the firewall will not close the session. 29 Security for Windows Mobile Messaging in the Enterprise Firewall idle connection timeouts: Operators need to set the idle connection timeouts on outgoing firewalls to 30 minutes. Enterprises also need to set timeouts on their incoming firewalls to 30 minutes. Web servers, network security appliances, and system network stacks have several time-based thresholds that are intended to insulate them from insufficiently tested or malicious clients. You can safely increase the idle connection timeout setting without compromising the security of the network. Increasing the idle connection timeout typically does not increase or decrease exposure to attacks. The following table shows examples of unauthenticated attacks and describes how other settings are used to mitigation exposure to them. DoS Threat Mitigation of exposure to attacks A DoS attack is launched by failing to complete the handshake that is implicit in the creation of a TCP connection. The attacker attempts to create a large number of partially open TCP connections. Increasing the idle connection timeouts is unrelated to this type of attack. A DoS attack is launched against IIS by opening a large number of TCP connections but never issuing an HTTP request over any of them. Increasing idle connection timeouts is unrelated to this type of attack. An attacker establishes a large number of TCP connections, issues HTTP requests over all of them, but never consumes the responses. Increasing idle connection timeouts is unrelated to this type of attack. The time within which a TCP handshake must complete is a separate threshold that is governed by the Windows TCP/IP stack. IIS mitigates this threat by requiring that a client submit a fully formed HTTP request within a certain time before dropping the connection. The name of the Connection Timeout setting in the IIS management console is misleading; TCP connections are closed when the Connection Timeout value is exceeded. The default is 120 seconds. This threat is mitigated by the same timeout as the previous scenario. The Connection Timeout setting in IIS defines the time within which a client must issue either its first request after a TCP connection is established or a subsequent request in an HTTP keep-alive scenario. For detailed information about the direct push technology, see Mobile Operator Guide to Messaging and Security Feature Pack for Windows Mobile 5.0-based Devices, at http://go.microsoft.com/fwlink/?LinkId=83456. Authentication for Mobile Devices on the Corporate Network Strong authentication not only protects the mobile device and the information stored on it, but it also protects any network access credentials and methods the device may use to access corporate resources. Using the certificate management configuration service providers and the certificate management tools provided by Microsoft, you can select an authentication method that fits your corporate network configuration and security requirements. Security for Windows Mobile Messaging in the Enterprise Basic Authentication on the Exchange Server Exchange 2003 and Exchange 2007 include Exchange ActiveSync, which relies on SSL to secure the connection between the Windows Mobile device and the Exchange front-end or client access server. The client device provides the domain user’s credentials using the SSL basic authentication method. This authenticates the client to the server. The device must have the root certificate of the Exchange front-end or client access server in order to establish a secure connection. Windows Mobile devices are shipped with a set of third-party trusted root and intermediate certificates. If you use one of these trusted certificates to secure your Exchange Server, these devices will be able to securely access your corporate network by entering their domain, name, and password. Certificate-based Authentication Windows Mobile 5.0 with MSFP and later devices can use SSL with Transport Layer Security (TLS) client authentication in place of SSL basic authentication. Certificate-based authentication offers a significant security advantage over the use of basic authentication. This advantage comes from two factors. First, the strength of the key is pre-determined by the administrator and can be very strong. Windows Mobile and Windows Server together support up to 2,048-bit keys. Second, requiring certificate-based authentication greatly reduces the risk that a user’s credentials will be compromised. A user cannot “loan out” their password, and an attacker who can sniff over-the-wire traffic will not be able to recover usable credentials because they are hashed and protected by SSL encryption during transport. To use certificate-based authentication with Windows Mobile, the mobile device must contain the root certificate for the Exchange front-end or client access server it is communicating with; the mobile device must also have its own client user certificate with the associated private key. The user certificate enrollment process can only occur when the device is connected to a desktop in the same domain as the enrollment web site. Certificate-based Authentication for Windows Mobile 5.0 The certificate enrollment process for Windows Mobile 5.0 MSFP devices uses ActiveSync desktop to connect to the corporate CA to receive the required user certificate and associated key. Once the user certificate and key are on the device, cradling with Desktop ActiveSync 4.1 or later is required only to renew the certificate when it expires. Microsoft has created a tool for deploying Exchange ActiveSync certificate-based authentication; it can be downloaded from the following Microsoft Download center Web site. http://go.microsoft.com/fwlink/?LinkId=54738. For an overview of setting up certificate-based authentication for use with Windows Mobile and Exchange ActiveSync, see Appendix A, Overview of Deploying Exchange ActiveSync with Certificate-Based Authentication, of the Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2, available at http://www.microsoft.com/technet/solutionaccelerators/mobile/deploy/msfpdepguide.mspx. Certificate-based Authentication for Windows Mobile 6 With Windows Mobile 6, the process for implementing Transport Layer Security (TLS) certificatebased authentication has been streamlined and made easier to maintain. The system administrator creates a certificate type and makes it available through Active Directory. The user then authenticates to the network, navigates to the designated location, and the client user certificate with the associated encrypted private key is passed to the user’s device. Note Wildcard certificates or certificates not supplied by a Microsoft Certificate Authority Server can be used with Windows Mobile 6 powered devices. 31 Security for Windows Mobile Messaging in the Enterprise For more information about using Desktop ActiveSync to set up certificate-based authentication on your network, see Adding Certificates to Windows Mobile 6 Powered Devices. Enabling RSA SecurID Authentication If you have an RSA SecurID infrastructure, you can use SecurID with your organization’s Windows Mobile devices and Exchange ActiveSync to gain the security benefits of two-factor authentication with direct push. To do this, you must install RSA’s ACE/Agent on the front-end Exchange server, and then configure it to protect the Exchange ActiveSync virtual directory. The detailed steps for doing so are outside the scope of this paper; for complete details on how to configure SecurID, please see the section titled “How to Use RSA SecurID with Exchange ActiveSync” in the Exchange Server Client Access Guide at the following Microsoft Web site: http://technet.microsoft.com/en-us/library/cfecf499-32a9-4b9a-9d2a-88e393be0bd2.aspx. Managing Device Certificates Digital certificates afford a powerful tool in establishing device and user identities for authentication. In a corporate environment, securely distributing and renewing digital certificates on hundreds of mobile devices can be a daunting task. With Windows Mobile 6 and desktop ActiveSync, the management of device certificates has been simplified. The certificate enrollment tools enable the system administrator to manage device certificates to create a more secure environment. You can use Windows Mobile 6 and ActiveSync certificate enrollment tools for the following company-wide activities: Deploying enterprise-wide Exchange ActiveSync or SSL TLS certificate-based authentication Renewing existing certificates Distributing 802.1x wireless certificates Providing certificates for S/MIME digital signing The process for adding certificates differs between Windows Mobile 5.0 and Windows Mobile 6. Adding Certificates to Windows Mobile 5.0-based Devices Network managers and device users can place additional certificates on devices if they have either Manager role permission on the device or have the ability to run trusted code. Another option is to contact your OEM or Mobile Operator for a signed certificate installation tool such as SPADDCERT.exe. Confer with your device vendor or mobile operator to ensure that the devices you intend to purchase will either work with the certificates you currently have deployed, that you can add the necessary certificates, or that you can replace your certificates in a cost-effective fashion. If you wish to install root certificates for certificate-based authentication, you can use the tool for deploying Exchange ActiveSync certificate-based authentication; it can be downloaded from the following Microsoft Download center Web site. http://go.microsoft.com/fwlink/?LinkId=54738. For more information, see the Microsoft Knowledge Base article, How to install root certificates on a Windows Mobile-based device available at the following Microsoft Web site: http://support.microsoft.com/kb/915840. Adding Certificates to Windows Mobile 6 Powered Devices With Windows Mobile 6-powered devices, you can easily and safely distribute the encrypted certificate/key pair required for certificate-based authentication or 802.1x wireless connection using Exchange ActiveSync Desktop enroll. Security for Windows Mobile Messaging in the Enterprise Note Anyone with User role permissions can install a certificate on a Windows Mobile 6 device by copying the .cer file to the device and running it. However, in order to enroll for a certificate from a Certificate Authority (CA), your device users should use Desktop ActiveSync. Desktop ActiveSync enables device users to enroll for a certificate from the corporate server to their cradled Windows Mobile-powered device. Your users connect to your network using the existing corporate desktop logon procedure -- password, smartcard, or other means of user identification. The two levels of authentication control the certificate enrollment, streamlining the distribution of the certificates. Desktop certificate enrollment can be used to query for and to renew certificates on mobile devices. You can also use the CertificateEnroller Configuration Service Provider to define certificate types and to create the provisioning XML that can be pushed to the mobile devices. For more information on provisioning or configuring mobile devices, see Security Model for Windows Mobile 5.0 and Windows Mobile 6. Desktop Certificate Enrollment Process To prepare for using desktop certificate enrollment, the system administrator should do the following: Set up or have access to a Windows 2000, 2003 or later Windows Certificate Server. Create the certificate type or use an existing certificate published to Active Directory. Inform users of the name and type of the certificate they should select. Provide users with instructions for using the Get Device Certificate user interface. Once the system administrator has published the certificate to Active Directory and directed the users to enroll for the certificate, the users will step through the following process: To enroll for a certificate with a Windows Mobile 6 powered device 1. From Advanced Tools, the user chooses Get Device Certificate, navigates to Active Directory on the corporate network, selects the desired certificate, and clicks Add. 2. The desktop processes the enrollment while the user waits a short period of time. During this time, the device generates a public/private key set and proxies the enrollment to the Windows Certificate Server through the desktop. 3. The CA returns a signed certificate to the desktop which, in turn, delivers the certificate to the device. 4. The device stores the certificate and its chain of certificates to the root CA. If the root certificate is not already in the root certificate store of the device, the user is asked to accept the certificate. 5. The user sees a success dialog to denote the end of the enrollment process. Once the certificate is in the user Root or CA store, the mobile device will be ready to authenticate with the desired protocol. Increasing E-Mail Security Mobile device users want to have the same rich feature set they have when using Outlook or OWA with their Exchange accounts. Using Exchange ActiveSync with Windows Mobile 5.0 with MSFP and later devices, mobile users can securely synchronize their devices with their Exchange mailbox; their communications are protected by SSL and the other security measures described in this paper. However, these solutions don’t protect the message once it reaches the Exchange server or the mobile device. You can increase e-mail security by using Information Rights Management (IRM) or Secure / Multipurpose Internet Mail Extensions (S/MIME). 33 Security for Windows Mobile Messaging in the Enterprise Support for Information Rights Management Applies to Windows Mobile 6: If your company is taking advantage of Information Rights Management, your employees will have the same protection extended to their mobile messaging experience. Windows Mobile 6 powered devices support replying to, forwarding, and composing IRM-protected e-mail. For example, using IRM protection a user can send sensitive information via e-mail or in Word, Excel or PowerPoint attachments and ensure that the e-mail or document is only viewed by the intended recipients. IRM protection is imposed on the e-mail or document itself – messages are protected before they leave a client's Outlook session and remain protected when stored on the Exchange server. IRM Client DLLs on the Windows Mobile 6 powered device communicate directly with the rightsmanagement server to get user-specific licenses for accessing content and handle encryption and decryption of communications between client and server. The IRM client on Windows Mobile 6 supports the following: Complete support for IRM protected e-mail communications including Downloading and decrypting messages and attachments Forwarding and replying to messages while preserving the rights restrictions Composing new “Do Not Forward” IRM protected messages Support for reading and editing Microsoft Office Word, Excel and PowerPoint documents. The following components are required for implementing IRM in your corporate environment: Windows Mobile 6 powered devices Desktop Outlook 2003 or later Exchange Server 2003 or 2007 Windows Rights Management Server SP1 for Windows Server System 2003 Using S/MIME with Windows Mobile Powered Devices Windows Mobile 5.0 based devices with MSFP and Windows Mobile 6 powered devices support sending and receiving S/MIME messages. The S/MIME standard defines a format for message security that allows e-mail users to exchange signed and/or encrypted e-mail. Signed e-mail enables the recipient to confirm that a message really came from the sender and was not tampered with en route. Encryption maintains the confidentiality of e-mail messages at rest and in transit. In an organization where user certificates are stored on smartcards, Windows Mobile can use those certificates to read and send S/MIME messages. Note Windows Mobile 5.0 based devices with MSFP supports only physically separated Common Access Card (CAC)/smart card implementations. Windows Mobile 6 powered devices support both smart card and soft certificate implementations by using PFX Import. Exchange 2003 SP2 provides support for S/MIME messages through Exchange ActiveSync. If your organization does not have S/MIME deployed with Exchange Server 2003 SP2, you can get more information in the Exchange Server Message Security Guide, available from http://go.microsoft.com/fwlink/?LinkId=34666. Security for Windows Mobile Messaging in the Enterprise Conclusion The Windows Mobile Security Model is designed to provide a robust, protected environment for a mobile messaging solution. The components can fit into your existing corporate network with a minimum of third party components or services. Windows Mobile powered devices used with Exchange ActiveSync in combination with ISA Server and IIS combine to present an exceptionally strong enterprise messaging solution: Powerful code on the device Windows Mobile powered devices can be controlled and customized to fit the needs of complex Enterprise solutions. The code on the devices is robust and conforms to industry standard security and cryptographic services that can be mass configured or provisioned, providing devicelevel control in the Enterprise setting. Direct interaction and control with Exchange ActiveSync Exchange ActiveSync protocols contain the ‘hooks’ into the code on Windows Mobile powered devices so that the system administrator can define and deploy security policies that help protect device and network security. Exchange Server management tools and tracking programs leverage OWA and Active Directory, facilitating administration of both front-door and back-door devices. Robust network components and protocols ISA Server and IIS, along with standard Web delivery and security protocols, work with existing corporate network configurations to complete the Windows Mobile Security architecture. Strong firewall protection and support for PKI and certificate-based network client authentication protocols facilitate the deployment of rigorous corporate security requirements. See Also Security for Windows Mobile Messaging in the Enterprise 35