Windows Mobile-based Device Security Model
Windows Mobile-based Pocket PCs and Smartphone comes with security features that help protect devices. In Windows Mobile 2003 Second Edition, only Windows Mobile-based Smartphones include a security model. In Windows Mobile 5.0, Windows Mobile-based Pocket PCs also include a security model. Windows Mobile-based Pocket PC and Pocket PC Phone Edition are available as one-tier devices. Windows Mobile-based Smartphones are available as one-tier and two-tier devices.
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 specific device settings. Control 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. |
You can achieve proportionate defense using security-through-identity, security roles, and secuirty policies.
One-tier vs. Two-tier Devices
The following table shows the two security configurations.
| Platform | One-tier | Two-tier |
|---|---|---|
| Windows Mobile 2003-based Smartphone | .gif) |
|
| Windows Mobile 5.0-based Smartphone | |
|
| Windows Mobile 2003-based Pocket PC | X | X |
| Windows Mobile 5.0-based Pocket PC | (NEW) |
X |
Legend
X = not supported
= supported
The one-tier device distinguishes between signed and unsigned applications. All signed applications run privileged on the device. Privileged applications can access every aspect of the device, including system APIs and protected registry keys. For more information about protected registry keys and system APIs, see Privileged APIs.
For unsigned applications 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 Windows Mobile-based Smartphone 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.
Privileged vs. Normal
Privileged and normal distinguishes what applications can do when the applications run.
Applications running normal cannot access protected registry keys and system APIs. Untrusted and unprivileged are the deprecated term for normal.
Applications running privileged can access all registry keys and all system APIs. Applications running privileged can also install certificates on the device. Privileged applications can switch to run kernel mode.
For more information about protected registry keys and system APIs, see Privileged APIs.
Revocation
Revocation is the process that allows an 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-based 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 ISV 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. You can use the revoke.exe tool available in the SDK to inspect or generate the appropriate hash. Use LoaderRevocation Configuration Service Provider 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-based 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.
See Also
Certificate Management in Windows Mobile-based Devices | Certificate Management and Application Signing for ISVs
Send Feedback on this topic to the authors