Compartilhar via

Windows Mobile Device Security Model

  • Artigo

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

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.

One-tier versus Two-tier 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.

  • 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.
    For more information about protected registry keys and system APIs for Windows Mobile 6.5 , see Privileged APIs.
  • Unsigned or signed with an unknown certificate
    Unsigned or incorrectly signed applications 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.

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.

Security Levels

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

Permissions

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

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.

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

See Also

Concepts

Certificate Management in Windows Mobile Devices
Certificate Management and Application Signing for Application Developers