Standard Security Configurations

4/8/2010

The Windows Mobile Device Security Model is flexible enough to allow you to combine security settings to create just about any security configuration. However, since many of the security settings in the security model are interdependent, it is possible to create configurations that contain contradictory and incompatible dependencies. For example, rights that are granted to users through a device configuration security setting might be blocked by rights that are associated with a remote access security setting. Such security configurations are not "self-consistent," and therefore cannot be used to enforce "coherent" security policies. Among the configurations that are self-consistent, four are known as the Standard Security Configurations because they cover the spectrum of trade-offs that exist between application compatibility and device security. The four standard security configurations are described in the following table.

The following list provides further details on each of the standard security configurations.

• Security-Off – Not Recommended
  In this configuration, applications are not required to be digitally signed to be installed and to run. This gives an attacker the opportunity to create an intentionally malicious application that conceals his identity. Such an application can install and run without any visible indication to users or mobile operators. This is especially troublesome when you consider that Windows Mobile powered devices normally have instant-on data connections, which give intentionally malicious applications the opportunity to activate quickly (in less time than it takes users to realize that an attack is taking place).

Because of these risks, it is recommended that you refrain from using the Security-off configuration.

• One-tier Prompt
  Like the Security-Off configuration, One-tier Prompt does not require that applications be digitally signed to be installed and to run. Again, this gives an attacker the opportunity to create an intentionally malicious application that conceals his identity, but this time, because of the Prompt policy, the installation and/or execution of an unsigned application is visible to Users, and is under their control. This slows the spread of intentionally malicious applications through the mobile device population; with security features now enabled, it is now possible to revoke the application, and prevent further damage.

A large number of software vendors have released unsigned applications for Windows Mobile Standard, and the number of such applications released for Windows Mobile Classic is even greater. Since users of mobile devices in this security configuration have the option of granting permissions to unsigned applications, they can run the largest variety of compatible applications. Another way of saying this is that the Prompt policy favors application compatibility over device security.

• Two-tier Prompt
  In this configuration, unsigned applications are allowed to run, but only with user interaction. With the Prompt policy, the installation and/or execution of an unsigned application is visible to users, and is under their control. If they grant it permission to run, it runs "Normal," which means it has no access to protected registry keys or system APIs. For an application to access protected registry keys and system APIs, it must run "Privileged," and for that, it must be signed with a certificate from the Privileged Certificate Store.

You can use the Mobile2Market program to digitally sign your application with a Privileged certificate.

• Mobile2Market Locked
  In this security configuration, unsigned applications are neither allowed to install nor run. To run, applications must be digitally signed with a certificate that "chains" to the Root Certificate of a Code Signing Certificate Authorities (CA), which must be installed in either the Privileged or the Normal certificates store. You can digitally sign your application with a certificate from the Mobile2Market program. Such certificates give Application Developers a "Strong Code Identity," which ties their Legal Identity to their applications. This approach creates a level of protection against the proliferation of intentionally malicious applications. For more information, see the Mobile2Market Certification and Marketing Program in the Mobile Developer Center on MSDN.

An important enabler for intentionally malicious applications is the anonymous nature of code execution. An attacker can unleash an intentionally malicious application into the mobile device population, and be completely assured that his identity is not traceable. The approach used by the Mobile2Market program removes this veil of anonymity. Certificate Authorities that participate in this program, authenticate Application Developer identity through processes that are audited and codified. Their certificates bind Application Developers to their Legal Identity, and the signing process binds that identity to the Application Developer's applications.

• Locked
  The Locked configuration removes mobile devices from the reach of all third party applications. In this security configuration, applications are neither allowed to install nor run. This is useful in situations where mobile devices are not intended to be used as a platform for third party applications. Such devices are designed from the ground up to fulfill one specific function. Examples are in industrial, vertically integrated settings, where mobile devices fulfill a business function. These mobile devices run appliances that operate in a standalone fashion, with little or no user interaction.

The Locked configuration is not recommended for use in environments where mobile devices are intended to be used for personal communication. In such a environments, blocking third-party applications from installing and running severely reduces the value of the device to users.

External Resources

• The Mobile2Market Program
  Contains information on the Mobile2Market certification program, including information on how to join.

See Also

Concepts

Security Configuration Management