A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers

Article
10/26/2006

James Pratt
Microsoft

February 2003

Applies to:
   Microsoft® Windows® Powered Smartphone 2002
   Windows Mobile™-based Smartphones
   Windows Mobile 2003 Second Edition software for Smartphones
   Microsoft ActiveSync®
   Microsoft Visual Studio® .NET 2003
   Microsoft eMbedded Visual C++® version 3.0
   Microsoft eMbedded Visual C++ version 4.0

Summary: Learn what an application developer must understand regarding the Smartphone Application Security model and the different policy options a mobile operator has when bringing a Windows Mobile-based Smartphone to market. (20 printed pages)

Abstract
Background to Application Security
   Digital Code Signing
   Why Have Digital Code Signing at All?
   Application Security on Windows Mobile Software for Smartphone
   When Do I Need Privileged Over Unprivileged Execution Mode?
   Privileged vs. Unprivileged Execution Modes
   What Are the Possible Security Policies?
Code Signing in Practice
   Configuration Steps Common to Smartphone 2002 and 2003
   Smartphone 2002 Specific Configuration Steps
   Smartphone 2003 Specific Configuration Steps
   Developing to Take Account of Privileged Access
   Signing Your Application for Deployment
Conclusion
Appendix A: Protected Registry Entries
Appendix B: List of Privileged APIs

Abstract

Windows Mobile™-based Smartphones implement an application security model based on digital code signing. An application developer who wants to target Windows Mobile-based Smartphones needs to understand the Smartphone Application Security model and the different policy options a mobile operator has when bringing a Windows Mobile-based Smartphone to market.

If you are a Smartphone developer with a knowledge of building Pocket PC or Smartphone applications and are also building Pocket PC and/or Smartphone installation (.cab) packages, this article should provide you with everything you need to know about the Smartphone Application Security model, the difference between privileged and unprivileged applications, how to determine if your application needs privileged trust, how to configure your development environment for Smartphone development, and how to sign your application through a code-signing vendor.

Background to Application Security

The Mobile2Market FAQ provides a good high-level guide to application security and code signing. You may want to read the Mobile2Market FAQ before you read this article to give you valuable context.

Digital Code Signing

Digital code signing is a way of authenticating the origins of digital content. In the Windows Mobile world, it is sometimes confused with logo certification. Logo certification is the process of obtaining validation that a Windows Mobile application meets a set of guidelines for the implementation of a Windows Mobile application. The current guidelines can be found at the Mobile2Market site. A certified application bears the "Designed for Windows Mobile" logo within the application and on its packaging. The "Designed for Windows Mobile" logo does not guarantee that an application is built by the software vendor it claims to be from, nor does it guarantee that if it is built by that software vendor, it has not been maliciously tampered with between the software vendor and you receiving it. Code signing, however, does provide these guarantees.

It is somewhat confusing that digital code signing uses a digital certificate and that there is a separate logo certification program. Both have quite different goals and objectives.

Why Have Digital Code Signing at All?

Digital code signing is not exclusive to Windows Mobile-based Smartphones. Every time Microsoft® Internet Explorer asks if you want to install an Microsoft Active X® control and then asks if you want to "trust content from Corporation X," the application is asking you to make a decision about whether you trust the content provider or not. Internet Explorer is asserting that the package in question hasn't changed since it was signed. If you trust the source, then you can trust the application because it comes from a verified source. Code signing is about verifying the origin of digital content and the fact that it hasn't changed since it was signed.

Application Security on Windows Mobile Software for Smartphone

Application security on the Windows Mobile-based Smartphone helps protect the integrity of the end-users' Smartphone device by not allowing the user to install applications from an unknown source.

Application security is a policy decision that is enforced through code signing. The mobile operator makes the policy decision before they bring a phone to market. The carrier can change the policy decision at any time.

Windows Mobile-based Smartphones implement both perimeter security and runtime security. Perimeter security controls can be installed on the device. Runtime security controls can be executed on the device. For example, you only need to install a ring tone or a home screen, whereas you need to both install and execute an application. If you are creating content to install on the device that does not contain any executable components, you only need to think about perimeter security. If you are creating something executable, such as an application or component, you need to think about perimeter and runtime security.

The Smartphone contains three different certificate stores: an unprivileged execution trust store, a privileged execution trust store, and an installation trust store. A certificate store contains the public portion of the digital certificates installed to the phone. The public version of a certificate can be used to verify the digital signature of an application, but it cannot be used to sign an application.

When Do I Need Privileged Over Unprivileged Execution Mode?

Most applications should need only unprivileged execution mode, for example games and personal productivity applications. If you plan to do any of the following in your application, you may need privileged execution mode that, hence, should be signed with a privileged certificate:

Modifying system registry entries (see Appendix A)
Accessing the SMS subsystem (SmsXXX functions)
Placing or intercepting phone calls and accessing other exTAPI APIs
Accessing the SIM management subsystem (SimXXX functions)
Directly accessing the radio through the Radio Interface Layer (not exposed through the Smartphone SDKs)
Using low level system APIs e.g. Kernel IOControl
Writing a component, such as a DLL, that is intended to plug into a system process or privileged process. A common example is a Microsoft ActiveSync® Service Provider as the device-side ActiveSync application is classified as a privileged application.

Note Appendix B contains a list of APIs that need privileged access.

Privileged vs. Unprivileged Execution Modes

The Smartphone Application Security model has been designed to be flexible to meet various mobile operator network requirements. The concept of privileged and unprivileged applications refers to the level of access to device features and APIs that are on the device by a given application:

Privileged trust applications have full access to the system and APIs. An application signed with a certificate in the privileged certificate store is run with this execution privilege.
Unprivileged trust applications have limited access to the system and APIs. An application signed with a certificate in the unprivileged certificate store is run with this execution privilege.
Untrusted applications are not permitted to load onto a Smartphone and have no access to the system or APIs.

The operator gets to choose the Smartphone security policy. This policy may allow untrusted applications to run with unprivileged access or may require that applications be digitally signed. The next section deals with the matrices of security policies.

What Are the Possible Security Policies?

For application installation (perimeter security), the operator's policy choice is simple:

Allow unsigned installation packages to install
Don't allow unsigned installation packages to install

In Smartphone 2003 there is an additional mode that asks the user if they want to install the application.

For application execution (runtime security), the mobile operator has to make the choice of whether to allow an application or component to run for both privileged and unprivileged trust. The following table shows, depending on the policy, the type of certificate you need to be signed with to run. In Smartphone 2002:

Policy	Execution mode	Execution mode
	Unprivileged	Privileged
Unrestricted	None	None
Standard	None	Operator privileged certificate required
Restricted	Mobile2Market unprivileged certificate required	Operator privileged certificate required

Windows Mobile-based Smartphones can also support prompt mode. Rather than simply deny the user the ability to install or run an application, an operator can defer the decision to the user by specifying prompt mode. In this case the user is prompted and asked whether to let an application run or install. The execution policies are now:

Policy	Execution mode	Execution mode
	Unprivileged	Privileged
Unrestricted	None	None
Standard	Mobile2Market unprivileged certificate required (also Prompt mode)	Mobile2Market or Operator privileged certificate required
Restricted	Mobile2Market unprivileged certificate required	Mobile2Market or Operator privileged certificate required

If you visit the Mobile2Market Build Applications page, you can find out the security policy decisions taken by popular mobile operators.

Code Signing in Practice

As a software developer, code signing affects you during the development of code and during the deployment of your application. During development, you need to be aware how to configure your emulator or device with certificates to allow development. When you want to deploy your application, you need to understand how to get your application digitally signed, which components need to be signed, and how to sign those components.

Before you begin developing Smartphone applications, you need to prepare your Smartphone device and development environment. For Smartphone 2002 you will learn how to configure Microsoft eMbedded Visual C++® version 3.0 and how to pick whether to use the privileged or unprivileged certificate for signing. For Smartphone 2003 you will learn how to configure both eMbedded Visual C++ 4.0 and Microsoft Visual Studio® .NET 2003 so that they both use the same set of certificates, which simplifies the development process.

Configuration Steps Common to Smartphone 2002 and 2003

For both Smartphone 2002 and Smartphone 2003, you need to use the command prompt from the SDK tools directory to perform some of the configuration steps. If you have installed the tools in the default location, the tools directory is:

Platform	Tools directory
Smartphone 2002	C:\Windows CE Tools\wce300\Smartphone 2002\tools
Smartphone 2003	C:\Program Files\Windows CE Tools\wce420\SMARTPHONE 2003\Tools

Open the command prompt and change directory to the tools directory by following these steps:

Click the Start menu and then click Run (or press the Windows logo key and R). The Run dialog opens.
Type cmd into the edit field, and then press the ENTER key. The command window opens.

Figure 1. Opening the command window

Change the directory to the platform-specific tools directory above. Type cd <tools path>, and then press the ENTER key.

Figure 2. Changing the directory to a platform-specific tools directory

Creating a Development Certificate

The Smartphone 2002 and 2003 SDKs ship with a tool called spdps, which is used to create a privileged developer certificate to sign the device-side development tools and provide that certificate to your Smartphone and Smartphone emulator. You should separately run the spdps command for both Smartphone 2002 and Smartphone 2003 to ensure that your emulator is configured with an appropriate certificate and that your debug tools are signed.

The spdps tool is installed into the tools directory of the SDK. Follow the previous steps to open the command prompt and change directory to the appropriate tools directory:

Platform	Tool name	Tools directory
Smartphone 2002	sp2002dps	C:\Windows CE Tools\wce300\Smartphone 2002\tools
Smartphone 2003	spdps	C:\Program Files\Windows CE Tools\wce420\SMARTPHONE 2003\Tools

Now run the tool indicated in the preceding table with the /create and /device parameter; for example, typing "sp2002dps /create /device" <ENTER> would run the tool for Smartphone 2002. You must have your device connected to your PC and an ActiveSync connection established before you issue this command.

Figure 3 shows what you can expect to see.

Figure 3. Pressing ENTER returns the result of the platform-specific tool

What we have done here is signed all of our device side development components, the remote tools, and debugger with a locally created certificate. These tools need privileged access to the device so we push the locally created certificate to the device's privileged execution trust store so that the device will allow the components to run as privileged processes.

Some mobile operators may choose a device configuration that does not support development out of the box. In this case, you will see the following error:

Figure 4. Choosing a device configuration that does not support development out of the box returns an error

If your phone does not support development out of the box, you need to contact your mobile operator to see if they offer a service to configure your phone so that you can develop for it. They may, for example, have a developer program on the Web that you can join and enable your phone for development.

If you develop on multiple phones, you can use the spdps /device command to push the development certificate to each phone. In this case, you only need to use the /device parameter.

Figure 5. Using one parameter

When you use the /device without the /create switch, the utility asks you to select a certificate.

Figure 6. Selecting a certificate

The "<username> Default Development Certificate" is created automatically when eVC targets a Smartphone device for the first time. The "Smartphone Privileged Development Certificate for <username>" is created by spdps /create. In this case we want to choose the "Smartphone Privileged Development Certificate for <username>" to push to the device. When the process is complete, you will see a success screen as before.

Don't forget, if you hard reset your phone or the battery runs completely dead, you will need to reconfigure your phone by repeating these steps.

Smartphone 2002 Specific Configuration Steps

For Smartphone 2002, you can only develop applications using eMbedded Visual C++ 3.0. By taking the steps previously mentioned, you created a known certificate in both the privileged and unprivileged certificate stores on your device. This will help you determine if your application needs privileged or unprivileged signing. This method focuses on configuring an actual Smartphone device over the emulator. The emulator ships with an open security policy that should enable you to develop any type of application. Because operators choose their own security policy, it's only when you come to target a device that — as a developer — you need to know which certificate you are using for signing.

Smartphone 2003 Specific Configuration Steps

There are two tools that you can use to develop applications for Smartphone 2003. The previous steps configured the device so that eMbedded Visual C++ 4.0 can deploy and debug applications to the device and emulator. The Smartphone 2003 SDK ships with a privileged and unprivileged development certificate. These certificates are already loaded into the emulator privileged and unprivileged certificate stores. The unprivileged certificate is used as the default certificates by Visual Studio .NET 2003. This section focuses on configuring your device to use those certificates so that you have a consistent set of certificates across all your tools and emulator.

Add the Test Certificates to Your Personal Certificate Store

First, you must add the certificates that ship in the SDK tools directory to the personal certificate store on your development PC. The certificate files are called TestCert_Privileged.pfx and TestCert_UnPrivileged.pfx. To install each certificate to your personal certificate store you need to:

Double click the .pfx file in Explorer.
Click Next.
Click Next again.
Click Next again – there is no password on the certificates.
Select "Automatically select cert store," and then click Next.
Click Finish.

Provision the Certificate to the Device

Once you have added the certificates to your personal certificate store, you need to add them to your device. Here you need to use the rapiconfig tool. The Smartphone 2003 SDK ships with a configuration file that adds these certificates to the appropriate device certificate stores. Open up the command prompt using the instructions given earlier and change to the SDK tools directory. Type:

rapiconfig /p sdktestcerts.xml <press enter>

You should see:

Figure 7. Using the rapiconfig tool to change directories

Configure Your eMbedded Visual C++ 4.0 Project

Your device now contains the SDK test certificates. The final step is to update your eMbedded Visual C++ 4.0 project so that it uses unprivileged test certificate for signing your application when it deploys it. In eMbedded Visual C++ 4.0:

Go to Project and then select Settings.
Scroll to the far right tab, which is Security (see the note in step 7).
Check ONLY the top check box (Sign This Application).
Press the upper Browse button.
Choose the certificate called "Smartphone 2003 Unprivileged Test Signing Authority" and then click OK.
Uncheck the "Configure device to trust signed applications" checkbox.

Note We have already provisioned the certificates into the stores we want them in; therefore, we do not want the tool to provision them again. By unchecking this box, we can prevent the wrong certificate going into the wrong store.
Click OK.

Note The Security tab is only present in Smartphone Projects. Ensure that the target platform in the main IDE is set to Smartphone and not Pocket PC. eMbedded Visual C++ 4.0 will sometimes select Pocket PC by default over Smartphone even if you create a Smartphone project.

Configuring Visual Studio .NET 2003

Visual Studio .NET 2003, by default, uses the certificates that ship with the Smartphone 2003 SDK. The steps that configure the device with the appropriate certificates are all that need to be completed to configure Visual Studio .NET 2003 to automatically sign applications with the unprivileged certificate.

If you determine that your Visual Studio .NET 2003 application needs privileged signing you will need to manually sign application components (.exes and .dlls) with the privileged test certificate called "Smartphone 2003 Privileged Test Signing Authority". You can do this using the signcode tool. Use of the signcode tool is described in the Signing Your Application for Deployment section.

Note This will enable you to run an application that requires privileged trust by starting the executable from the device. However, if you run or debug the application from the development environment, it will resign the application with the unprivileged certificate.

Developing to Take Account of Privileged Access

Accessing Privileged Registry Entries

You are able to open and navigate through privileged registry keys and values, but you are not able to create, modify, or delete keys or values. All the registry access functions return a LONG value. When you try to perform create, modify, or delete on a key requiring privileged access the return value will be ERROR_ACCESS_DENIED (0x05). Make sure to check those registry function return values and fail gracefully!

There is a list of privileged registry entries in Appendix A.

Calling Privileged APIs

If an API is failing in your application, it could be that you've called a privileged API and you are not running with privileged trust. In this situation the function call will fail. Each function has a different way of indicating that it has failed, usually indicated by some return value. This on its own is not sufficient to indicate that the call has failed because you need to be running with privileged trust.

If you suspect that a function call has failed because you need privileged trust you can call the GetLastError function. If the return value is 0x05 (ERROR_ACCESS_DENIED), this is an indicator that you may need to be running with privileged trust to use that function.

See the section that explains how to test empirically if your problem is caused by needing privileged signing.

There is a list of privileged APIs in Appendix B.

Writing DLLs and Other Components

It's common for an executable to load functionality from other executable components, for example DLLs. Usually this is in the form of loading a function at runtime or link time. Some of the standard Smartphone applications allow themselves to be extended by writing DLLs that implement specific functionality, for example ActiveSync, Inbox, and the Home Screen.

When a Smartphone executable tries to load another component, the system checks the privilege level of the executable. If it finds the component has a lower level of trust, it does not allow the component to load.

It is especially important to remember that almost all system executables run with privileged trust.

On Smartphone 2002, attempting to load an unprivileged component into a privileged process will fail quietly. For example, you might be trying to create an ActiveSync service provider. Although you have installed the components correctly on both a desktop and the device and, on the desktop side, the service provider appears in ActiveSync options, when you try to synchronize, no data is transferred because your component is never loaded on the device side. As a rule of thumb, any component that plugs into a system application will need to be signed with a privileged certificate.

On Smartphone 2003, the result of attempting to load an unprivileged component into a privileged process depends on the security policy. If the operator has allowed prompt mode, the user is prompted and asked to make the decision on whether or not to load the component. The user is asked:

This program needs a component from an unknown source that may not be trustworthy.
Do you want to load this component?

If the operator does not support prompt mode, the behavior is the same as Smartphone 2002.

How Do I Test Empirically If My Application or Component Is Failing Because It Needs Privileged Signing?

If you have followed the preceding configuration instructions, your development environments should be configured to automatically sign your applications with a known unprivileged certificate. If, having followed the configuration instructions and you believe that your application or component might need privileged signing, you can test this empirically by signing with a privileged certificate that you know is in the privileged store on your device. Assuming you have configured your environment using the preceding instructions, you can use some of the following steps to help identify security related failures.

eMbedded Visual C++ 3.0 and 4.0

For the eMbedded Visual C++ family, you need to change the certificate used to sign the application or component in the project settings. Depending on whether you are using eMbedded Visual C++ 3.0 or 4.0, you need to make slightly different selections.

Note Because the Smartphone 2002 emulator ships with an open security policy you cannot perform this test for Smartphone 2002 using the emulator.

eVC version	Certificate name
3.0	Smartphone Privileged Development Certificate for <username>
4.0	Smartphone 2003 Privileged Test Signing Authority

Go to Project and select Settings.
Scroll to the far right tab, which is Security (see the note in step 7).
Check only the upper check box (Sign This Application).
Press the upper Browse button.
Choose the certificate from the table above.
Uncheck the "Configure device to trust signed applications" checkbox.

Note We have already provisioned the certificates into the stores we want them in; therefore, we do not want the tool to provision them again. By unchecking this box, we can prevent the wrong certificate going into the wrong store.
Click OK.

Note The Security tab is only present in Smartphone Projects. Ensure that the target platform in the main IDE is set to Smartphone and not Pocket PC. eMbedded Visual C++ 4.0 will sometimes select Pocket PC by default over Smartphone, even if you create a Smartphone project.

If you now Rebuild All your application or component, it will be signed with a privileged certificate. If your application or component now begins to work as you expected it, your application needs privileged signing.

Visual Studio .NET 2003

Testing with Visual Studio .NET 2003 is a little different. In this case, you need to use the signcode tool to sign your components manually and then try to deploy them. There is a guide to using signcode in the Signing Your Application for Deployment section of this document. You need to choose the Smartphone 2003 Privileged Test Signing Authority certificate to sign your application or component. Remember that Visual Studio .NET 2003 ONLY supports Smartphone 2003.

Query Which Certificates Are in the Certificate Store on Your Smartphone

Both Smartphone 2003 and Smartphone 2002 SDKs ship with a tool called rapiconfig. rapiconfig allows you to query the certificate store on your phone. Both 2002 and 2003 SDKs ship with an example file called querystore.xml. You can use this document to ask the phone exactly what certificates it has in its privileged, unprivileged, and installation stores. You'll learn how to do this, including:

Create an appropriate .xml file for the privileged, unprivileged, and installation store.
Use rapiconfig to get the information from the phone.
Identify if your phone is locked for development.

Creating the Query Files

The template querystore.xml looks like this:

<!-- Sample XML to query a certificate store  -->
<wap-provisioningdoc>
   <characteristic type="CertificateStore">
      <characteristic-query type="{Enter certificate store name over here}" />
   </characteristic>
</wap-provisioningdoc>

You need to create three copies of this document called querystore_priv.xml, querystore_unpriv.xml, and querystore_spc.xml. The names are not important; however, these are the names we will use throughout the examples. Make copies of querystore.xml in the SDK Tools directory so they are easier to use with the command line tool rapiconfig.

You can use Notepad, or your favorite text or XML editor to edit these files.

For …	Replace …	With …
Querystore_unpriv.xml	{Enter certificate store name over here}	Unprivileged Execution Trust `Authorities`
Querystore_priv.xml	{Enter certificate store name over `here`}	Privileged Execution Trust `Authorities`
Querystore_spc.xml	{Enter `certificate` store name over `here`}	`SPC`

Using RAPIConfig

Refer to the Configuring Your Development Environment section to open the command prompt in the tools directory of the SDK. The rapiconfig tool works slightly differently for 2002 and 2003. The 2002 version outputs to the screen; the 2003 version outputs to a file. The instructions below will yield three .xml files. Each .xml file contains the list of certificates in a particular store.

Smartphone 2002

rapiconfig /p querystore_unpriv.xml > unpriv_certs.xml <press enter>
rapiconfig /p querystore_priv.xml  > priv_certs.xml <press enter>
rapiconfig /p querystore_spc.xml  > spc_certs.xml <press enter>

Smartphone 2003

rapiconfig /p querystore_unpriv.xml <press enter>
copy rapiconfigout.xml priv_certs.xml
rapiconfig /p querystore_priv.xml <press enter>
copy rapiconfigout.xml priv_certs.xml
rapiconfig /p querystore_spc.xml <press enter>
copy rapiconfigout.xml spc_certs.xml

You now have three files that each contain the list of certificates in a certificate store:

File	Cert list for …
`priv_certs.xml`	Privileged store
`priv_certs.xml`	Unprivileged store
`spc_certs.xml`	Installation store

If you get an error message from rapiconfig, you should check the next section.

What Happens If Your Smartphone Is Locked for Development?

One of the aspects of phone security an operator can control is whether or not a developer can connect to the phone from their development machine. If the operator has the opted for the restricted policy, you will receive an error:

 Config failed (0x80070005): Access is denied

If this is the case, you need to contact your operator to find out if they have a program for developers that allows you to develop against their specific phone hardware.

Note If you have an error in your .xml file, you will also receive an access denied error; however, the error number will be 0x80042004.

Signing Your Application for Deployment

To sign your application, you need to obtain a digital certificate that is trusted by your target phone or phones. The digital certificate has to be trusted to the level of execution privileges you need to run; that is, if you need privileged trust execution, you need to be signed with a privileged certificate. If you only need unprivileged trust execution, you need to be signed with an unprivileged certificate. For most applications, unprivileged trust execution is sufficient.

Obtaining a Certificate

Mobile2Market has certificates in the unprivileged store of all shipping Windows Mobile-based Smartphones. In order to sign your application so that it works across the widest range of handsets, we recommend you purchase a certificate from one of the participating certificate vendors in the Mobile2Market Participate Now section.

The certificate you obtain from these vendors is not typically trusted by the phone. You use this certificate to sign your application and then submit the signed application — usually via a Web interface — to your certificate vendor. The certificate vendor then has an automated process that signs your application with a certificate trusted by the Smartphone and gives you a link to download this application. This is done so that the vendor can verify your identity and hence helps maintain the integrity of the certificate that is trusted by the phone.

The certificate is often shipped on a physical USB device with a required PIN code. Your vendor will send you instructions on how to set it up.

Signing Your Application and Installer

There are five simple steps to creating a signed application once you have finished development and obtained your certificate:

Sign the executable components of your application (.exes and .dlls) with your certificate purchased from one of the Mobile2Market certificate vendors. There are instructions on doing this below.
Submit the signed components of your application to your certificate vendor through their Web interface. Contact your certificate vendor for their specific instructions. A file or files signed by a certificate trusted by the phone will be returned to you.
Build these components into an installation package (.cab) file.
Sign your .cab file using certificate purchased from one of the Mobile2Market certificate vendors. There are instructions on doing this later in this article.
Submit your signed .cab file to your certificate vendor through their Web interface. Contact your certificate vendor for their specific instructions. Your signed .cab file will be returned to you.

This .cab file can then be installed on all Windows Mobile-based Smartphones. The application itself can run without requiring prompting.

In order to sign an .exe, .dll or .cab file, you need to use the signCode.msi tool, which is installed in the Tools directory for both Smartphone 2002 and Smartphone 2003. Both tools are identical. When you run the tool, you will be presented with a wizard.

Figure 8. Opening the Digital Signature Wizard

By clicking Next, you will be asked which file you want to sign. You need to run the tool once for each component that needs to be signed, that is for each.exe and .dll as well as your final .cab file. You can see that I have chosen my Signing Demo.exe from the ARMRel directory of my project.

Figure 9. Selecting a file in the Digital Signature Wizard

After clicking Next, you are asked whether you want Typical or Advanced settings; choose Typical. The next screen asks you to select a certificate to use to sign. Choose Select From Store, and then you will be presented with a list of certificates in your personal certificate store. Rather than use the locally created certificates we have used up until now, you want to use the certificate you have bought from your vendor.

Note Signing with codesign does not use up your signing events with your provider. Signing events only get used when you submit your locally signed application to your vendor through their Web site.

Figure 10. Selecting a certificate to sign

You should be able to easily identify your Mobile2Market certificate because the Issued By field will be the same name as the company you bought your certificate from, for example, I have selected a Geotrust certificate. Once you click OK, you can click Next.

The next screen asks you for optional description data; you can click Next. You also don't need to add a timestamp, so you can click Next on the timestamp screen.

You've now successfully navigated the wizard. Click Finish and your .exe, .dll or .cab will be signed. You are now ready to submit your component or components to your signing vendor. Please refer to instructions for your vendor for doing this, but typically you must log into their Web site, often using the USB certificate they send you to verify your identity. Once you are logged in, you can upload your components and have them signed with a certificate trusted by the Smartphone.

Signing an App Requiring Privileged Access

With some security policies the certificates in the privileged certificate store are owned by the operator. If you identify that you need privileged execution trust, you need to contact your operator, often through their developer program, to establish how you can get your application signed with this certificate.

Note It is at the discretion of the operator to provide you with this service.

Conclusion

Smartphone application security policies and code signing can at first seem daunting and complicated. In fact, it is reasonably simple, and through this article you now understand the different certificate stores on the Smartphone, how to place certificates in those stores, and how to ensure you sign your applications with the correct certificate when you come to deploy it. Using these simple techniques you can ensure you have your application signed with the correct level of trust.

If you have any feedback on the content in this article, please send it to wmsecfbk@microsoft.com.

Appendix A: Protected Registry Entries

Registry Keys
HKEY_LOCAL_MACHINE\Comm HKEY_LOCAL_MACHINE\Drivers HKEY_LOCAL_MACHINE\HARDWARE HKEY_LOCAL_MACHINE\SYSTEM HKEY_LOCAL_MACHINE\Init HKEY_LOCAL_MACHINE\Security HKEY_LOCAL_MACHINE\WDMDrivers HKEY_LOCAL_MACHINE\Services HKEY CLASSES_ROOT (device specific)

HKEY_LOCAL_MACHINE\Comm

HKEY_LOCAL_MACHINE\Drivers

HKEY_LOCAL_MACHINE\HARDWARE

HKEY_LOCAL_MACHINE\SYSTEM

HKEY_LOCAL_MACHINE\Init

HKEY_LOCAL_MACHINE\Security

HKEY_LOCAL_MACHINE\WDMDrivers

HKEY_LOCAL_MACHINE\Services

HKEY CLASSES_ROOT (device specific)

Appendix B: List of Privileged APIs

Component	APIs
Public	SetInterruptEvent SetSystemMemoryDivision CESetThreadPriority CeSetThreadQuantum ForcePageout VirtualCopy LockPages UnlockPages SetProcPermissions SetKMode ReadProcessMemory WriteProcessMemory SetCleanRebootFlag PowerOffSystem DebugActiveProcess CreateProcess (only the debug flags DEBUG_ONLY_THIS_PROCESS and DEBUG_PROCESS) KernelIOControl
Extended Telephony Application Program Interface (ExTAPI)	lineRegister lineSetCallBarringPassword lineSetCallBarringState lineUnregister lineSetPreferredOperator lineSetEquipmentState lineGetGeneralInfo lineManageCalls lineSetGprsClass lineGetNumberCalls lineSetHSCSDState lineGetUSSD lineSendUSSD lineSetSendCallerIDState lineSetCallWaitingState
SIM Manager	simUnlockPhone simSetLockingStatus simGetSmsStorageStatus simChangeLockingPassword simReadMessage simWriteMessage simDeleteMessage simReadRecord simWriteRecord simGetRecordInfo
Short Message Service	SmsSetMessageNotification SmsClearMessageNotification SmsReceiveAllMessagesFromSIM SmsSetSMSC
Connection Manager	ConnMgrProviderMessage
Critical Process Monitor (CPM)	CPMRegister (Reboot) CPMShutdown CPMStatus CPMRegisterTest
Radio Interface Layer	All RIL APIs Note The required trust level for RIL APIs can be modified by changing the value of the following registry key from 2 to 1: [HKEY_LOCAL_MACHINE\Security\Policy\APIs\RILGSM] @="2"