Windows Mobile 5.0 Application Security

Jason Fuller
Microsoft Corporation

May 2005

Applies to:
   Windows Mobile version 5.0–based devices
   ActiveSync
   Visual Studio 2005
   Visual C#
   Visual Basic .NET

Summary: Every Windows Mobile–based device implements a set of security policies that determine whether an application is allowed to run and, if allowed, with what level of trust. To develop an application for a Windows Mobile–based device, you need to know what the security configuration of your device is. You also need to know how to sign your application with the appropriate certificate to allow the application to run (and to run with the needed level of trust). (9 printed pages)

Note This document describes the designed and intended functionality of the security model. This does not guarantee that a targeted malicious attack cannot compromise the intended security protections. The following security functionality is provided as is and is for informational purposes only. Microsoft makes no warranties, expressed, implied or statutory as to the performance of this functionality.

Contents

Glossary of Terms
Preparing a Device for Development
Deciding on the Type of Certificate to Sign an Application
Signing an Application During Day-to-Day Development
Signing a Cabinet File During Day-to-Day Development
Signing an Application or Cabinet File for Release to the Public
Testing How an Application Will Behave Under Different Security Configurations
Additional Tools

Glossary of Terms

The Windows Mobile documentation uses a set of security terms that have specific meanings, and understanding these terms will help you understand security on Windows Mobile devices.

Trusted and Normal

A trusted process can call any API and write to any registry key. There are essentially no limits on what it is allowed to do. A normal process is forbidden from calling certain APIs and writing to certain registry keys. For the list of APIs and registry keys, see the "Trusted APIs" topic in the Windows Mobile SDK documentation.

Normal execution mode is designed to reduce the amount of code that needs Trusted execution access to the device. By using Normal mode to run an application, you can reduce the risk that an error-prone application can cause accidental damage on the device. Using Normal mode can also reduce the likelihood that malicious or error-prone code misuses an application, and it can help minimize the damage that can result from security vulnerabilities in application code.

Although Normal execution mode is designed to reduce access to system and device resources, it should not be considered a primary method to contain the damage caused by malicious code that is written with the intention to do harm. Running code from untrustworthy sources comes with risk. The primary defense against malicious code is to not run it at all on the device. Windows Mobile devices implement code signing that can be used for this purpose.

Privileged, Unprivileged, and Unsigned

An privileged application is signed with a certificate that is in the privileged certificate store on the device. An unprivileged application is signed with a certificate that is in the unprivileged certificate store on the device. An application that is unsigned has no certificate.

Privileged certificate means a certificate that is in the privileged certificate store on a specific device. Note that there is nothing intrinsic to the certificate itself that is privileged. It is only the presence of the certificate in the privileged certificate store on a particular device that makes the certificate privileged.

Note that the terms trusted and normal refer to how an application runs, whereas privileged, unprivileged, and unsigned refer to how an application is signed. This is an important distinction; for example, it is entirely possible to have an unsigned application run trusted.

One-Tier and Two-Tier

A device that is one-tier is one where any process that runs, runs trusted. A device that is two-tier is one where a process runs either trusted or normal. On a two-tier device, only privileged applications run trusted.

Currently, Pocket PC only supports one-tier. Smartphone supports either one-tier or two-tier, but the vast majority of Smartphones are two-tier.

Mobile2Market

Mobile2Market is a program operated by Microsoft for independent software vendors that provides a unified market for applications for mobile devices. The code signing program within Mobile2Market is open to all application vendors for Windows Mobile devices, and it allows you to have your application signed with one of the Mobile2Market certificates. All Windows Mobile 2003 devices that currently ship contain the Mobile2Market unprivileged certificate, and that is likely to remain true of Windows Mobile 5.0 devices.

Most devices that currently ship also contain the Mobile2Market privileged certificate. As of May 2005, the only exceptions are devices sold by the following mobile operators: Orange UK and Verizon USA.

For more information about the Mobile2Market signing program and how to get your final application signed with a Mobile2Market certificate, see Mobile2Market Certification and Marketing Program.

Security Policy

A security policy is a key/value pair, where the key is simply a constant identifying the security policy, and the value is the policy decision. The header file secpol.h contains a set of SECPOLICY_* constants, which are the set of keys. For example, SECPOLICY_UNSIGNEDAPPS (4102) is the key for the "Can unsigned apps run?" policy, and the value is the policy decision: a value of 0 means unsigned applications cannot run, and a value of 1 means unsigned applications can run. There are two dozen security policies, but the four policies shown in Table 1 are the most important.

Table 1. Important security policies

Security Configuration

Together, the values of the four security policies in Table 1 define a security configuration. Windows Mobile has five standard security configurations, as shown in Table 2.

Table 2. Standard security configurations

For more information, see the "Selecting Security Configuration" topic in the SDK documentation.

Preparing a Device for Development

Locked or Third-Party-Signed Device

If you are using a physical device (that is, an emulator) that has the Locked or Third-Party-Signed configuration, the only applications that will run are those applications that have been signed with a certificate in one of the device's certificate stores. Moreover, the use of the certificates that are in the certificate stores is controlled completely by the OEM, the mobile operator, or Mobile2Market. Because these certificates are private (that is, their private keys are secret), you cannot use them to sign your application during day-to-day development. Instead, you need to install other certificates in the certificate store, and then sign your application with one of them. Microsoft ships a set of certificates (and private keys) in the Windows Mobile SDK for this purpose. You can find these certificates in the Tools directory and packaged in SdkCerts.cab.

The catch is that only trusted processes can install certificates. Therefore, the device manager (the OEM or mobile operator) must set up a developer program that you can use to install these certificates. The device manager can use many mechanisms; for example, a Web site that provides an executable file that installs the SDK certificates on your device. (This executable file will likely be keyed with the unique identifying number of your device, so it will not work on any other device.)

Two-Tier-Prompt Device

If your application needs to run trusted, you need to install the SDK certificates exactly as you would on a Locked or Third-Party-Signed device.

If your application does not need to run trusted, you do not need to install the SDK certificates because you can always respond affirmatively to the security prompts. However, to avoid the inconvenience of being prompted, you can install the SDK certificates exactly as you would on a Locked or Third-Party-Signed device.

Note that if you respond affirmatively to a prompt, you will not be prompted again for that module. But if you recompile, that recompiled module is considered a new module, and you will be prompted again.

One-Tier-Prompt Device

On a One-Tier-Prompt device, install the SDK certificates by running SdkCerts.cab on the device. You can find this file in the Tools directory of the SDK.

On Pocket PC, use ActiveSync to copy SdkCerts.cab to the device, and then open it in File Explorer. On Smartphone, use ActiveSync to copy it to \Windows\Start Menu\Accessories, navigate to Start\More\Accessories on the device, and then open the file.

Security-Off Device

On a Security-Off device, you do not need to install SdkCerts.cab. Note, however, that it is not recommended to use the Security-Off configuration, and it is unlikely there will be any retail devices that ship with this configuration.

Emulator

The SDK certificates are prebuilt into the emulator, so you do not need to install them yourself.

Deciding on the Type of Certificate to Sign an Application

After you install the SDK certificates on your device, you must decide how to sign your application: privileged, unprivileged, or unsigned. You will use the same type of certificate (that is, privileged or unprivileged) for your day-to-day development that you will use when you release your application. The only difference is that during development you will use an SDK certificate, and when you release, you will use a certificate controlled by Mobile2Market, an OEM, or a mobile operator.

Privileged

If your application needs to run trusted on a two-tier device, you need to sign your application with a privileged certificate. For day-to-day development, use SDKSamplePrivDeveloper.pfx. The advantage of signing with a privileged certificate is that your application can call any API, and there are essentially no security restrictions on what your application can do. (To see which APIs require you to run trusted, see the "Trusted APIs" topic in the SDK documentation.) The disadvantage of signing with a privileged certificate is that when you release your application, you have to ensure that your application is signed with a certificate that is in the privileged store of the real device.

Most Windows Mobile devices ship with the Mobile2Market privileged certificate. Your application will work on these devices if you sign it through the Privileged Signing program of Mobile2Market.

However, Smartphones on some mobile operator networks ship without the Mobile2Market privileged certificates. (As previously mentioned, these operators, as of May 2005, are Orange UK and Verizon USA.) On these devices, you have to ask the OEM or mobile operator to sign your application, and that organization may be very restrictive about what applications it is willing to sign.

Because of these requirements, if you want your application to run on all devices from all operators, you need to have different versions of your application that are each signed with a different certificate.

Unprivileged

Signing your application with an unprivileged certificate is the recommended default choice. For day-to-day development, use SDKSampleUnprivDeveloper.pfx. Most applications can run fine without needing to call any trusted APIs. All devices that currently ship have the Mobile2Market unprivileged certificate, and this is likely to remain true. (If a device did not have the Mobile2Market certificate, the OEM or mobile operator would need to sign your application.)

Unsigned

The advantage of an unsigned application is that it is the easiest to produce. You do not need to contact any third-party signing authority. The disadvantage is that the application runs only on a device that has one of the security configurations shown in the Table 3.

Note that as of May 2005, all Smartphone that currently ship use a Prompt configuration.

Table 3. Security configurations and their disadvantages

Special Considerations for Device Drivers and System Services

If you are writing a device driver (which loads into device.exe) or a system service (which loads into services.exe) that is loaded at boot time, your executable file must be signed privileged—regardless of the security configuration of the device. For example, on a one-tier Pocket PC where unprivileged applications run trusted, your executable must be signed privileged.

However, if your executable is loaded later in the boot process, for example, when the Startup folder is run, your application does not need to be signed privileged. So, to avoid the requirement of being privileged, you can, for example, put a small executable in the Startup folder that loads your device driver or service. (Device drivers can be loaded by means of the ActivateDeviceEx(), and services are loaded by means of RegisterService().)

Signing an Application During Day-to-Day Development

Visual Studio 2005 provides a UI that you can use to set up your application to be signed automatically as part of the build process.

To sign a C or C++ application

1. On the Project menu, click Properties.

2. Click Authenticode Signing.

3. For the Authenticode Signature property, click Yes.

4. For the Certificate property, click the Ellipses (…) button.

5. In the Select Certificate dialog box, do one of the following:

   • If the certificate you want appears in the list, select it, and then click OK.
   • If the certificate you want does not appear in the list, click Manage Certificates to open the Manage Certificates dialog box. Use this dialog box to import one of the SDK certificates (or import the certificate an OEM or mobile operator gave you as part of its developer program).

   Note Be sure to use the *.pfx file, not the *.cer file.

6. On the Authenticode Signing page, click OK.

To sign a C# or Visual Basic .NET application

1. In Solution Explorer, right-click the project, and then click Properties.

2. Click the Devices tab.

3. Select the Authenticode Signature check box.

4. Click Select Certificate.

5. Do one of the following:

   • In the Select Certificate dialog box, if the certificate you want appears in the list, select it, and then click OK.
   • If the certificate you want does not appear in the list, click Manage Certificates to open the Manage Certificates dialog box. Use this dialog box to import one of the SDK certificates (or import the certificate an OEM or mobile operator gave you as part of its developer program).

   Note Be sure to use the .pfx file, not the .cer file.

6. On the Authenticode Signing page, click OK.

Signing a Cabinet File During Day-to-Day Development

If you are not using a Visual Studio 2005 Smart Device Cab project and you are building your cabinet file through some other mechanism, you should follow this procedure to sign your cabinet file.

To sign you cabinet file if you build your cabinet file without using Visual Studio 2005

1. Make sure that the certificate you want to use is available in a pfx format file.

2. Sign the binary files that will go into your cabinet file. For example:

   Signtool sign /f SDKSampleUnprivDeveloper.pfx *.exe *.dll
   

3. Build your cabinet file with the signed binaries.

4. Sign your cabinet file with the correct certificate. For example:

   Signtool sign /f SDKSampleUnprivDeveloper.pfx myApp.cab
   

Signing an Application or Cabinet File for Release to the Public

The SDK certificates are for development or test purposes only. Users will never have SDK certificates installed on their devices. Therefore, when an application is ready to be released to users, it must be signed with a certificate that is on the user's device. All OEMs and mobile operators currently include the Mobile2Market unprivileged certificates on the devices they ship. Most OEMs and mobile operators also include the Mobile2Market privileged certificates. Therefore, unless your application needs to run on a device that does not have the Mobile2Market privileged certificate, you should have your application signed with one of the Mobile2Market certificates. For information about the Mobile2Market signing program, see Mobile2Market Certification and Marketing Program.

To run your application on a device that does not have the Mobile2Market privileged certificate, you need to ask the OEM or mobile operator to sign your application.

Testing How an Application Will Behave Under Different Security Configurations

After you have the SDK certificates on your device, you can change the security configuration of the device when you want. The Tools\SecurityConfiguration directory in the SDK contains a set of .cpf files (one per security configuration) and a readme.txt file with instructions about how to apply the files. Also, the Tools\RapiSecurity directory contains .cpf files that change the security policy for RAPI.

Additional Tools

The SDK ships with a sample application, called SecurityViewer, that queries the security configuration of the device. It runs on the device and displays the security configuration, the values of all the security policies, and all the certificates on the device. This application must run trusted, and so the Visual Studio solution file for this sample is set up to sign the application with the SDK privileged certificate.

To get the value of an individual security policy from your code, call the QueryPolicy() method in DevMgmt.h. Your code does not need to run trusted to call this method.

To get or set the security configuration of a device from the desktop computer, you can use rapiconfig.exe, which is in the Tools directory of the SDK. On the command line to Rapiconfig.exe, pass the name of an XML configuration file. You can use the files in the Tools\SecurityConfiguration directory as examples. Note that you must have sufficient permissions to get or set the security configuration, which means the RAPI security policy must already be set to Allowed. You can set this policy with Tools\RapiSecurity\RapiAllowed.cpf if the SDK certificates are on the device.

To get or set the security configuration of a device from your own code, you can call the DMProcessConfigXML() method in CfgMgrApi.h from C/C++ code, or Microsoft.WindowsMobile.Configuration from C# or Visual Basic .NET code. You can use the XML files in the Tools\SecurityConfiguration directory as examples of input to these APIs. Your code must run trusted.