Export (0) Print
Expand All
Expand Minimize
4 out of 9 rated this helpful - Rate this topic

Understanding the Windows Mobile Security Model

Published: January 10, 2007

By Jim Wilson, JW Hedgehog, Inc., Microsoft MVP

See other Security MVP Article of the Month columns.

Applies to:

  • Microsoft .NET Compact Framework

  • Windows Mobile 5.0

  • Microsoft Visual Studio 2005


When we think about Windows operating system security, often the first aspects to come to mind are patch management, user authentication and user permissions, using measures like access control lists (ACLs). Although very familiar, because of the distinctly different usage model of Windows Mobile devices, these concepts based on users, user permissions, and user serviceability do not apply very well to the world of mobile devices.

There are a couple of key differences that make this the case. The most obvious is that Windows Mobile devices do not have a logon concept, and therefore there isn’t a concept of the current user. Mobile devices are generally considered personal productivity tools, not something that one logs on to like a workstation. Even if there were a concept of user identity, the overhead of maintaining per-item permissions through ACLs would put a tremendous strain on the limited resources of these devices.

One factor that affects the security architecture of Windows Mobile devices, possibly more so then any other, is that unlike a workstation or portable computer, in most cases the device that someone uses is probably not maintained or owned by an employer. Instead, individuals or organizations purchase or lease mobile devices such as Windows Mobile powered Smartphones or Windows Mobile powered Pocket PC Phone Edition devices from a network service provider such as Cingular, Sprint, T-Mobile, or Verizon. One of the most important concerns of these service providers is protecting their networks. They want to be sure that neither you nor anyone else installs or runs something on a device that threatens the security and integrity of the service provider’s network. As a result, the service provider is normally the one who sets the device security policy.

Note: Some very large organizations make arrangements with service providers to introduce organization-specific security policies. In some cases you may also be able to purchase what is known as an unlocked device, which allows you to set the security policy for that device. These situations are in the minority. As you’ll see, even in these special cases, the Windows Mobile security model continues to work well.

The fact that a service provider determines the device security policy rather than the organization using the device presents very different challenges from the familiar workstation and portable computer environment. As you’ll see shortly, making Windows Mobile a secure platform is achieved through a combination of operating system features, developer tools, and trusted third parties enforcing standardized security polices across organizations.


Like any other security model, Windows Mobile software does have a concept of permissions. We’ve already established that tracking per-item permissions is too resource intensive for mobile devices; instead, a much simpler model of three permission tiers is used: privileged, normal, and blocked. As shown in figure 1, each permission tier is more restrictive then the tier above. These permissions are granted per application.

Figure 1

Figure 1. Windows Mobile permission tiers

As you might expect, applications running at the privileged tier can do anything. They can call any API, can write to anywhere in the registry, can write to anywhere in the file system, and can install certificates. Very few applications should need to run as privileged.

Most applications run at the normal tier. These applications cannot call any trusted APIs, write to protected areas of the registry, write to system files, or install certificates. The complete list of trusted APIs, protected registry areas, and file system protections is available in the Windows CE Platform documentation. As you review the list, the need for preventing most applications from accessing these features becomes obvious. Basically, allowing applications to access these features gives applications the ability to modify the operating system environment and can threaten the device’s integrity.

The last permission tier, blocked, is provided primarily for completeness. No application executes at the blocked tier because the blocked tier applies to those applications that are not allowed to execute.

Certificates and Authentication

As mentioned in the introduction to this article, Windows Mobile software has no concept of user logon and therefore no concept of user authentication. There is however a concept of application authentication. Like many other situations requiring authentication of an item’s source, Windows Mobile software uses certificates. The certificate you use to sign your application determines the application’s privilege.

Just like the Windows XP operating system, Windows Mobile software has a number of certificate stores. Two of the Windows Mobile certificate stores are specifically used to determine an application’s permissions. These two stores are known as the privileged and normal certificate stores. Just as you expect, when you sign an application with a certificate from the privileged store, that application runs with privileged permissions; when you sign an application with a certificate from the normal store, that application runs with normal permissions.

Note: For more information on certificates, certificate stores, and certificate management on Windows Mobile devices, take a look at Certificate Management in Windows Mobile-based Devices.

There is one complication. In most cases, you cannot control the list of certificates in the privileged and normal certificate stores. The service provider for the Windows Mobile device controls the certificates in each certificate store. As with all certificates, the private part of the certificates associated with certificates in the certificate store must be closely controlled. This, of course, prevents most developers from being able to sign their applications with certificates found in the Windows Mobile device’s certificate store.

For your application to run with the appropriate privilege level, you must cooperate with an organization that has the ability to sign your application with one of the certificates in either the device’s privileged or normal certificate store. Many of the service providers have developer programs that you can join to help you to install your applications on their devices. Within these programs, once you meet the legal and fee requirements of the developer program, you can have the application signed with the service provider’s certificate.

Signing your application with a particular service provider’s certificate works well if your application is targeting only devices from that service provider. However, in many situations you want your application to run across the widest range of devices possible, which would require you to work with several service providers to have a copy of your application signed with each provider’s certificate. You would then have to manage multiple signed copies of your application and also ensure that each device that runs your application has the version signed with the appropriate service provider’s certificate. This solution is complex and can be expensive because you’ll most likely have to pay a fee each time a service provider signs your application with its certificate.

To avoid the complexity and expense of working with multiple service providers, Microsoft provides the Mobile2Market program. The Mobile2Market program provides a number of services to Windows Mobile developers; most relevant to this article, Mobile2Market provides certificates that almost all service providers include in the devices they sell. Both normal and privileged certificates are available.

Note: At the time of this writing, I am aware of only two service providers that do not include both the normal and privileged certificates on their devices. Orange provides only the Mobile2Market normal privilege certificate. You must work with Orange directly to have your application signed with a privileged certificate. The other exception is South Korea Telecom, which does not include either Mobile2Market certificates on its devices. Again, you will have to work with the company directly to have your applications signed.

The process of signing an application with one of the Mobile2Market certificates is straightforward:

  1. You start by working with one of the trusted certificate authorities that are part of the Mobile2Market program: GeoTrust and Verisign at the time of this writing.

  2. You purchase a certificate from the certificate authority. This certificate is not one of the Mobile2Market certificates but rather a certificate issued to your organization to identify your applications to the certificate authority.

  3. When you’re ready to distribute your application, you sign the application with your organization’s certificate identifying your organization as the publisher of the application.

  4. You send the publisher-signed application to the certificate authority. The certificate authority verifies the publisher signature on the application.

  5. The certificate authority then replaces the publisher signature with the signature of the appropriate Mobile2Market certificate. The Mobile2Market-signed application can now be distributed and run on the vast majority of Windows Mobile devices.

From a technical perspective, there is no difference in the process to sign an application using a normal or privileged certificate. What changes is the legal agreement that your organization enters into. If you find that your application must call one of the trusted APIs, access a privileged part of the registry, or access a privileged part of the file system, your organization must be preauthorized by Microsoft before a certificate authority can sign your application with a privileged certificate. As part of the preauthorization you will need to legally assert that your application conforms to the Microsoft Privileged Certificate Technology Requirements.

Note: As mentioned earlier in this paper, the complete list of trusted APIs, protected registry areas, and file system protections is available in the Windows CE Platform documentation.

For more information on the application signing process see the Verisign Authenticated Content Signing for Microsoft Windows Mobile and the GeoTrust Code Signing Credentials for Windows Mobile web pages.

Security Policy

The security policy of a particular device determines just how that particular device handles the issues of application signatures and permissions.

The first part of the security policy is the device security tiers; devices can have one-tier or two-tier security. A device with one-tier security focuses only on whether an application is signed; there is no concept of permission restrictions in one-tier security. Under one-tier security, any running application can call any API, modify any part of the file system and modify any part of the registry. One-tier security only restricts application startup. Signed applications can execute with no further checks; unsigned applications require further policy checks to determine if they can run.

Two-tier security restricts both application startup and application run-time permissions. On a device with two-tier security, signed applications can execute with no further checks, unsigned applications require further policy checks to determine if they can run. At run-time, two-tier security restricts an application’s access to the APIs, registry, and file system based on the permissions associated with the certificate the application is signed with. Applications signed with a certificate from the privilege certificate store execute with privileged permissions, all other applications run with normal permissions.

The next two parts of the security policy are closely tied together: whether unsigned applications can execute and whether the user should be prompted before the unsigned application executes.

Together, these three security settings (one-tier/two-tier security, can unsigned applications execute, prompt user before executing unsigned code) create four common security policies:

  • Security off

  • One-tier prompt

  • Two-tier prompt

  • Mobile2Market locked

The security off policy is pretty obvious. Unsigned applications are allowed to run without prompting the user. The security off policy is a one-tier policy, but that doesn’t really matter. Signed applications can execute with no further security checks; unsigned applications can execute without prompting the user. Once executing, any applications can call any API, and modify any part of the registry and file system. The security off policy is the default configuration of the Microsoft Device Emulator. The security off policy makes application testing and demos easy, but it is not a safe policy to have on an actual device. A device configured with the security off policy is extremely venerable because the device can install malicious applications without your knowledge and those applications have unrestricted access to the device.

The one-tier prompt security policy allows signed applications to execute; the device prompts the user before executing unsigned applications. Once an application is executing, it has no restriction on permissions. This is true for both signed and unsigned applications. To my knowledge, all devices running Windows Mobile 5.0 for Pocket PCs and Windows Mobile 5.0 for Pocket PC Phone Edition use this security policy. Verizon Smartphones also use this security policy.

The two-tier prompt security policy allows signed applications 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 certificate store have unrestricted access to the device. Applications signed with a certificate from the normal certificate store run with normal permissions and cannot access privileged APIs, or protected areas of the registry and file system. If the user allows an unsigned application to execute, the application executes with normal permissions. With only a few exceptions, Windows Mobile powered Smartphones use the two-tier security policy. You’ll find the Smartphones that I’m aware of that don’t use this policy listed with the other security policies discussed in this section.

The final security policy is the Mobile2Market locked policy. Applications that are signed can execute; users are not prompted to execute unsigned applications. These unsigned applications simply cannot execute. Once the application is executing, the permissions are determined by whether the application is signed with a certificate from the privileged certificate store or the normal certificate store. The Nextel i930 uses this policy. Smartphones from Orange and South Korea Telecom use variations of this policy. The only difference is the presence of the Mobile2Market certificates. As mentioned earlier in this paper, devices from Orange do not include the Mobile2Market privileged certificate and devices from South Korea Telecom do include any Mobile2Market certificates.

Security and Application Development

Now that we understand the components and effect of Windows Mobile security, we need to consider how it affects our application development. If you’re like most Windows Mobile developers, most of your application testing is performed using the Microsoft Device Emulator. As we just discussed, the fact that the emulator has security turned off makes testing applications very easy; unfortunately, with the security off, the emulator doesn’t reveal any security-related problems your application might have, which leaves your application open to unexpected failures when your application is deployed.

You could buy a bunch of different devices, with each having a different security policy, but that’s expensive and time consuming. A better choice is to configure the security policy on the emulator to reflect the devices your application targets; you may even want to configure the emulator in a number of different security policies to see how you application behaves when run under each policy. If you are uncertain as to the security configuration of a specific device, you can usually get this information from the device vendor’s developer program. The Security Policy section above is a pretty good guideline as to the security policy you should expect to find on the various devices.

The components of the security policy are configured by the registry, so you can modify the registry each time you want to test your application under another security policy. Ideally, you would have a program to modify these security policies for you. As luck would have it, Microsoft provides such a program in the Device Security Manager PowerToy. Figure 2 shows the Device Security Manager.

Figure 2

Figure 2. The Device Security Manager PowerToy

The Device Security Manager runs on your workstation and provides two essential services. First, the Device Security Manager displays the current security settings of the device or emulator currently connected to your workstation through Microsoft ActiveSync. The displayed information includes each of the device registry values that affect security policy and the list of certificates that are in each of the device certificate stores.

The Device Security Manager also allows you to configure the emulator or an unlocked device with one of the common security policies. To do this, you simply select the desired policy from the Selected Configuration field on the left and then click the Provision button. Figure 1 shows the Device Security Manager just after configuring the emulator to have a one-tier prompt security policy.

Using the Device Security Manager, you can take advantage of the ease of application testing with the emulator while ensuring that your application behaves as you expect under the different security policies.


The Windows Mobile security model provides a lightweight solution to enforcing application permissions while allowing individual service providers to determine the security policy of the devices on their networks. At the same time, the Mobile2Market program, in conjunction with trusted certificate authorities, allows application developers to successfully distribute their applications across the vast majority of Windows Mobile devices while working with a single certificate authority and maintaining a single signed version of their applications.

As a Windows Mobile developer, you should be sure to design your applications to be secure and frequently test your applications to confirm that your applications behave as expected with each security policy. The Device Security Manager simplifies testing across the various security policies by providing an easy way to configure the Microsoft Device Emulator with each of the different security policies.

Now that you have a basic understanding of Windows Mobile security and the tools necessary to test your applications with the various Windows Mobile security policies, you’re ready to start writing safer Windows Mobile applications that can be easily installed and run on almost every Windows Mobile device. For more information on building secure Windows Mobile applications, you should check out Security for Windows Mobile-based Devices in the Windows Mobile 5.0 SDK documentation. This documentation provides comprehensive coverage of the Windows Mobile security architecture and best practices.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
© 2014 Microsoft. All rights reserved.