Selecting Security Configuration

Send Feedback

The security policies and certificates installed in the device determine the security configuration of the device. The Operator typically determines the requirements for the security configuration. The most important consideration in this decision is the tradeoff between application compatibility and device security. The point chosen on this spectrum determines the rest of the security configuration.

The security model has many degrees of flexibility that can be used to configure the device in a very large number of ways. However, some of the security policy settings are interdependent, so it is possible to create a security configuration that is not self-consistent. Such configurations would not represent a coherent policy. The common security configurations are listed below. These security configurations cover the entire spectrum of the trade-off between application compatibility and device security.

Security-Off – Not Recommended

The Security-Off configuration implies that applications are not required to have digital signatures. In this case, it would be possible for an attacker to write a malicious application while hiding his identity. A rogue application will be able to install and run on the device without any visible indication to the user or to the operator. This is especially troublesome because Windows Mobile-based devices typically have instant-on data connections. A rogue application could spread very rapidly among the device population before being detected.

Because of these risks, Microsoft does not recommend the Security-off policy for any Windows Mobile-based device.

One-tier Prompt

Like Security-Off, the one-tier Prompt configuration also does not require applications to be signed. This means that an attacker could create a rogue application while hiding his identity. However, with the Prompt policy, the installation and/or execution of an unsigned application would be visible to the user and under his/her control. This would have the effect of slowing down the spread of the rogue application in the device population. And it would give the user the ability to protect him/herself by saying no. The security system is enabled as well, so it is possible to revoke the application to prevent further damage.

There are a number of software vendors who released applications for Windows Mobile-based Smartphone without signing them. Among the Windows Mobile-based Pocket PC compatible applications, the share of those that are unsigned is much larger. Since the user has the option to allow unsigned applications, the Prompt policy is favorable towards application compatibility and allows the user to take advantage of the largest variety of applications compatible with his/her device.

However, allowing applications from unknown and anonymous sources comes with an inherent risk. Once the application is allowed to execute, defending against malicious code becomes much more difficult, and the damage potential becomes much greater. Therefore, the Prompt policy should be configured only after a careful consideration of the trade-off between application compatibility requirements and device security.

Two-tier Prompt

In this configuration, unsigned applications are allowed to run with user interaction. With the Prompt policy, the installation and/or execution of an unsigned application would be visible to the user and under his/her control. If the user allows the application to run, the application runs normal, which means no access to protected registry keys and system APIs.

For an application to run privileged, the application must be signed with a certificate in the privileged certificate store. You can use the Mobile2Market program to get your application signed with a Mobile2Market Privileged certificate. For more information about the Mobile2Market Program see this Microsoft Web site.

3rd Party Signed

In this configuration, the security system is designed not to allow anonymous applications to run. For the application to run, the application must be signed with a certificate that chains to the root certificate of one of the Code Signing certificate authority (CA) that is installed in the privileged or normal certificates stores in the device. You can use the Mobile2Market program to get your application signed with a Mobile2Market certificate. The ISV's certificate is a strong code identity and ties the ISV's legal identity to the application. This creates some protection against rogue and intentionally malicious applications.

For more information about the Mobile2Market Program see this Microsoft Web site.

The most important enabler for a rogue application is the anonymous nature of code execution on most computing devices. An attacker can unleash a rogue application in a device population and be completely assured that his identity is not traceable. Mobile2Market removes this veil on anonymity. Certificate Authorities that participate in the Mobile2Market program verify the ISVs legal identity, through processes that are codified and audited. The certificate they issue to the ISV binds the ISV's legal identity. The signing process ensures that the identity is attached to the ISV's application. Thus, the ISV cannot deny responsibility for the actions of their applications.

The second enabler for rogue applications is the difficulty of collecting forensics that provide evidence of the intent to harm and the evidence of harm. The Mobile2Market program mitigates this problem by keeping track of signing activity, which provides evidence in the case of alleged wrong-doing.

Finally, ISVs that participate in Mobile2Market are contractually required to ensure that their applications do not modify the security policy on the device. The ISVs are also required to take full responsibility for the harm their applications may bring.

The verified legal identity, the contractual requirements, and the evidence of activity available in the signing program create a framework for enforceable security. This removes the veil of anonymity, enables forensic investigation, and creates an environment of legal accountability. This framework of enforceable security creates a strong deterrent against rogue applications.

Locked

Locked configuration implies that the device is out of reach for all third party applications.

Locked configuration is useful in settings where the device is not intended as a platform for third party applications. Such devices are designed to fulfill a specific function, and designed from hardware up to fulfill this function only. Examples are in industrial, vertically integrated settings where the device fulfils a business or work-flow function; appliances which operate in a standalone fashion with little or no general user interaction.

For settings where the device is intended as a personal communication device for consumers or business end-users, Locked configuration is not recommended. In such a setting, blocking third party application vendors severely reduces the value of the device to the user.

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.