ne topic you really need to understand when deploying Windows Mobile applications is security. Often, developers spend a lot of time developing and testing their applications on emulators. However, applications that are working perfectly on emulators often break mysteriously on real devices. A large part of this can be attributed to the lack of understanding of the security policies implemented on Windows Mobile devices.

In this article, you will learn about the security provisioning of Windows Mobile devices and how you can provision your own Windows Mobile device using the Device Security Manager (included with Visual Studio 2008). In addition, you’ll learn how to sign your application using a test certificate shipped with the Windows Mobile 6 SDKs.

Creating a Simple Application
Instead of explaining the various security tiers employed by Windows Mobile devices, this article will walk you through the creation of a simple application, deployment of the app on an emulator, and then explain the behaviors exhibited by the application.

First, launch Visual Studio 2008 and create a new Windows Mobile 6 Standard application project. Name it SecureApp. Populate the default Form1 with the controls shown in Figure 1.

Figure 1. Form1: A very simple application with a single menu item control.

Switch to the code-behind of Form1 and import the following namespace:

using Microsoft.Win32;

Code the Write Registry menu item as follows:

        private void menuItem1_Click(object sender, EventArgs e)        {            try            {                RegistryKey masterkey =                    Registry.LocalMachine.CreateSubKey(                    @"SystemMyAppPreferences");                if (masterkey == null)                    MessageBox.Show("Key not created!");                else                    MessageBox.Show("Key created!");            }            catch (Exception ex)            {                MessageBox.Show(ex.Message);            }        }

Essentially, you are trying to create a new key in the Registry of the target Windows Mobile device, in particular, in HKEY_LOCAL_MACHINESYSTEM. However, the following registry root keys and their sub keys are protected from normal applications:

Figure 2. Access Denied: Access is denied when attempting to create a new registry sub key in HKEY_LOCAL_MACHINESYSTEM.

• HKEY_LOCAL_MACHINEComm
• HKEY_LOCAL_MACHINEDrivers
• HKEY_LOCAL_MACHINEHARDWARE
• HKEY_LOCAL_MACHINEInit
• HKEY_LOCAL_MACHINEServices
• HKEY_LOCAL_MACHINESYSTEM
• HKEY_LOCAL_MACHINEWDMDrivers

To be able to write to the above registry keys, your application must be signed with a privileged certificate (this will be explained later).

The above code will attempt to create the registry key. If it fails, an exception will be caught and the error message displayed.

Press F5 to debug the application on a Windows Mobile 6 Standard Emulator. When you click the Write Registry menu item, you will realize that access is denied (see Figure 2).

Security Provisioning
To understand why the previous attempt to write to the registry fails, take a look in the Device Security Manager. In Visual Studio 2008, go to Tools?>Device Security Manager and launch it. Notice that the Windows Mobile 6 standard Emulator has the Custom security configuration.

Observe the various settings of the Custom security configuration. Basically, it means:

• The emulator uses a two-tier security configuration (more on this later).
• Users are not prompted when attempting to run unsigned applications. That means, unsigned application will be allowed to run.

Applications that are not signed will be allowed to run, but they run in Normal mode. In Normal mode, applications have access to most of the APIs, but access to privileged APIs will be denied. This article shows the list of privileged APIs in the Windows Mobile platform.

From this configuration, you can see that because your application has not been signed, it is allowed to run in Normal mode, and attempting to write to the registry (which is restricted) will thus be denied.

Now, select the Prompt One Tier security configuration in the Device Security Manager and click the Deploy to Device button to effect the change on the emulator (see Figure 3).

In the One-Tier Prompt security configuration:

• All unsigned application (or signed with a normal certificate) are always prompted before allowed to execute.
• When an application is allowed to execute, it runs in the Privileged Mode (that is, it can access all APIs).

Windows Mobile 6 Professional and Classic devices usually have this security configuration.

Figure 3. Prompt One Tier: Changing the security configuration of the emulator to Prompt One Tier.

Figure 4. One Tier Prompt: In the One Tier Prompt security configuration, applications that are allowed to execute run in privileged mode.

Rebuild the application and press F5 to deploy it onto the emulator again. You will now be prompted to allow the application to execute. Click Yes. When you now click the Write Registry menu item, the registry key will be created successfully (see Figure 4).

In the Device Security Manager, select the Prompt Two Tier security configuration and click the Deploy to Device button.

In the Prompt Two-Tier configuration:

• All unsigned application (or signed with a normal certificate) are always prompted before allowed to execute.
• Unsigned applications which are allowed to execute run in the Normal mode.
• Signed applications (signed with a normal certificate) run in the Normal Mode.
• Signed applications (signed with a privileged certificate) run in the Privileged Mode.

Windows Mobile 6 Standard devices usually have this security configuration.

Rebuild the SecureApp application and debug it by pressing F5 again. You will be prompted to run the application. Click Yes. When you now click the Write Registry menu item, you will be denied access again (see Figure 5).

Figure 5. Access Denied: Access to the registry is denied.

To summarize, there are four common security configurations for Windows Mobile:

• Security Off: Applications have access to all APIs on the device.
• Prompt One-Tier: Applications that are not signed are prompted before execution. Applications are either blocked or execute in Privileged mode (when granted permission by the user to execute).
• Prompt Two-Tier: Applications that are not signed are prompted before execution. Applications are either blocked, or execute in Normal mode or privileged mode depending on the certificates it has been signed with.
• Mobile2Market locked: Applications that are not signed will not be allowed to execute. Only applications signed with the Mobile2Market certificate (will be discussed in the next section) are allowed to execute. The mode they execute in (Normal or Privileged) depends on the certificates it has been signed with.

Certificate Management
In the real world, devices shipped with certificates installed by the service provider of your device. That means, if you need to deploy your applications on the device, you need to work with the service provider to sign your application so that your application can be trusted. This model works quite well if your application is targeting only a particular device. However, if you are deploying your application to a wide variety of devices, this is a nightmare?you have to work with the various service providers of the devices and get your applications signed.

To avoid this code signing nightmare, Microsoft releases the Mobile2Market program. Most devices include the Mobile2Market certificates, which mean that as long as your application is signed with the Mobile2Market certificate, your application will be able to run on any devices. The signing process goes like this:

1. Purchase a certificate from one of the certificate authorities (CA) that is a partner of the Mobile2Market program, for instance Verisign and GeoTrust.
2. A certificate will be issued to identify your organization.
3. When you are ready to deploy your application, sign your application with the certificate you obtained from the CA and send it to the CA.
4. The CA, upon verifying the publisher signature, will replace the publisher signature with the signature of the appropriate Mobile2Market certificate.
5. Your application is now Mobile2Market signed.

For development purposes, you can use the test certificates shipped with the Windows Mobile 6 SDKs. By default the Windows Mobile 6 SDKs ship with three test certificates for development use:

• Sample Privileged Root for Windows Mobile SDK (in Privileged Store)
• Failsafe Configuration Root for Windows Mobile SDK (in Privileged Store)
• Sample Unprivileged Root for Windows Mobile SDK (in Normal Store)

You can verify this by clicking the Certificate Management button in the Device Security Manager. Figure 6 shows that the Windows Mobile 6 Standard Emulator containing the three certificates.

If you want your application to execute in Privileged mode in the emulator, you need to sign your application using the Sample Privileged Root certificate. Likewise, applications signed with the Sample Unprivileged Root certificate will run in Normal mode in the emulator.

It is important to know that you should place the certificates in the appropriate stores on the device. If you place the unprivileged certificate in the Privileged store (the unprivileged certificate should instead be placed in the Standard store), applications signed with an unprivileged certificate will be executed in the privileged mode.

Figure 6. Three Certificates: The sample certificates shipped with the Windows Mobile emulators.

Figure 7. Sign the Project: Signing a project with a certificate.

Signing Your Application
Now let’s see how to sign the SecureApp application with one of the test certificates.

In Solution Explorer, right-click on the project name and select Properties. Select the Devices tab and check the Sign the project output with this certificate checkbox (see Figure 7).

Click the Select Certificate button and the Select Certificate dialog will be shown. Click the Manage Certificates button and click the Import… button. Next, in the Certificate Import Wizard dialog, click Next and then Browse…

Navigate to the following directory: C:Program FilesWindows Mobile 6 SDKToolsSecuritySDK Development Certificates. Be sure to select Personal Information Exchange (*.pfx;*.p12) for the file type and then select SamplePrivDeveloper.pfx (see Figure 8). Note that this is a privileged certificate.

Back in the Certificate Import Wizard dialog, click Next for the next three steps and then Finish. Click Close.

Figure 8. A Privileged Certificate: Select the Personal Information Exchange and then the file.

Figure 9. The Properties Window: After signing your application with a privileged certificate.

In the Select Certificate dialog, select the certificate you have just selected and click OK. The Properties window will now look like Figure 9.

Rebuild the SecureApp application and press F5 to deploy the application to the emulator again. This time, you will be able to write the registry key.

Signing with the CabSignTool.exe
The Windows Mobile 6 SDK ships with the CabSignTool utility that allows you to sign a CAB file (and all the files contained within it). Create a CAB file for the SecureApp application and then sign it with the CabSignTool.

Uncheck the Sign the project output with this certificate checkbox (see Figure 10) and rebuild the project.

Then, add a new Smart Device CAB Project to the current solution. In the File System tab, right-click on the Application Folder item and select Add?>Project Output…. Next, select the SecureApp application and click Primary output. Click OK.

Figure 10. Uncheck the Box: Do not sign the application within Visual Studio 2008.

Figure 11. The CAB File: Locate the CAB file generated by the project in the binDebug folder of the project.

Build the project. Locate the CAB file generated by the project in the binDebug folder of the project (see Figure 11).

Copy the CAB file into the emulator (via ActiveSync) and install it on the emulator. You will see the confirmation as shown in Figure 12. This is because the CAB file has not been signed yet.

Figure 12. Confirmed: Unsigned CAB files are prompted.

To sign the CAB file, first copy the following files into a folder, say C:Signing.

Launch the Visual Studio 2008 Command Prompt by selecting Start?&gtlPrograms?>Microsoft Visual Studio 2008?>Visual Studio Tools?>Visual Studio 2008 Command Prompt.

Issue the following command (see also Figure 13):

C:Signing>cabsigntool.exe SmartDeviceCab1.CAB SmartDeviceCab1.CAB -f SamplePrivDeveloper.pfx

Essentially, you are signing the CAB file and all the files contained within it.

Figure 13. Signing the CAB File: Signing the CAB file with the cabsigntool.

Figure 14. Privileged Mode: The application now runs in privileged mode.

Copy the CAB file into the emulator now and install the application. You will now be able to install the application without any prompting. Also, you will now be able to write a registry key without any problem (see Figure 14).

Emulator Testing Is Not Enough
Now that you’ve seen how the security configuration of Windows Mobile devices affects the running of your applications, you’ll agree that it’s always useful to test your application on real devices and not totally rely on emulators as they normally have security turned off.