Security Model for Windows Mobile 5.0 and Windows Mobile 6

Article
06/02/2010

6/2/2010

Windows Mobile-powered devices employ a combination of security policies, roles, and certificates to address configuration, remote access, and application execution.

Download

You can open or save this document. To do so, choose download this paper.

Overview

Security policies provide the flexibility to control access to the device. If a user or application is allowed access, security policies then control the boundaries for actions, access and functionality. The following list shows some of the ways you can use security policies on Windows Mobile-powered devices:

Control which applications are allowed to run on the device and what they can do.
Control who can access specific device settings, and their level of access.
Control what desktop applications can do on the device (Remote API (RAPI) control through ActiveSync).

Policies configure security settings that are then enforced with the security roles and certificates:

Security roles determine access to device resources, based on message origin and how the message is signed.
Certificates are used to sign executables, DLLs, and CAB files that run on Windows Mobile-powered 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

Protection Against Threats and Risks

The following features help protect devices against a variety of threats and risks:

Threat or Risk	Windows Mobile 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
	Local device wipe occurs after a specified number of incorrect login attempts		X	X
	Remote device wipe erases data and helps to prevent unauthorized use		X	X
	Exponential back-off if incorrect passwords are entered	X	X	X
	Local storage card wipe erases data and helps to prevent unauthorized use			X
	Remote storage card wipe erases data and helps to prevent unauthorized use			X
	Storage card encryption helps to prevent 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	X	X
	Password policy enforcement, such as required password for synchronization		X	X
Access to data during transmission	Secure Sockets Layer (SSL) encryption of all data transmitted between the device and the corporate mail server	X	X	X
	Advanced Encryption Standard for SSL channel encryption in 128 and 256 bit cipher strengths.			X
	Encrypted data passes through a single SSL port on the firewall	X	X	X
	Cryptographic implementations are certified by US Federal Information Processing Standard (FIPS) 140-2, and are designed to be protected against a variety of potential threats. Supported algorithms include: Advanced Encryption Standard (AES) DES and 3DES, Secure Hash Algorithm (SHA-1), RSA public-key encryption and decryption.	X	X	X
Unauthorized penetration into corporate network	Flexible client authentication: SSL TLS, Exchange ActiveSync, Certificate-based, RSA SecurID-protected	X	X	X
	Users can add root certificates without being a manager of the device; user root certificates will not compromise the level of security established by the device management security settings.			X
Unauthorized penetration into mobile device	Security policies help to control over-the-air access to device	X	X	X
	Bluetooth discovery mode can be prohibited to help guard device integrity (Supported in Windows Mobile 6 Standard only)			X
Device corruption	Security policies help control acceptance of unsigned attachments, applications, or files Two-tier access for code execution control — executable runs if it is signed; permissions indicate access. (Supported by Windows Mobile powered 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			X
Malicious software or viruses on mobile devices	Office Mobile does 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

Permissions

Application execution is based on permissions. Windows Mobile-powered devices have a two tiered permission model, or applications can be blocked:

Privileged
Normal
Blocked

Applications running at the privileged level have the highest permissions: they can call any API, write to protected areas of the registry, and have full access to system files. Few applications need to run as privileged. In fact, allowing them to run privileged allows them to change the operating system environment, and can threaten the integrity of the device.

Most applications run normal. They cannot call trusted APIs, write to protected areas of the registry, write to system files or install certificates to protected stores. They could still install a certificate to the MY store, however.

Applications do not run if blocked 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 permission. The first part of the security policy is known as access tiers; devices can have one-tier or two-tier access.

Security policy settings	Description
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. Signed with a known certificate Signed applications execute with no further checks and run with privileged permissions on the device. They can call any API, modify any part of the file system, and modify any part of the registry. In a one-tier device, an application that is allowed to be run on the device has the MANAGER role. Unsigned or signed with an unknown certificate Unsigned applications or those signed with a certificate that the device does not recognize require further policy checks to determine if they can run, then security policies are checked to determine whether to prompt the user to allow them to run. If they are allowed to run, they run with the same permissions as if they were a signed application.
Two-tier access	A device with two-tier access restricts application start and run-time permissions. Signed with a known certificate Applications signed with a certificate that the device recognizes execute with no further checks. There is a distinction between Privileged and Normal applications: Applications signed with a certificate from the Privileged Execution Trust Authorities certificate store execute with privileged permissions and therefore have full access to the device. All other applications run with normal permissions. Applications running with normal permissions can read from protected areas of the registry, and read contents of files marked with the System attribute. They cannot write to protected areas of the registry, to system files, or access files in the \Windows\System directory. In two-tier device, Applications running privileged have the MANAGER role, and those running normal have the USER_AUTH role. Most applications only require normal permissions to run. Unsigned or signed with an unknown certificate Unsigned applications or those signed with a certificate that the device does not recognize require further policy checks to determine if they can run. If they are allowed to run, they will run with normal permissions.

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.

Signed with a known certificate

Signed applications execute with no further checks and run with privileged permissions on the device. They can call any API, modify any part of the file system, and modify any part of the registry.

In a one-tier device, an application that is allowed to be run on the device has the MANAGER role.

Unsigned or signed with an unknown certificate

Unsigned applications or those signed with a certificate that the device does not recognize require further policy checks to determine if they can run, then security policies are checked to determine whether to prompt the user to allow them to run. If they are allowed to run, they run with the same permissions as if they were a signed application.

Two-tier access

A device with two-tier access restricts application start and run-time permissions.

Signed with a known certificate

Applications signed with a certificate that the device recognizes execute with no further checks.

There is a distinction between Privileged and Normal applications:

Applications signed with a certificate from the Privileged Execution Trust Authorities certificate store execute with privileged permissions and therefore have full access to the device.
All other applications run with normal permissions. Applications running with normal permissions can read from protected areas of the registry, and read contents of files marked with the System attribute. They cannot write to protected areas of the registry, to system files, or access files in the \Windows\System directory.

In two-tier device, Applications running privileged have the MANAGER role, and those running normal have the USER_AUTH role. Most applications only require normal permissions to run.

Unsigned or signed with an unknown certificate

Unsigned applications or those signed with a certificate that the device does not recognize require further policy checks to determine if they can run. If they are allowed to run, they will run with normal permissions.

The following table shows the platform support for these security configurations:

Platform	Supports one tier	Supports two tier
Windows Mobile 5.0 powered Smartphone	Yes	Yes (default)
Windows Mobile 5.0 powered Pocket PC Phone	Yes (default)	No
Windows Mobile 5.0 powered Pocket PC	Yes (default)	No
Windows Mobile 6 Professional	Yes (default)	No
Windows Mobile 6 Classic	Yes (default)	No
Windows Mobile 6 Standard	Yes	Yes (default)

The 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 the unsigned application executes.

Together these settings create the following common security levels:

Security level	Description
Security off	Both signed and unsigned applications are allowed to run with no further security checks and without prompting the user. (This is a one-tiered policy.) Any application can call any API, and modify any part of the registry and file system. This policy may be used during the testing phase of a device, but it is not a safe policy to have on an actual device. A device with this policy would be vulnerable to malicious applications and allow unrestricted access to the device.
One-tier prompt	This policy allows applications signed with a certificate recognized by the device to execute with no user prompt, since the application's certificate matched a device certificate. The device prompts the user before allowing unsigned or incorrectly signed applications to run. Once a signed or unsigned application is running, it has full permissions on the device.
Two-tier prompt	This policy allows signed application to execute. The device prompts the user before executing unsigned applications. Once a signed application is executing, the application permissions are determined by the certificate: Applications signed with a certificate in the Privileged Execution Trust Authorities store have unrestricted access to the device. Applications signed with a certificate from the Unprivileged Execution Trust Authorities store run with normal permissions. They can read from protected areas of the registry, and read contents of files marked with the System attribute. They cannot write to protected areas of the registry, to system files, or access files in the \Windows\System directory. If a user allows an unsigned application to execute, it executes with normal permissions.
Mobile2Market locked	Applications that are signed can execute; Unsigned applications are not allowed to execute. Once the application is running, the permissions are determined by whether the application is signed with a certificate from the Privileged Execution Trust Authorities store or the Unprivileged Execution Trust Authorities store. Mobile2Market is the Microsoft certification and marketing program for mobile applications for independent software and hardware vendors. Mobile2Market partners provide certificate authority and digital signature services for Windows Mobile. Once certified, applications can be marketed through Mobile2Market's Mobile Application catalog.
Locked	Market2Market certificates have been removed from the device, but OEM, Mobile Operator, or Enterprise certificates are present.

CAB Signing

Cabinet (.cab) files are used to package applications or updates, such as new DLL files, for delivery. Depending on security policy settings, you may need to sign .cab files to install the contents. You can use Microsoft Authenticode tools to sign .cab files.

Note

Files signed using the Authenticode tool can be later revoked.

If the policy settings require signed .cab files, the one creating the cab must confirm the following:

The revocation list does not include the certificate hashes. A certificate hash is a digest of the certificate data.
The revocation list does not include the .cab file hashes.
The certificate chain maps to a root certificate in the Software Publisher Certificate (SPC) store.

The .cab file is installed with the role mask associated with the root certificate. If the store does not contain a matching root certificate, the .cab file is treated as an unsigned .cab file. The Unsigned CABS policy determines whether the file can be installed and with which role mask an accepted file is installed

Executables and DLL Signing

Executables and DLLs are signed and validated against certificates in the device Privileged or Unprivileged certificate stores.

The following list shows the behavior based on permissions:

Privileged executables cannot access DLLs that have Normal permissions.
Normal executables can load Privileged DLLs, but the DLL will run at Normal level. This is because the privilege is assigned to processes rather than to modules.

Other Resources

Security Considerations for Windows Mobile Messaging in the Enterprise

Share via