Security Considerations on the Device

6/2/2010

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 Considerations on the Exchange Server.

Permissions

Application execution is based on permissions. Windows Mobile-powered devices have a two-tiered 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.
• 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 powered Smartphones 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 are configurable and provide the flexibility to help control access to the device. If a user or application is allowed access to the device, the security policy settings are designed to control the boundaries for action. For example, policies determine whether to accept unsigned messages, applications, or files. Security policy settings 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 help protect the device by setting security policies using Exchange Server. Security roles define who can change each policy; the default role is listed.

For a complete list of features that can be changed with Exchange ActiveSync and information about how to change the policy settings, see Security Considerations 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 powered 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 e-mail 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.

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 powered 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 powered 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 help 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.

The following table shows the certificate stores and their uses and permissions.

Installing Certificates on a Windows Mobile Powered Device that runs Windows Mobile 6

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 powered devices that run Windows Mobile 6 will install certificates delivered in the following file formats:

• 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, e-mail attachment, or Mobile Internet Explorer file download. Windows Mobile powered devices that run Mobile 6 Professional 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 Considerations 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 are designed to be 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 support for remote access networking and authentication, including Windows NT® LAN Manager Challenge/Response protocol version 2 (NTLMv2), SSL 3.1, Private 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.
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. https://go.microsoft.com/fwlink/?LinkID=82573.
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: WPA2 provides a stronger encryption mechanism through Advanced Encryption Standard (AES) with key sizes of 128 and 256 bits.
Storage card encryption	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-powered device, or download applications. The SSL protocol helps Web servers and Web clients 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-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2 at https://go.microsoft.com/fwlink/?LinkId=81200 For information about using SSL in a network configuration, see Security Considerations 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 help 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 level of security approved by NSA for TOP SECRET information, the highest level of security the U.S. government requires.

Windows Mobile provides 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 ActiveSync

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 Considerations 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 powered 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.

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 erased.

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 Considerations 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.

Authentication with LAS and LAP

Local Authentication Subsystem (LASS) allows flexible integration of Local Authentication Plug-ins (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.

Applies to Windows Mobile 6:

The following table describes the additional LAP functionality in Windows Mobile 6.