Export (0) Print
Expand All

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.

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.

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

Protection Goal Windows Mobile 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 Considerations on the Exchange Server.

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.

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 two-tier 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 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.

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. http://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 http://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.

Cc182275.note(en-us,TechNet.10).gifNote:
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.

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.

Cc182275.note(en-us,TechNet.10).gifNote:
Device wipe in Windows Mobile powered devices that run 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.

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.

Cc182275.note(en-us,TechNet.10).gifNote:
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 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.

Cc182275.note(en-us,TechNet.10).gifNote:
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 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.

Cc182275.note(en-us,TechNet.10).gifNote:
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 security enhanced solution. If possible, 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 help prevent 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 2007.

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

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

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.

The following steps show the recovery process:

  1. The user creates a new PIN to unlock the device.
    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 Reset process.
  2. The user obtains the recovery PIN through Outlook Web Access or by calling a Helpdesk.
  3. The user enters the recovery PIN and then enters the new PIN created in the first step of this process to unlock the device.
  4. 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 store passwords on the device to help 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 2007.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft