Ask Learn
Preview
Please sign in to use this experience.
Sign inNote
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
4/8/2010
Windows Mobile devices are shipped with default security settings. The security model enables Mobile Operators to make post-production changes to security settings. In addition, you can change the default settings.
Note
This section describes the designed and intended functionality of the security model. This does not guarantee that an intentional malicious attack cannot compromise the intended security protection. The security functionality described below is provided AS IS and no warranty is implied as to the performance of this functionality.
The following table summarizes the security model.
| Item | Description |
|---|---|
Application execution security |
Applies to code execution. Controls the applications that can run on the device. Controls what applications can do. |
Device configuration security |
Applies to device management security. Controls who can access to specific device settings. Controls the level of access to device settings. |
Remote access security |
Remote API (RAPI) control through ActiveSync. Controls what desktop applications can do on the device. |
Windows Mobile devices employ a combination of security policies, roles, and certificates to address configuration, remote access, and application execution.
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 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 devices.
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.
|
Two-tier access |
A device with two tier access restricts application start and run-time permissions.
|
For unsigned applications running on a device with one-tier access, the following security policies are checked to determine whether an application can run on the device:
- The unsigned applications policy (SECPOLICY_UNSIGNEDAPPS) is checked to determine whether unsigned applications are allowed to run on the device.
- If unsigned applications are allowed to run on the device (SECPOLICY_UNSIGNEDAPPS=1), then the Unsigned Prompt policy is checked. If the Unsigned Prompt policy (SECPOLICY_UNSIGNEDPROMPT) is 1 then the user is not prompted and the application is allowed to run privileged. If the Unsigned Prompt policy is zero (SECPOLICY_UNSIGNEDPROMPT = 0), then the user is prompted to specify whether to allow the unsigned application to run. If the user allows the application to run, the application runs privileged.
The following table shows the platform support for these security configurations:
| Platform | Supports One-tier | Supports Two-tier |
|---|---|---|
Smartphone for Windows Mobile 2003 |
Yes |
Yes |
Pocket PC for Windows Mobile 2003 |
No |
No |
Smartphone for Windows Mobile Version 5.0 |
Yes |
Yes (default) |
Pocket PC for Windows Mobile Version 5.0 |
Yes (default) |
No |
Windows Mobile Professional |
Yes (default) |
No |
Windows Mobile Classic |
Yes (default) |
No |
Windows Mobile Standard |
Yes |
Yes (default) |
Windows Mobile Standard two-tier device (SECPOLICY_PRIVELEGEDAPPS=0) provides greater flexibility in how applications are allowed to run on the device. In the one-tier device, applications are either allowed to run or not allowed to run. In the two-tier security device, when the application is allowed to run there is a distinction between running privileged and normal. All signed applications running privileged can access every aspect of the device. All signed applications running normal cannot access the protected registry keys and system APIs.
The two-tier security device (SECPOLICY_PRIVELEGEDAPPS=0) uses the application's signature to determine whether the application runs privileged or normal. If the application is signed with a certificate in the privileged certificate store, then the application will run privileged. If the application is signed with a certificate in the normal certificate store, then the application will run normal.
Note
A device should not be converted from a one-tier device to a two-tier device during its normal lifetime. Once a device is built as a one-tier device, it can be converted to a two-tier device only with a complete flash of user data. The same is true for converting from two-tier device to one-tier device.
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:
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 Program 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. |
Application execution is based on permissions. Windows Mobile devices have a two tiered permission model, or applications can be blocked. Privileged and normal permissions distinguish what applications can do when they run.
- Privileged
Applications running at the privileged level have the highest permissions. They can call any API, write to all areas of the registry (including protected areas), and have full access to system files. Applications running privileged can also install certificates on the device. Privileged applications can switch to run kernel mode.
For more information about restricted registry keys and system APIs for Windows Mobile 6.5, see Privileged APIs.
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. - Normal
Applications running normal cannot access protected registry keys and system APIs. Untrusted and unprivileged are the deprecated terms for normal.
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 can install a certificate to the MY store. - Blocked
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.
Revocation is the process that allows a Mobile Operator or device owner to block a specific application or group of applications. The device prevents the execution of the matching binaries. The application revocation mechanism used in Windows Mobile devices is separate from PKI certificate revocation and uses a different technology on the device.
A code signing certificate or a Certificate Authority (CA) certificate can be blocked by revoking the corresponding certificate. This way, a specific application developer or a whole class of applications can be blocked. An individual executable can be blocked by revoking the hash of the binary. When revoking a certificate, you should use the thumbprint of the certificate's SHA1 hash. When revoking a binary, you should the applications SHA1 hash. You can use the revoke.exe tool that is available in the SDK to create a revocation XML.
To revoke an item, you must send a revocation message to the device. This message can come from the Operator using an over-the-air (OTA) device management system, or by pushing a cab provisioning file (cpf) file that contains the WAP provisioning XML the hash for the revoked item. In both instances, the message must originate from a source that has SECROLE_MANAGER role on the device.
Effective use of the revocation system requires that revocation message be pushed to the device over-the-air. This typically means that the Operator must implement a device management (DM) infrastructure on its network. This can be one of the standard DM systems that are supported by Windows Mobile devices, or a custom over-the-air DM system that can push a signed cpf file to the device and force it to be executed.
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 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.
- 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.
Certificate Management in Windows Mobile Devices
Certificate Management and Application Signing for Application Developers