Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
4/7/2010

Microsoft Corporation

February 2007

Summary

Become familiar with the concepts of authentication, permissions, and authorization. This HOL will also teach you to use several tools to understand how an application runs on different security configurations. This HOL will take 1 hour to complete. (18 printed pages)

Applies To

Microsoft Windows Mobile 5.0

Microsoft Visual Studio 2005

Device Security Manager

The following applications are required to run this HOL:

Introduction

Windows Mobile 5.0-based devices implement an application security model that is based on authentication. As an application developer who wants to target Windows Mobile-based devices, you need to understand the Windows Mobile application security model and the different policy options a mobile operator has when bringing a Windows Mobile-based device to market.

Lab 1: Understanding Security Using the Device Security Manager

This lab is performed using the device emulator that ships with Visual Studio 2005 to reduce complexity, save time, and protect your physical device from accidental provisioning. You may see references to a device, which simply refer to the emulator. You may also perform this lab on an actual Pocket PC or Smartphone device, provided it is not locked by the mobile operator or OEM.

Lab Objective

The objective of this lab is for you to understand the Windows Mobile security model and the different security configurations. You will also learn how to use several tools to see the configuration on a given device, sign a file, and check a file signature.

In this HOL, you will perform the following exercises:

  • Using the Device Security Manager to determine the security configuration of a device

  • Using the Device Security Manager to change the security configuration of a device

  • Provisioning the development certificates on a device

  • Signing a file with the development certificates

  • Provisioning a locked device

  • Learning More About Mobile2Market

Exercise 1: Using the Device Security Manager to Determine the Security Configuration of a Device

In this exercise, you will learn about the different security configurations on Windows Mobile-based devices, and you will also be able to determine the configuration on your device.

The Windows Mobile Application Security model implements a security-through-identity model that allows authenticated applications to execute on nearly all shipping devices. In other words, the device will trust a given application based on who signed the application (the issuer of the certificate that the application is signed with).

Windows Mobile-based devices have certificate stores that contain a set of certificates. There are three certificate stores on the device that define the trust level of your application: a privileged certificate store, a normal certificate store, and a Software Publisher Certificate (SPC) certificate store.

There are three levels of authentication: signed for privileged execution, signed for normal execution, and unsigned. The level of authentication that is required to run an application depends on the application programming interfaces (APIs) that the application uses.

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

Privileged certificate is 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.

The term authentication refers to how an application is signed. The execution permissions that an application receives are based on the security configuration on the device and the level of authentication of the application. The distinction between authentication and permission is important; for example, it is entirely possible to have an unsigned application run in privileged execution mode.

In this exercise, you will use the Device Security Manager tool to understand the most common security configurations.

To open the Device Security Manager

  • On the desktop computer, click Start| All Programs| Device Security Manager| Device Security Manager. The Device Security Manager application opens, and it should look like Figure 1.

    Figure 1. Device Security Manager

Notice the two main groups of information. On the left, there is a Selected Configuration group that shows you the security policies of the selected configuration. On the right, there is a similar group that shows the security policies of the connected device. The tabs at the bottom let you see the certificates on the selected configuration and the connected-device configuration.

To select a configuration

  1. In the Selected Configurationbox in the Device Security Manager, select the Security Offconfiguration. The security policies update to reflect the security policies for the selected configuration.

    The following are descriptions of each of the security policies:

    • Security Model

      The security model can be One Tieror Two Tier. In a two-tier security model, applications run with either privileged permissions or normal permissions. In a one-tier security model, applications always run in privileged mode. Both two-tier and one-tier models allow unsigned applications to be blocked from running.

    • Prompt

      The prompt policy can be Promptor No Prompt. If set to Prompt, the user will be prompted to decide if an unsigned .cab file should be allowed to deploy or not.

    • Unsigned CAB Role and Grant Manager Role

      If the unsigned CAB role policy is among the grant manager policy roles, unsigned .cabs will run with a Manager role. The managerrole usually has privileged mode execution permission.

    • Unsigned Applications

      The unsigned applications policy determines whether unsigned applications are allowed to execute or not.

    • RAPI

      The remote API (RAPI) policy can be Allowed(all RAPI calls are allowed), Disabled (no RAPI calls are allowed) or Restricted. For more information about RAPI restricted mode, see RAPI Restricted Mode Security .

  2. Click the Normal Storetab. This step shows the Normal Certificate Store certificates. An application signed with any of these certificates is able to execute in Normal Execution mode. Some of the certificates start with the (M2M)prefix. These are Mobile2Market certificates on the device. More information about Mobile2Market is provided in Exercise 6.

  3. Click the SPC Storetab. This step shows the SPC Certificate Store certificates. A .cab or .cpf file signed with any of these certificates is able to install on the device with privileged execution mode.

  4. Click the Privileged Storetab. This step shows the Privileged Certificate Store certificates. An application signed with any of these certificates is able to execute on the device with privileged execution mode.

  5. Change the selected configuration to Lockedand notice the certificates in privileged store are different that in the Security Offconfiguration. For example, the Locked configuration does not have Mobile2Market certificates in any of the configurations.

    If you look at the different configurations, you will notice the different security policies for each of the configurations. The following are descriptions of each of the standard configurations:

    • Locked or Mobile2Market Locked

      With a Locked 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 original equipment manufacturer (OEM), the mobile operator, or Mobile2Market.

    • Two-Tier-Prompt

      In a Two-Tier Prompt device, the only applications that will run with privileged execution mode are those that are signed with a certificate in the privileged store. Applications that are signed with a certificate in the normal store will run with normal mode execution. Applications that are unsigned will only be allowed to run if you respond affirmatively to the security prompt that appears when you try to run a given unsigned application. After you have allowed a given application to run by responding affirmatively to the prompt, the application will always run in normal execution mode.

    • One-Tier-Prompt

      On a One-Tier-Prompt device, applications can either execute in privileged mode or are not allowed to execute. If you try to run an unsigned application, you will be prompted to allow the application to run, and if you respond affirmatively, the application will run with privileged mode execution.

    • Security-Off Device

      On a Security-Off configuration, all applications will execute on privileged mode, even if they are unsigned.

Now you have an idea about the different standard security configurations, and you should understand the different security policies.

Exercise 2: Using the Device Security Manager to Change the Security Configuration of a Device

In this exercise, you will learn how to determine a device's current security configuration and how to provision it with different security configurations. You may find it useful to provision your device with different security configurations, so you can understand how your application will run on each of the security configurations.

To determine a device's security configuration

  1. If Device Security Manager is not currently running it, open it by clicking Start| All Programs| Device Security Manager| Device Security Manager.

    You will now connect the device emulator to ActiveSync to change its configuration.

  2. On the desktop computer, open Visual Studio 2005.

  3. In Visual Studio, click Tools| Device Emulator Manager.

  4. In the Device Emulator Manager, right-click Windows Mobile 5.0 Smartphone Emulator, and then select Connect. The emulator opens.

  5. Wait until the emulator shows the Todayscreen.

  6. In the Device Emulator Manager, right-click Windows Mobile 5.0 Smartphone Emulator, and then select Cradle. This step creates an ActiveSync connection with the emulator.

  7. Dismiss the ActiveSync message that appears by clicking OK.

  8. Dismiss the Synchronization Setup Wizarddialog box that appears by clicking Cancel.

    After you have established an ActiveSync connection, Device Security Manager detects your connected device. The Connected Device Configuration gets populated with data about your device. To understand what each of the security policies mean, see Exercise 1.

Because you connected to the Smartphone emulator, it has a two-tier security configuration. To change the security configuration by using the Device Security Manager, you will change its configuration to a One-Tier Prompt security configuration.

To provision your device with a different security configuration

  1. While your emulator is connected, select One-Tier Promptas your selected configuration.

  2. In the middle of the Device Security Manager, click the Provisionbutton.

    The first time Device Security Manager attempts to provision your emulator, it deploys a .cab file that needs to execute in privileged mode. However, the .cab file is not signed. Therefore, in some security configurations, you may need to respond affirmatively to a prompt on your emulator for the .cab file to execute in privileged mode.

  3. Notice that the status bar message changes to inform you that the device is being provisioned with the selected configuration. If your device cannot be provisioned because it is either Locked, Mobile2Market Locked, or Two-Tier Prompt, you may not be able to provision your device.

  4. If your device is properly provisioned, you will see a message that indicates that the device is provisioned. Click OKto close the message.

    Note:
    In the case of the Windows Mobile 5.0 Smartphone Emulator, you should also click Doneon the device emulator.

  5. Notice that the security policies change to match the configuration that you provisioned.

Exercise 3: Provisioning the Development Certificates on a Device

In this exercise, you will be introduced to the SDK certificates, why they are important, and how you can provision your device with them.

Depending on the device's standard configuration, you need to prepare your device for development. The following descriptions will help you understand how to prepare your device:

  • Locked or Mobile2Market Locked

    If you are using a physical device that has the Locked or Mobile2Market Locked 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 certificates that are in the certificate stores is controlled 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 corresponding private keys in the Windows Mobile 5.0 SDK for this purpose. You can find these certificates in the SDK Tools directory packaged in SdkCerts.cab.

    One caveat is that only privileged processes can install certificates. Therefore, the OEM or mobile operator must offer a developer program that you can use to install these certificates or to allow you to change the configuration of the device. The OEM or mobile operator can do so in several ways; 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

    If your application needs to run in privileged mode, 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 in privileged mode, 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, the recompiled module is considered a new module, and you will be prompted again.

  • One-Tier-Prompt

    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, you can 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, browse to Start Menu\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 there will not 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.

    Even though the emulator already has the SDK certificates by default, they will be removed when you provision it with one of the standard configurations from Device Security Manager.

To provision development certificates by using the Device Security Manager

  1. Be sure the Smartphone emulator is connected to ActiveSync and is detected by the Device Security Manager.

    Note:
    If it is not connected, follow the steps in Exercise 2 to connect it.

  2. Click the Privileged Storetab.

  3. If you provisioned the Smartphone emulator with the One-Tier-Promptconfiguration as described in Exercise 2, you will notice that there is no certificate called "TEST USE ONLY – Sample Privileged Root for Windows Mobile SDK."

  4. On the Device Menu, click Add Development Certificates.

  5. Notice the status bar is updated to describe that the device is being provisioned. Wait for the SDK certificates to be added to your emulator.

  6. If provisioned successfully, you will see a message that indicates that the device was provisioned successfully. Click OKto dismiss the message.

  7. Notice that some certificates were added to the certificate stores. For example, in the Privileged Store of your connected device, you should be able to see the "TEST USE ONLY – Sample Privileged Root for Windows Mobile SDK" certificate.

 To provision with one of the standard configurations

  1. Follow the steps in the "To provision your device with a different security configuration" procedure in Exercise 2. Provision your device with the One-Tier-Prompt configuration.

  2. Verify that you do not see any certificates that start with TEST USE ONLYin the certificate stores of the connected emulator.

 To provision development certificates by using SdkCerts.Cab

  1. Be sure the Smartphone emulator is connected to ActiveSync and is detected by the Device Security Manager.

    Note:
    If it is not connected, follow the steps in Exercise 2 to connect it.

  2. On your desktop computer, browse to the tools directory of the Windows Mobile 5.0 SDK (that is, C:\Program Files\Windows CE Tools\wce500\Windows Mobile 5.0 Pocket PC SDK\Tools).

  3. Right-click the SdkCerts.cabfile, and then click Copy.

  4. In Microsoft ActiveSync, click Explore.

  5. In the Mobile Device Explorer window, double-click My Windows Mobile-Based Device, and then navigate to Windows\Start Menu\Accessories.

  6. Right-click in an empty part of the explorer window, and then click Paste.

  7. On the File Conversionmessage, click OK.

  8. After the file is copied, close the device and the local desktop computer's explorer windows.

  9. On the Smartphone emulator, click the left soft key (under the Start menu).

  10. Click the soft key again (under More), and then use the direction keys to select Accessories, and then click the Action key, which is in the center of the navigational pad.

  11. Use the direction keys to move to SdkCerts.cab, and then click the Action key to open the file.

  12. Be sure to respond affirmatively to the message on the device.

  13. After the installation is complete, click the soft key under Done.

  14. In Device Security Manager, press F5 to refresh the connected device configuration.

  15. Notice that some certificates were added to the certificate stores. For example, in the Privileged Store of your connected device, you should be able to see the TEST USE ONLY – Sample Privileged Root for Windows Mobile SDKcertificate.

Exercise 4: Signing a File with the Development Certificates

In this exercise, you will learn how to sign a file with the development certificates by using several different tools.

To add the development certificates to your desktop computer's certificate store

  1. Click Start| Run.

  2. Type C:\Program Files\Windows CE Tools\wce500\Windows Mobile 5.0 Pocket PC SDK\Tools\sdksamplePrivDeveloper.pfx, and then click OK. The Certificate Import Wizardshould appear.

  3. Click Next. The path to the certificate should be filled in for the File name.

  4. Click Next.

  5. Click Next(you do not need a password).

  6. Click Next. You should leave the selected default options as they are.

  7. Click Finish.

  8. In the Security Warningmessage, click Yes.

  9. In the Certificate Import Wizardsuccess message, click OK.

  10. Repeat steps 1 to 11 for SDKSampleUnPrivDeveloper.pfx.

 To sign an application by using the Device Security Manager

  1. Start Device Security Manager if it is not already running.

  2. Click File| Sign File.

  3. Choose whether you would like to sign with the Privileged or Normal Development certificate.

  4. Select a file to sign. You can sign the ToSign.exe file, which is located at C:\Program Files\Windows Mobile Developer Samples\HOLs\HOL313_WM_Device_Security\Unsigned. Click Open and wait for the file to be signed.

 To check the certificate of a file

  1. On the desktop computer, open Windows Explorer.

  2. Browse to the file of interest. In this case, you can verify that the ToSign.exe file was properly signed. Browse to C:\Program Files\Windows Mobile Developer Samples\HOLs\HOL313_WM_Device_Security\Unsigned.

  3. Right-click ToSign.exe, and then click Properties. The File Properties dialog box appears.

  4. Click the Digital Signaturestab. You should see the certificate that the file is signed with, as shown in Figure 2.

    Figure 2. The certificate of a file in the File Properties dialog box

  5. You can also check the signature on a file in the Device Security Manager by clicking File| Check File Signature.

Visual Studio allows you to sign your projects as part of the build process.

To sign a native application from a Visual Studio 2005 project

  1. Start Visual Studio 2005 if it is not already running.

  2. Click File| Open| Project/Solution.

  3. Open the solution called HelloWorld.sln, which is located at C:\Program Files\Windows Mobile Developer Samples\HOLs\HOL313_WM_Device_Security\HelloWorld. This solution contains two projects. A managed project called ManagedHelloWorld and a native project called NativeHelloWorld.

  4. In Solution Explorer, right-click the NativeHelloWorldproject.

  5. Click Properties.

  6. Under Configuration Properties, select Authenticode Signing. A form should appear similar to the one in Figure 3.

    Figure 3. The Authenticode Signing form

  7. In the Authenticode Signaturebox, select Yes.

  8. In the Certificatebox, click the ellipsis button. A dialog box appears that lets you select from the certificates installed on your desktop computer for which you have a private key. Because you have installed the SDK certificates, you should be able to pick from a set of certificates that start with TEST USE ONLY.

  9. Select the unprivileged SDK certificate, which has the issuer name of TEST USE ONLY – Sample Unprivileged Root for Windows Mobile SDK.

  10. Click OKto confirm the selection.

  11. On the project's Propertiesdialog box, click OK.

  12. In Visual Studio, click Build| Build Solution. This step produces the NativeHelloWorld.exe file, and it will be signed with the privileged development certificate.

  13. Verify that the file has been signed by doing the "To check the certificate of a file" procedure.

 To sign a managed application from a Visual Studio 2005 project

  1. In Solution Explorer, in Visual Studio 2005, right-click the ManagedHelloWorldproject.

  2. Click Properties.

  3. Click the Devicestab to Authenticode sign your application, as shown in Figure 4.

    Note:
    Do not click the Signingtab. The Signing tab refers to strong naming (specific to managed code), but the Devicestab allows you to Authenticode sign.

    Figure 4. The Devices tab

  4. Select Sign the project output with this certificate.

  5. Click the Select Certificatebutton. The certificate selection dialog box appears.

  6. Select the unprivileged certificate (the issuer is TEST USE ONLY – Sample Unprivileged Root for Windows Mobile SDK).

  7. Click OKto confirm the selection.

  8. Close the project's Propertiesdialog box.

  9. In Visual Studio, click Build| Build Solution. This step opens ManagedHelloWorld.exe, and it will be signed with the privileged development certificate.

  10. Verify that the file has been signed by doing the "To check the certificate of a file" procedure.

    Because all you are doing in the Hello World application is showing a message, we needed to sign it with the normal SDK certificate. If you had used an API that required privileged access, you should have signed with it with the privileged SDK certificate.

    For more information about which APIs require privileged mode execution, see Trusted APIs .

 To sign an application without using Visual Studio 2005

  • There will be some situations where you might not be building from the Visual Studio UI. In such cases, you can use the command-line tool called SignTool.exe .

Exercise 5: Provisioning a Locked Device

There are some situations when your device may be Mobile2Market Locked or Locked, and it may not have the SDK certificates for development. In this exercise, you will lock the Smartphone emulator to see what would happen if you tried to change the configuration of a locked device by using the Device Security Manager.

To lock your emulator and try to provision it

  1. Be sure the Smartphone emulator is connected to ActiveSync and is detected by the Device Security Manager.

    Note:
    If it is not connected, follow the steps in Exercise 2 to connect it.

  2. Provision your emulator with the Locked configuration by following the "To provision your device with a different security configuration" procedure in Exercise 2.

    Next, you will remove the Configuration Manager Tool certificate from the emulator. This certificate is not found on locked devices.

  3. Browse to C:\Program Files\Windows Mobile Developer Samples\HOLs\HOL313_WM_Device_Security on your desktop computer.

  4. Use ActiveSync to copy RemoveToolCert.cabto the \Windows\Start Menu\Accessories folder on your emulator.

  5. On the emulator browse to Start Menu\Accessories, and then open the RemoveToolCert file.

    Note:
    For more information about copying a file to the device emulator and opening a file on the emulator, see the "To provision development certificates by using SdkCerts.Cab" procedure in Exercise 3.

  6. Be sure to respond affirmatively to any prompt on your device.

  7. From Device Security Manager, press F5 to refresh the connected device configuration. The Configuration Manager Tool certificate should not be in any of the certificate stores.

  8. Click Provision. A dialog box that explains that it is not possible for you to provision your device using Device Security Manager should appear. At this point, you know that you should contact your mobile operator to inquire about their development program.

  9. Close the message.

Exercise 6: Learning More About Mobile2Market

Mobile2Market is a program that Microsoft operates for independent software vendors and that provides a unified market for mobile applications. The Mobile2Market code signing program is open to all Windows Mobile application vendors—large or small. It enables you to sign your application with the Mobile2Market certificates that are shipped on almost 100 percent of the Windows Mobile devices that are sold. Using Mobile2Market's certificate ensures that your application will be able to meet the security requirements of almost every device on the market today. Signing up to use Mobile2Market is a simple process.

To sign up to use Mobile2Market

  • Establish an account with a vendor that supports Mobile2Market. Currently there are two choices: Verisign and GeoTrust. Both vendors offer reliable, competitively priced packages to get your applications signed. For more information about the current pricing plans, see the following Web sites:

These vendors are also known as Certifying Authorities (CA). To establish an account with a CA, a brief background check will be conducted to confirm your identity. Usually, this background check includes verifying your phone number, company address, and Web site. After your account has been established, the CA issues you a USB key that allows you to sign executable files with a Mobile2Market public key. You upload signed files to an online tool on the CA's Web site, which gives your files a corresponding Mobile2Market private key. At this point, your signed files are ready for distribution. Each time you sign a file, a signing token is used. There is a cost associated with each token, so it is best to leave Mobile2Market signing until the end of your product development cycle.

Conclusion

In this lab, you performed the following exercises:

  • Using the Device Security Manager to determine the security configuration of a device

  • Using the Device Security Manager to change the security configuration of a device

  • Provisioning the development certificates on a device

  • Signing a file with the development certificates

  • Provisioning a locked device

  • Learning more about Mobile2Market

After you complete this lab, you should have a good idea about the Windows Mobile security model and should be know the following: how to determine what authentication level your applications should have, how to use the many different tools that are available to you to test your application's execution on different security configurations, and how to use the tools that are available to you to sign your applications during development.