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 (http://msdn.microsoft.com/en-us/library/aa919335.aspx).
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, 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 Name | Description |
|---|
| 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 Name | Policy Meaning |
|---|
| Off | No
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. |
| Locked | Only
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 Prompt | All
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 Locked | All
applications run at the Privileged level and must be signed by an M2M
certificate. Unsigned applications are not allowed to run. |
| Two-Tier Prompt | All
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 Locked | All
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.
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.
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:
1. | Either start an emulator or connect a device to the computer.
|
2. | Start Visual Studio 2008.
|
3. | Select Tools | Device Security Manager. In the left panel will be a list of the currently connected devices.
|
4. | Choose the desired security configuration from the list of security configurations in the right panel.
|
5. | Click Deploy to push the new configuration to the device.
|
Use the security configuration
tools to experiment with security policies.
