Windows Mobile Security - Permissions and User Controls

2/5/2011 5:04:31 PM
The Windows Mobile security model does not have an expressive permission or user control system. In fact, the concept of users does not even exist in Windows Mobile! Instead, permissions are assigned on a per-application basis. Windows Mobile Standard devices support two possible privilege tiers for applications to run at: Privileged and Normal.

Windows Mobile Classic and Professional devices support only the Privileged tier. The privilege level is decided based on the device’s security policy and assigned to a process at start time. Network operators or the device owner are responsible for configuring and deploying this policy, which is stored on the device as XML.

Privileged and Normal Mode

Privileged mode applications are able to read and modify any data on the device, configure device settings, modify other processes, and switch to kernel mode. In short, they have total control over the device. Any application that is allowed to run on a Windows Mobile Classic or Professional device will run as Privileged.

The Normal privilege level was introduced so that mobile carriers and enterprise device administrators could have more control over their devices. Normal applications are unable to modify sensitive portions of the device’s configuration and file system, such as the security policy and driver configurations. Additionally, they cannot enter kernel mode or modify other processes. They are able to use much of the device’s functionality, including Phone, Mobile Office, and SMS. The Normal privilege tier is available only on Windows Mobile Standard devices; however, not all Standard devices use the two-tier privilege model. Changing the Privileged mode requires a complete flash of user data and is therefore not normally done during the device’s lifetime.

To block access to the device’s configuration, certain APIs and file and registry locations are only available in Privileged mode. The list of Privileged APIs is included within the SDK and maintained by Microsoft. To see the most current list of Privileged APIs and protected locations, read the “Privileged APIs” topic within the Windows Mobile 6 SDK documentation on MSDN (

Authenticode, Signatures, and Certificates

The device decides the privilege level based on the application’s Authenticode signature. Authenticode is a Microsoft technology for attaching cryptographic signatures to various file types. The signature uses public key cryptography to ensure that the application has not been modified. If the application is tampered with, the signature will be invalidated. Associated with the key pair is a X.509 certificate. This certificate includes information about the developer of the application and is issued by a Certification Authority (CA). The CA is responsible for verifying who the developer is before issuing the certificate. After verifying the developer’s identity, the CA signs the developer’s certificate using the CA root certificate. A developer’s certificate signed by a CA root certificate is “chained to” that root. Multiple CAs are currently issuing certificates, and there are many types of certificates. All certificates are cryptographically equivalent and are only differentiated by their marked usages. The certificates used by Windows Mobile are marked valid for code signing.

On Windows Mobile devices, the common file types with signatures are CAB files, EXE executables, and DLLs. Before releasing an application, the application’s developer generates the signature and signs the application using Authenticode. Once an application is signed, the application cannot be modified without invalidating the signature. Users and the Windows Mobile OS can make trust decisions based on a valid signature and whether or not the application developer is trusted. Not all applications must be signed, and not all signed applications can be trusted. Whether or not the application should run is up to the device’s security policy and, in some cases, the user.

Signed applications can still have security vulnerabilities or be malicious. The signature process only adds accountability. Because the publisher information is included in the Authenticode signature, users can see who actually wrote the application. Once users choose to run the application, all bets are off, and the application can perform any operation allowed by its privilege level.

Public key cryptography

Public key cryptography, also known as asymmetric cryptography, requires a key pair consisting of two parts: a public key and a private key. The two are linked mathematically. The public portion can be freely distributed whereas the private portion must be kept secret. Data encrypted with the public key can only be decrypted by the associated private key, and vice versa. Cryptographic signatures use a one-way hash function to generate a unique hash of the body; this hash is then encrypted with the private key. This encrypted hash is referred to as the signature. The signature and the data are sent to users. When verifying a signature, the user uses the one-way hash function to generate a hash from the data. Then using the public key, the user decrypts the signature, which yields the original hash. These hashes are compared; if they do not match, the data has been modified.

Certificate Stores

Each Windows Mobile device has several collections of certificates, called certificate stores. Each store is named and can contain either CA root certificates, developer certificates, or a combination thereof. The certificates are stored with their associated public keys. If a certificate is valid for a particular usage on the device, it will be placed into the appropriate store. The code-execution certificate stores are populated by privileged code; for two-tier devices this means the content is generally fixed before the device is sold to the end user. The following table outlines the application certificate stores and their usages; there are other certificate stores, but these are not used for determining an application’s privilege level.

Store NameDescription
Privileged Execution Trust Authorities (Privileged Store)Applications signed with a certificate, or chaining to a certificate, in this store run at the Privileged level. Only highly trusted applications should have certificates in this store.
Unprivileged Execution Trust Authorities (Normal Store)Applications signed with a certificate, or chaining to a certificate, in this store run at the Normal privilege level on two-tier devices and at the Privileged level on one-tier devices. Most signed applications developed for Windows Mobile have certificates in this store.
Software Publisher Certificate (SPC)Only used by the installer to determine the trust level of CAB or Cabinet Provisioning Files (CPFs). The installer checks this store when verifying installer files to determine at what privilege level the installation should run. A special attribute in the certificate indicates the target privilege level. This store exists so that an installation can run at the Privileged level, while the application itself will run at the Normal privilege level. In general, all of the roots in the Normal or Privileged stores also exist within this store.

Mobile2Market Certificates

Many different mobile providers offer Windows Mobile devices. Remember that providers are responsible for the shipped contents of a device’s certificate stores. To avoid having developers sign applications for each different provider, Microsoft created the Mobile2Market (M2M) program. This program identifies CA root certificates that should be included on every Windows Mobile device. Developers can then get a certificate from a M2M CA and be confident that their signature will be valid on any Windows Mobile device. The CA and Microsoft publish M2M developer requirements. Developers meeting these standards are able to purchase M2M certificates for signing their applications.

There are two tiers of M2M: Normal and Privileged. At the time of this writing, all Windows Mobile 6 devices include the Normal M2M certificate. Most operators include the M2M certificate; however, the requirements for obtaining these certificates are much more stringent, and developers must submit their applications for testing and evaluation.

Emulator and Developer Certificates

The Windows Mobile emulator images contain test certificates, and the private keys for these certificates are distributed along with the Windows Mobile SDK. Developers can sign their applications with these certificates during the development process to test out application behavior without having to purchase a certificate. Most mobile operators also run a developer program, where developers can get development certificates. The CA root certificates for these certificates are not installed on production devices. It is a good security practice to sign applications with an emulator or development certificate during development and testing. The actual code-signing certificate should be kept secure and only be present on the machine used to create release builds. This prevents the certificate from being stolen or accidently disclosed and used to create sign malicious code. For best results, rotate certificates once per every two major releases. This way, the amount of code signed by a protected certificate can be minimized and incident response is hopefully much easier.

Revoking Applications

If an application is unreliable or malicious, the application can be revoked and will not be allowed to run. All applications by a publisher are revoked by disallowing the publisher’s certificate. Unsigned applications or a single app by a publisher are revoked by creating a one-way hash of the application and distributing the hash using XML policy. Individual CAB files may also be revoked using the same mechanism.

Revocation is performed using the revoke.exe tool included with the Windows Mobile SDK. The tool creates an XML blob that the mobile operator pushes out through their network. Upon receiving the XML, the device updates the revocation store to prevent the publisher’s applications, individual applications, and installations from running. Mobile operators may use this functionality to block the spread of viruses through their networks or kill applications that have violated the network’s development agreements. If a device is already compromised, revocation may not be effective because the device can ignore revocation messages.

Running Applications

Each device has a security policy that decides which applications will be allowed to run. The security policy is only updatable by privileged applications or by the wireless operator pushing out new policy via SMS. The policy is a collection of various settings, but the setting combinations detailed in Table 1 are the most common.

Table 1. Standard Device Security Policies
Policy NamePolicy Meaning
OffNo restrictions. All applications run without prompting and at the Privileged level. Devices rarely ship from mobile operators with this configuration, and this configuration is normally used during testing.
LockedOnly applications signed with the OEM’s certificates are allowed to run. This policy is extremely rare, if not nonexistent, on Windows Mobile consumer devices. Only devices meant for an industry, company, and purpose tend to have this policy.
One-Tier PromptAll applications run at the Privileged level. If the application is unsigned, a prompt will be displayed to the user asking if they want to run the application.
One-Tier M2M LockedAll applications run at the Privileged level and must be signed by an M2M certificate. Unsigned applications are not allowed to run.
Two-Tier PromptAll applications signed by certificates in the Privileged store run at the Privileged level; all applications signed by certificates in the Normal store run at the Normal level. If the application is unsigned, a prompt will be displayed to the user asking if they want to run the application. This is a common security policy for Windows Mobile devices.
Two-Tier M2M LockedAll applications signed by certificates in the Privileged store run at the Privileged level; all applications signed by certificates in the Normal store run at the Normal level. All applications must be signed by an M2M certificate in order to run; unsigned applications are blocked.

The prompts presented for unsigned applications are rudimentary and grant access to the application based on the current security policy (see Figure 1). For example, on a One-Tier Prompt device, the application will run at the Privileged level. If a user cancels a prompt, the application will not run.

Figure 1. Windows Mobile 6 prompt when running an unsigned application

Once a user accepts a prompt, Windows Mobile stores a cryptographic hash of the application, and the user will never be prompted again for that application. If the application is recompiled, the hash will change and the user must once again accept the prompt. This policy prevents the user from having to answer multiple prompts for the same application.

Locking Devices

Devices may contain sensitive corporate data that, when lost, is very damaging. To prevent misuse, users can lock a device, preventing all use of the device. To unlock the device, users can specify either a numerical PIN code or a strong alphanumeric code. The lock can be activated manually or after an inactivity timeout. In a large enterprise, device administrators often push out a security policy requiring devices to lock after a specified amount of time. Administrators can also specify that a device should wipe data if a certain number of invalid PIN codes are entered. Removable storage cards are not wiped. Interestingly, Windows Mobile contains an interstitial screen between each PIN attempt. This way, a user’s device won’t be accidently wiped if it is in the user’s bag or pocket and the PIN is accidently pressed. In an enterprise environment, the device PINs can be escrowed through Exchange so that they can be recovered in case they are forgotten. If the device is wiped, data on the device cannot be recovered.

The lock code prevents the device from being accessed when cradled in a PC. If the device is locked and then cradled, the user will have to enter the PIN code on the device before the cradling operation can complete. The code is entered on the device so that it is never disclosed to the PC. The cradle security mechanisms prevent an attacker from finding a device and then pulling all the data off it using a PC.

Managing Device Security Policy

While you’re developing and performing security testing, playing around with a device’s security policy can provide a lot of insight into how the application works. To make managing security policies simple, Microsoft provides the Security Configuration Manager PowerToy (see Figure 2). This tool can be downloaded from Microsoft’s website . The tool can be used against real devices and the emulator.

Figure 2. The Security Configuration Manager PowerToy setting a device’s security policy

To use the Security Configuration Manager PowerToy, install it, cradle the device, and start the tool. On the right side, the tool shows the device’s current security policy. On the left side, there is a drop-down list containing common security policies. After selecting a policy, click Provision and the policy will be pushed to the device. The policy is pushed by generating a CAB Provisioning File (CPF) containing the policy and signing the CPF with a development certificate. If the development certificate root is not installed on the device, the device may show a prompt. At the bottom of the tool are several tabs showing the contents of the device’s certificate stores. New certificates can be added through the Device menu.

The tool can also be used to display the signature on a package. To do so, click the File menu, select Check File Signature, browse to the file, and click OK. The tool will display the package’s signature and relevant information. Signing with the development certificates is also possible using this tool.

If you are using Visual Studio 2008, the Security Configuration Manager PowerToy is integrated directly into Visual Studio and is much easier to use. To use the Visual Studio 2008 version, follow these steps:

Either start an emulator or connect a device to the computer.

Start Visual Studio 2008.

Select Tools | Device Security Manager. In the left panel will be a list of the currently connected devices.

Choose the desired security configuration from the list of security configurations in the right panel.

Click Deploy to push the new configuration to the device.

Use the security configuration tools to experiment with security policies.

  •  Windows Phone 7 Development : Using a WebBrowser Control to Display Web Content
  •  Windows Phone 7 Development : Adding a WebBrowser Control
  •  Programming the Mobile Web : Content Delivery (part 3)
  •  Programming the Mobile Web : Content Delivery (part 2) - File Delivery
  •  Programming the Mobile Web : Content Delivery (part 1) - Defining MIME Types
  •  iPhone Application Development : Using Switches, Segmented Controls, and Web Views (part 3)
  •  iPhone Application Development : Using Switches, Segmented Controls, and Web Views (part 2)
  •  iPhone Application Development : Using Switches, Segmented Controls, and Web Views (part 1)
  •  iPhone Application Development : Using Advanced Interface Objects and Views - User Input and Output
  •  Windows Phone 7 Development : Wiring Up Events to an Application Bar ( part 2)
  •  Windows Phone 7 Development : Wiring Up Events to an Application Bar ( part 1) - Reacting to Add Button Events
  •  Adding an Application Bar to a Windows Phone 7 Application (part 3) - Adding an Application Bar Using Managed Code
  •  Adding an Application Bar to a Windows Phone 7 Application (part 2) - Adding a Local Application Bar Using XAML & Adding Menu Items
  •  Adding an Application Bar to a Windows Phone 7 Application (part 1) - Adding Images for Use with Application Bar Buttons & Adding a Global Application Bar Using XAML
  •  iPhone Application Development : Creating and Managing Image Animations and Sliders (part 3) - Finishing the Interface
  •  iPhone Application Development : Creating and Managing Image Animations and Sliders (part 2) - Adding an Image View
  •  iPhone Application Development : Creating and Managing Image Animations and Sliders (part 1)
  •  iPhone Application Development : User Input and Output
  •  Windows Phone 7 : Using Accelerometer Data to Move a Ball
  •  Server-Side Browser Detection and Content Delivery : Mobile Detection (part 4) - Device Libraries
    Top 10
    Group Test – Soundbars (Part 2)
    Group Test – Soundbars (Part 1)
    ‘Space Junk’ Could Be Catastrophic
    Dropbox For Teams: Suitable For Business?
    AMD And Nvidia Based Products In The New Benchmark (Part 3)
    AMD And Nvidia Based Products In The New Benchmark (Part 2)
    AMD And Nvidia Based Products In The New Benchmark (Part 1)
    BlackBerry Z10 - A Contender For The Best Smartphone (Part 2)
    BlackBerry Z10 - A Contender For The Best Smartphone (Part 1)
    Fujifilm X-Pro1 - One Of The Very Best CSC On The Market
    Most View
    Turn Your iPhone Into A DSLR
    Algorithms for Compiler Design: THE LR PARSER
    Kodak ScanMate i940 - Cost-Effective Sheet-Fed Scanner
    TriCaster 40 And Newtek Control Surface For TriCaster 40
    Roccat Lua Tri-Button Gaming Mouse - Great Choice For Lefties
    ASUS Transformer Pad - Transforming Value to Quality
    SQL Server 2008: Managing Resources with the Resource Governor (part 2) - Workload Groups
    System Builder - The Future Of USB
    Open GL : Using Vertex Array Objects to Organize Your Buffers
    Apple Retains Its Top Slot In The Tablet Market
    Ultrasone 650 Pro headphone review
    Viewsonic Pro8300 - Full HD 1080p DLP Projector
    How To Overclock Your New PC
    Maintaining Your Windows XP System : Backing Up Your Files
    The HP Virtual Server Environment : HP Integrity Virtual Machines (Fully Virtualized Partitioning)
    Programming with DirectX : Game Input - XInput
    Creative Sound Blaster Tactic3D Alpha Headphones Review
    Custom: Installation Nation (Part 2)
    Troubleshooting and Testing Network Settings
    Buying Guide: High-end CPUs (Part 3) - Intel Core I7-3770K, Intel Core i7-3930K, Intel Core i7-3970X