Windows
Mobile supports storing information in the device’s nonvolatile memory
and on external flash memory cards, if they are available. The data in
nonvolatile memory will persist until the device is hard reset or cold
booted. Developers have several options available for storage
encryption.
Files and Permissions
Files can be stored in either
the Object Store, internal flash memory, or on external flash memory
cards. Because there are no users, there are no file-level permissions.
However, some files can be written only by processes running at the
Privileged level. These files are marked with the SYSTEM file attribute
and include system files or sensitive device configuration data. All
files are readable by all processes, regardless of privilege level. Most
of the user’s data, including Outlook and application data, is
accessible to all applications running on the device.
Much like its
desktop counterparts, Windows Mobile has a registry that contains device
configuration information. The registry is laid out as a tree structure
with each node called a key. Each node can have multiple named values.
There are several possible data types for values, and they are what
hold the actual configuration data. The tree’s root nodes are hives.
The two main hives are HKEY_LOCAL_MACHINE (HKLM) and HKEY_CURRENT_USER
(HKCU). HKLM holds device-wide configuration, and HKCU holds
user-specific information. It doesn’t make much sense to have HKCU on a
Windows Mobile device because there is only one user; still, it exists.
The entire registry is
readable by all applications, so it is not possible to hide data within
the registry. However, certain locations can only be updated by
Privileged processes. These locations include device configuration
information that either mobile operators don’t want users to update or
that could be leveraged by malicious applications to elevate to
Privileged level. For example, certificate stores are in the registry
and should not be updated by applications running at the Normal
privilege level. The write permissions on the registry keys are checked
when the application calls one of the update registry APIs:
RegSetValueEx, RegCreateKeyEx, RegDeleteKey, or RegDeleteValue.
The following keys are only accessible when running at Privileged level:
| Registry Keys | Description |
|---|
| HKLM\Comm | Contains
common configuration information for the device. The communication
components are configured here. Also contains the certificate stores. |
| HKLM\Drivers | Configuration
information for drivers. Each driver has a unique node containing its
settings. Blocked from Normal processes because misconfigured drivers
would compromise the security of the device. |
| HKLM\HARDWARE | Used as a lookup for drivers implementing a certain device class (for example, the touchscreen driver). |
| HKLM\Init | Device
initialization information. Used to get the device up and running.
Contains the path to the registry file; overwriting this would lead to
loading of malicious registry data. |
| HKLM\Services | Configuration information for long-lived services that run on the device. |
| HKLM\SYSTEM | System-wide configuration information related to the base OS. |
| HKLM\WDMDrivers | Windows Driver Model (WDM) drivers. These drivers conform to the WDM conventions that outline how to write compatible drivers. |
| HKLM\Security | Security-related policies that define the privilege levels and security components, such as certificate enrollment policies. |
| HKCU\Security | Security policies specific to this user. |
| HKLM\Loader | Configures the device loader. |
Stolen Device Protections
As
mentioned earlier, Windows Mobile devices can be locked with a PIN
that, if misentered, will cause the device to wipe itself. Any data on
removable storage cards will not be wiped. Windows Mobile 6 adds support
for encrypting data on removable storage cards. Enterprise device administrators
can also wipe data remotely by pushing out policy through Exchange. When
the device syncs, it will receive the wipe policy and delete all
non-storage card data.
Structured Storage
Windows Mobile 6
includes Microsoft Compact SQL Server 3.5 as part of the OS ROM image.
Compact SQL Server is a full relational database engine and is file
based (SDF files). Users connect to the database using a standard SQL
connection string, and the database is manageable using SQL Management
Studio.
SQL Server 3.5 supports
password-based database encryption and integrity protection. The entire
database file is encrypted using AES 128 and integrity protected using
SHA-1. To enable encryption, include “Password=password” in the database
connection string. The responsibility for managing the password is
placed on the application developer, and the encryption option must be
specified at database creation time.
Encrypted and Device Secured Storage
Windows Mobile does not
support encryption of the entire device. However, encryption of
removable storage cards is supported starting in Windows Mobile 6.
Protection of on-device data is provided by prohibiting access to the
device unless the proper unlock code is specified. All data is wiped
from the device when a hard reset or cold boot is performed, which is
the only way to bypass the PIN. Therefore, the data is protected while
the device is running. An attacker could hack the hardware to gain
access to in-memory data, a sophisticated attack which is not currently
mitigated.
Encryption of removable
cards works by generating a key and storing that key in memory using the
Data Protection API (DPAPI), a technology that will be discussed
shortly. The key is erased upon hard reset, and the card is only usable
in that particular device. The encryption algorithm used by default is
AES 128, although RC4 may be used as well. When files are transferred to
a desktop PC from the device, they are decrypted before transfer.
Data Protection API (DPAPI)
DPAPI
is a technology ported from the Windows desktop OS. It includes two
APIs: CryptProtectData, for encrypting data, and CryptUnprotectData, for
decrypting data. Multiple keys can be used to encrypt data: the SYSTEM
key and the USER key. Both keys are generated by the device
automatically and stored in kernel memory. If the device is hard reset,
both keys will be lost and the data cannot be decrypted. Only Privileged
applications can use the SYSTEM key. DPAPI uses AES 128 for encryption
and SHA-1 for integrity protection. Applications using DPAPI protect the
data using CryptProtectData and receive back an encrypted blob; the
application is responsible for storing the blob.
Because DPAPI only has two
keys, there is no way to prevent one application from decrypting another
application’s data. Therefore, all applications running at Normal level
can unprotect all blobs protected with the USER key. Regardless, DPAPI
provides a good technology for storing data securely on a device. Users
unable to run arbitrary code or only able to browse the file system and
registry will be unable to decrypt DPAPI-protected data.
Crypto API
Windows Mobile includes a
subset of the Crypto API (CAPI), a general-purpose cryptographic API.
With the CryptXXX series of functions, CAPI provides symmetric and
asymmetric encryption support, one-way hash functions, and HMAC support.
Developers can use these functions to perform advanced encryption
operations.
CAPI also includes
the CertXXX collection of functions for manipulating certificates and
performing certificate operations. CAPI is very powerful and reasonably
documented, so developer have a good option available when performing
cryptographic operations.
