Export (0) Print
Expand All
1 out of 2 rated this helpful - Rate this topic

Secure Windows Mobile Development and Deployment

 

Chung Webster
Microsoft

August 2004

Applies to:
   Windows Mobile™-based devices
   Windows Mobile 2003 Second Edition software for Pocket PCs
   Windows Mobile 2003 Second Edition software for Smartphones
   Microsoft® Exchange 2003
   Microsoft eMbedded Visual C++® version 4.0
   Microsoft .NET Compact Framework version 1.0
   Microsoft SQL Server™ CE version 2.0
   Microsoft Windows® CE .NET version 4.2

Summary: This article looks at what development and deployment security options are available for the Pocket PC and Smartphone, including Public Key Infrastructure, Email with Exchange Server, Virtual Private Networks, WiFi, device configuration management, Pocket PC power on passwords and SQL SE security. (44 printed pages)


Download Secure Windows Mobile Development and Deployment.msi from the Microsoft Download Center.

Download a PDF version of this article from the Microsoft Download Center.

Contents

Introduction
Mobile Threats
Public Key Infrastructure
Exchange Server and SSL E-Mail
Virtual Private Networking
Safer WiFi
Standard Perimeter Security
Pocket PC Custom Password Perimeter Security
Smartphone Application Security
XML Device Management
Custom Storage using File System Filters
SQL Server CE Security
Conclusion

Introduction

What exactly is deployment? It covers many situations, hardware and software, but primarily is about distribution and maintenance. In the desktop and server world, maintenance tends to be a factor in deployment planning, Windows Mobile™-based devices tend not to be at the forefront of deployment and maintenance. This paper demonstrates various techniques to aid configuration of devices, to support hardware deployment and maintenance. We will also look at developer techniques you can use to improve security of your application and data on the device.

Mobile Threats

When you start designing a Smart Client application you should consider threat modeling analysis to identify your assets, threats and risks. Common areas include securing access to data on the device and securing communications between the device and remote endpoints. Since there is no concept of users and ACLs, all users of the device are effectively local administrators, so you might want to lock down the device.

When securing data on the device, consider encrypting SQL CE databases and adding login to your application. What happens if the device is lost or stolen? If someone tries a dictionary attack on your application you may want to delete your application data after a certain number of failed attempts or increase a wait time between each login. If your application data resides on a storage card then consider encrypting the data files as these are easily removable and readable.

For remote communications think about using encrypted transports such as SSL or if applicable VPN, or you may want to custom encrypt data before sending. Be aware that the shared key encryption on 802.11b WiFi can be broken if enough packets are sniffed.

Table 1 lists some techniques you can use to reduce your security risks.

Table 1. Security areas and options to reduce your security risks

Security Area Options
Securing Data Microsoft Exchange Server

Custom Storage using File System Filters

Crypto API (Under PKI Infrastructure section)

Microsoft SQL Server™ CE Security

Securing Communications PKI Infrastructure

SSL E-mail

Virtual Private Networking

Safer WiFi

SQL Server CE Security

Device Lockdown Standard Perimeter Security

Pocket PC Custom Password Perimeter Security

XML Device Management

SQL Server CE Security

Smartphone Application Security

Public Key Infrastructure

PKI is a set of software services and standards that help provide secure communications. This consists of encryption enabling privacy, identification or authentication of users and non-repudiation, providing integrity and proof of origin of data.

Most users think of encryption as requiring a private key which is used to encrypt and decrypt data. This requires the private key to be kept secret, which poses a problem since it requires distribution. Public-key cryptography uses two keys, a private and a public key. This allows users to encrypt data with their private keys, which can then be decrypted using their public key, which is distributable. This scenario could allow us to determine the source of the encrypted data, by the virtue we can only decrypt the data using their public key. Likewise if a user encrypts data with someone's public key, then only the recipient with correct private key can decrypt that data.

PKI packages up public keys as a digital certificate, providing additional information such as the issuer, version and expiration of the key. Certificates are also signed with a digital certificate. The certificate issuer creates a hash based on the content of the certificate and then encrypts this using their private key, this forms the digital signature. The user receiving the certificate can then decrypt signature and extract out the hash value, the user also generates a hash from the certificate and compares both hash values. If they are the same then the certificate has not been tampered with.

Microsoft provides the CryptoAPI for implementing PKI standards such as symmetric/asymmetric key encryption/decryption and Microsoft Windows® CE .NET 4.2 provides the following configurable certificate stores, as shown in Table 2.

Table 2. Configurable certificate stores

Store Description
ROOT This store contains certificate roots trusted for secure Web sessions (HTTPS).
CA This store contains trusted intermediate certification authorities
MY This store contains the user's personal client certificates for authenticating over a Secure Sockets Layer (SSL) channel, using 802.1x, using a Virtual Private Network (VPN), encrypting or signing e-mail, or any other usage. As these are personal certificates, they also contain the private key.

Smartphone also provides some additional stores used determining execution privileges, see the Smartphone Application Security section in this paper for more details.

Pocket PC 2003 and Smartphone 2003 provide a settings applet to manage certificates. Here you can view and delete the root and personal certificates on the device, as shown in Figures 1 and 2.

Figure 1. Certificate store

Figure 2. Certificate store

Generally within the enterprise market, certificates are used to ensure the identity and secure communications of messages. Most infrastructures provide a Certificate Authority (CA) for example running on Windows Server 2003. This CA service issues certificates to support PKI enabled applications. For more information on how to setup a Windows Server CA see Step-by-Step Guide to Setting up a Certificate Authority. It is recommended to obtain an SSL certificate from a 3rd party CA since most browsers ship with their certificate roots pre-installed.

Note the Pocket PC and Smartphone Certificates applet has no capability to install certificates, only list and remove certificates.

To enroll a certificate from a CA, the client needs to authenticate the current user, create a PCKS #10 certificate request message over HTTP POST, then issue an HTTP GET to retrieve the certificate. This is then stored in the relevant certificate store using CryptoAPI. Both Pocket PC 2003 and Smartphone 2003 SDKs provide enrollment sample code, in the Samples\Win32\Enroll directory under the SDK installation directory. The sample is native, so you need to install Microsoft eMbedded Visual C++ 4.0 first. For managed development you must first install Microsoft Visual Studio .NET 2003.

On Pocket PC 2003 it is also possible to install a ROOT certificate file, .cer extension, using File Explorer. Simply copy the certificate onto the device and open using File Explorer.

For example code on how to programmatically add a certificate to the root store, see the How to add root certificates to Windows Mobile 2003 Smartphone and to Windows Mobile 2002 Smartphone Knowledge Base article.

Traditionally applications have authenticated users using a username and password combination. With PKI and the Windows Mobile platform, we have additional options for authenticating users.

  • Something you provide — Certificates (on device, smartcard or token).
  • Something you know — Usernames, passwords and phrases.
  • Physical attributes — Biometric security (thumbprint scanner on HP5550).
  • Personal attributes — Signature (Pocket PC stylus capture that also measures velocity of handwriting).

Multi-factor authentication combines two or more of these authentication options and can further reduce unauthorized access. For example if a device is stolen containing a certificate to run an application, security is breached, unless a PIN is also required to run the application.

Cryptography API

Pocket PC and Smartphone provide the CryptoAPI (CAPI) for developing applications requiring security standards such as hashing, symmetric/asymmetric encryption and certificate support. CAPI uses a provider model, as shown in Figure 3, where encryption algorithms are provided by cryptographic service providers (CSPs).

Figure 3. CryptoAPI provider model

Windows CE .NET 4.2 provides base and enhanced RSA providers along with a Smart Card provider, as shown in Table 3. The enhanced CSP provides longer keys and additional algorithms. Note on Windows CE .NET 4.1 onwards the default CSP is the enhanced RSA provider.

Table 3. Windows CE .NET 4.2 base and enhanced algorithms

Algorithm Base Enhanced
RSA Key Exchange 512 bit 1024 bit
RSA Signature 512 bit 1024 bit
RC2 block 40 bit 128 bit
RC4 stream 40 bit 128 bit
RC5 block Not Supported 128 bit
DES Not Supported 56 bit
Triple DES (2-key) Not Supported 112 bit
Triple DES (3-key) Not Supported 168 bit

Each CSP provides one or more encryption algorithms, which may be symmetric or asymmetric. CAPI provides the generic methods to process and manipulate the algorithms. To ensure encryptions keys are secure, each CSP provides an internal key database which is not directly accessible. The keys are stored within a key container which is held within the key database. This relationship is showed in Figure 4.

Figure 4. CSP database/container relationship

Session keys are not automatically persisted, to store a key it needs to be exported into a key binary large object (key BLOB). This mechanism is used for secure key exchange, for more information see Key BLOBs on MSDN. An alternative is to derive session keys from a password, so the key does not need to be persisted.

Let's look at an example that allows encryption and decryption of data on the device. This sample generates a symmetric key from a password that is provided by the user (as shown in Figure 5); this is used to encrypt the data using the RC2 block algorithm.

Figure 5. File encryption/decryption sample

Before we can encrypt or decrypt data we need to acquire a CSP, in this case the default RSA provider.

CryptAcquireContext (&hProv, NULL, NULL, PROV_RSA_FULL, 0);

Next create a MD5 hash object, this will allow us to hash the password.

CryptCreateHash (hProv, CALG_MD5, 0, 0, &hHash);
CryptHashData (hHash, (PBYTE)lpszPassword, _tcslen(lpszPassword), 0);

We can then derive a RC2 session key from the password hash, this key can be used to encrypt and decrypt data.

CryptDeriveKey (hProv, CALG_RC2, hHash, 0, &hKey);
// encrypt data
CryptEncrypt (hKey, 0, bEOF, 0, pbBuffer, &dwCount, dwBufferLen);
// or decrypt data
CryptDecrypt (hKey, 0, bEOF, 0, pbBuffer, &dwCount);

Figures 6 and 7 show the plaintext and ciphertext data.

Figure 6. Plaintext data

Figure 7. Ciphertext data

Since the password is used to derive the RC2 session key, the user is required to enter this before the data can be encrypted/decrypted. Sending the encrypted data to another user would require shared knowledge of the same password. PKI can be used for secure key exchange, so the password does not need to be manually given to another user. For more information see Exchanging Session Keys on MSDN.

Exchange Server and SSL E-Mail

Windows Mobile-based devices provide out of the box connectivity to Exchange Server and support for synchronization of Inbox, Contact and Calendar information. Device support is inbuilt with Exchange Server 2003 (Server ActiveSync must be enabled) and Exchange Server 2000 can support devices with Mobile Information Server installed.

Synchronization works over HTTPS, although it can be configured over HTTP, so devices with an inbuilt radio stack, such as Smartphone and Pocket PC Phone Edition, can synchronize over-the-air using GPRS or data GSM calls, along with WiFi enabled devices. Other 'wired only' devices can either connect to the server if they have a network card or connect via USB to a PC and utilize the PCs connectivity.

With Windows Mobile-based devices it is possible to configure the device not to use SSL secure channel, however this channel is open and subject to eavesdropping.

Connection over HTTPS requires the organization hosting Exchange to purchase an SSL certificate. Smaller organizations may not be keen to purchase this upfront and may enable synchronization over HTTP, resulting in credentials (and data) being sent in cleartext. If this is occurring internally, behind the firewall, then this level of security may be acceptable, just consider the risk of eavesdropping within your network. If you need to externally synchronize over HTTP, consider using VPN through to your firewall. This externally provides more security through encrypted packets, but again once within your network, data is open. Bear in mind that HTTPS provides a secure channel from the client, through to the server.

Root certificates installed on Windows Mobile-based devices

  • Entrust.net Secure Server
  • Entrust.net CA (2048 bit)
  • Equifax Secure Certificate Authority
  • GlobalSign Root CA
  • GTE Cybertrust ROOT
  • GTE Cybertrust Solutions ROOT
  • Secure Server Certifricate
  • Thawte Server CA
  • Thawte Premium Server CA
  • Verisign Class 2 Public Primary CA
  • Verisign Class 3 Public Primary CA

It is possible to further secure the e-mail transmission channel by configuring Exchange ActiveSync to use RSA SecurID that supports Pocket PC. This provides two-factor authentication with a random access code which is changed every 60 seconds combined with a PIN. This authentication is implemented in software and Pocket PC client software is available from RSA. Since a new code is generated every 60 seconds, the timeframe for attack is severely limited making this solution even more secure.

For more information on how to setup and configure RSA SecurID download the Exchange Server 2003 Deployment Guide.

Secured MIME (S/MIME) enables encryption of messages with digital signatures providing confidentiality and identity. This processing is done on the clients, the mail severs treat S/MIME like a standard MIME message. A user sending an S/MIME message signs the message using their X.509 certificate/private key. The recipient then uses the sender's public key to decrypt the message. This ensures the sender can be verified and that the message has not been tampered with. Additionally this can be used in reverse to enable shared key encryption. A user can create a shared key and encrypt an attachment. This key can be sent to a recipient by encrypting the message with the recipient's public key. This way only the recipient can decrypt the message with their private key and find out the shared key. Support for S/MIME is on the future Windows Mobile roadmap, providing an even more secure message exchange.

Logging the Client

Data synchronizing between the client and server uses the AirSync protocol over HTTP. This uses a variety of verbs including GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS and CONNECT, the body is XML. A typical synchronization session will initially sync the folder structure on the server, then provide an estimate of which items need transferring, followed by full synchronization of data.

Assuming there are no connectivity issues, synchronization on a configured system rarely fails. To help diagnose any issues, verbose logging can be configured on the client. This will log all AirSync activity including the HTTP headers and XML body.

To switch on logging on Pocket PC 2003, start Microsoft ActiveSync®:

  1. Select Tools | Options
  2. Select the Server tab
  3. Select the Options button
  4. Select the Rules tab
  5. Change Logging to Brief or Verbose

To switch on logging on Smartphone 2002, start ActiveSync:

  1. Select Menu | 1 Options
  2. Select 3 Server Settings
  3. Select 4 Connection
  4. Select Menu | 1 Rules
  5. Change Logging to Brief or Verbose

Figure 8. ActiveSync Logging

Common situations that affect synchronization including no memory space left on the device or a full mailbox on the server. Sometimes it is possible for the synchronization keys used between the client and server to become mismatch, for example if a device is restored from an old backup image and subsequently the user's mailbox has moved servers. This can be fixed by unselecting what items to synchronize; this will delete the data on the device. These items can then be re-selected and synchronized down.

Virtual Private Networking

This technology allows you to extend your network infrastructure by using the public Internet as your own private network. This is achieved by adding routing information and encrypting each packet of data destined for the private network. The overhead of using the Internet is much lower than the cost of installing a dedicated private network infrastructure, enabling users to work anywhere there is an Internet connection.

Windows Mobile has extended VPN support to include Layer Two Tunneling Protocol (L2TP)/Internet Protocol security (IPSec) alongside previous support for Point-to-Point Tunneling Protocol (PPTP), as shown in Figures 9 and 10.

Figure 9. IPSec/L2TP VPN settings, screen 1

Figure 10. IPSec/L2TP VPN settings, screen 2

Using IPSec/L2TP we can now authenticate using a client certificate, providing stronger security than a simply username/password combination, or we can use a shared secret key. See the Public-Key Infrastructure section for references on how to provision a certificate onto the device.

Safer WiFi

With the advent of cheap 802.11b hardware, WiFi access points have become ubiquitous throughout larger cities. I was staying around a friend's house in Soho, London and found eight access points when I switched on my laptop, three of these were completely open! Wired Equivalent Privacy (WEP) provides a weak encryption that has published exploits enabling you to read wireless data. It also relies on a shared secret key, which makes it harder to limit connecting clients, since by nature this key must be given out. Some smaller WLANs filter clients on their network MAC addresses, which is not scalable within a large enterprise. A good solution is to implement the 802.1X standard. This uses Extensible Authentication Protocol (EAP) and can provide more secure communications by installing a client certificate, so you can ensure the identity of the client device and encrypt key exchanges. This requires a CA to publish certificates for each user/device and Internet Authentication Service to authenticate the client certificate. For more information on how to configure these see Securing Wireless LANs - A Windows Server 2003 Certificate Services Solution.

Microsoft Pocket PC 2003 Second Edition also brings Wi-Fi Protected Access (WPA) to the platform, providing further enhanced security. This includes stronger integrity for each packet and protection against replay attacks by using a new frame counter. It still uses the 802.1X authentication mechanism but unlike 802.11b mandates the use of an encryption key. For unicast traffic, The Temporal Key Integrity Protocol (TKIP) is used, providing a new key with every frame. For multicast a global encryption key is used, which can be updated dynamically. It is possible for an access point to support both WEP and WPA standards, but the global key must be static in order to support 802.11g clients.

Standard Perimeter Security

The aim of perimeter security is to provide protection against remote attacks or malicious activity. There are three main areas where this is enforced:

  • Physical access to the device
  • Device management
  • Remote calls via desktop ActiveSync

Physical access to the device

The primary mechanism to secure physical access is by using a device password, which is enforced on power on or after a configurable timeout. This prevents the user from any access to the device until the correct password has been entered, see next section on implementing a custom password provider.

If the device has an expansion slot, then the device can be configured to provide autorun functionality. If this is enabled, it would be possible for the user to unintentionally install an aggressive application such as a virus. See the Security Policies in the XML Device Management section, to learn how to enable/disable this functionality.

Pocket PC Phone Edition and Smartphone devices also provide a radio stack which communicates with a SIM card. These devices support a SIM lock, enabling users to set a SIM password. When the radio stack is turned on, the user has three attempts to unlock the SIM and gain radio access. After this the SIM card is locked, requiring assistance from the SIM operator to unlock it.

Device Management

Windows Mobile contains a configuration metabase, similar to Internet Information Services (IIS), which can deny/allow various operations that may affect the device. Instead of configuring these directly modifying an XML document (à la IIS6), the device can be configured with an XML message received OTA, via ActiveSync using the Remote API (RAPI) or directly in code on the device by using the DMProcessConfigXML API call (See the XML Device Management section).

Table 4 shows the available polices available on Windows Mobile devices.

Table 4. Device management policies

Policy Description Smartphone Pocket PC
AutoRun This policy setting determines whether applications stored on an expansion card (such as SD or CF) are allowed to run automatically when inserted into the device. Yes Yes
Grant Manager This policy setting grants security roles — other than the Manager role — administrative privileges to the system that are given to the Manager role, without modifying metabase role assignments. In particular, the Grant Manager policy maps a role mask to the Manager role.

Configuration Manager enforces this security policy.

Yes Yes
Grant User Authenticated This security policy setting allows other roles to impersonate the SECROLE_USER_AUTH role. In particular, this security policy permits a particular role mask to map to the SECROLE_USER_AUTH role without modifying the security role assigned to every metabase setting that the SECROLE_USER_AUTH role can access. Yes Yes
Message Authentication This policy setting defines the maximum number of times the user is allowed to retry authenticating a Wireless Application Protocol (WAP) PIN-signed message. Yes Yes
OTA Provisioning This policy setting determines which provisioning messages are accepted by the Configuration Host based on the roles assigned to the messages. This policy limits the provisioning messages that come from the Push Router.

For more information about the Configuration Host, see Data from Push Router

Yes Yes
PrivilegedApps Determines whether the One-Tier (all execution is in privileged mode) or Two-Tier (may be privileged or un-privileged depending on signed certificate, see Smartphone Application Security) security model is used. Yes No
RAPI The RAPI policy restricts the access of remote applications that are using remote API (RAPI) to implement Microsoft ActiveSync operations on mobile devices. Yes Yes
Service Loading policy Determines whether SL messages are accepted. Yes No
Service Indication policy Determines whether SI messages are accepted. Yes No
TPS This policy setting determines whether mobile operators can be assigned the Trusted Provisioning Server role for WAP provisioning. Yes Yes
Trusted WAP This security policy setting specifies the level of permissions required to create, modify, or delete a trusted proxy. Yes Yes
Unauthenticated Messages Unauthenticated Messages policy. This policy setting determines whether to accept non-WAP-signed messages processed by the default security provider in the Security Module (Push Router), based on their origin. Yes Yes
Unsigned .cabs This security policy setting enforces whether unsigned .cab files can be installed on the device. Yes No
Unsigned Applications policy Enforces whether unsigned applications are allowed to run on Smartphone. Yes No
Unsigned Prompt policy Enforces whether a user will be prompted if an unsigned application is installed or executed on Smartphone. Yes No
WAP Signed Message This policy setting determines how WAP-signed messages should be processed based on their origin and the lack of the SECROLE_USER_AUTH security role. Yes Yes
WSP Push This policy setting determines whether to allow Wireless Session Protocol (WSP) notifications from the WAP stack to be routed. Yes Yes

For example if we wanted to change the autorun policy, we would need to create an XML document.

<!-- Sample XML to change autorun device policy  -->
<wap-provisioningdoc>
   <characteristic type="SecurityPolicy">
      <!--
      Policy ID 2
      Possible values
      1 - Applications are restricted
      0 - Applications can run
      -->
      <parm name="2" value="1" /> 
   </characteristic>
</wap-provisioningdoc>

See the XML Provisioning section on how to send this configuration XML to a Windows Mobile device.

For more information, including the parameter details for the XML configuration, look up Device Management Policies in the Pocket PC 2003 SDK help.

Remote calls via desktop ActiveSync

The Remote API (RAPI) provides a remote procedure call (RPC) between the desktop and device. This is used extensively by ActiveSync for example when setting up a partnership, RAPI will configure the e-mail provide/configuration, or when copying files to/from the desktop to device. This may be a security risk to your organization, so it is possible to restrict if RAPI is enabled or not, also setting a Power On Password will prevent RAPI calls.

<!-- Sample XML to change RAPI device policy  -->
<wap-provisioningdoc>
   <characteristic type="SecurityPolicy">
      <!--
      Policy ID 4097
      Possible values
      0 - All RAPI calls are disabled
      1 - All RAPI calls are allowed
      2 - RAPI calls in restricted mode
      -->
      <parm name="4097" value="0" /> 
   </characteristic>
</wap-provisioningdoc>

Note it is possible to set a restricted mode for RAPI. This limits calls that fit under the SECROLE_USER_AUTH (User Authenticated) role. In effect this covers most user scenarios except non-WAP-signed WAP push messages and unsigned cab files. See Security Roles on Pocket PC in the Pocket PC 2003 SDK help for more information of roles.

Pocket PC Custom Password Perimeter Security

Perimeter security provides an effective mechanism for limiting access to your device. The default power applet enables you to provide either a fixed 4-digit or string password. Additionally the shell has a timeout setting, enabling you to control when the power on password dialog is displayed. Figures 11, 12, and 13 show the default password settings.

Figure 11. Default password settings, screen 1

Figure 12. Default password settings, screen 2

Figure 13. Default password settings, screen 3

It is also possible to plug-in a custom password applet if you have a requirement for custom security. For example if you have fingerprint hardware, the key could be a hash of the fingerprint data, or you could capture a signature storing the speed it was drawn, making it more difficult to forge, or you could log when the device is powered on. To deploy this custom functionality, the device must provide a compatible internal StartUI component. Warning the OEM can customize this and may break compatibility with this solution, so test against your hardware.

There are two sections in creating a custom power on password, creating the control panel applet and setting/authentication of the password data, as shown in Figure 14.

Click here for larger image

Figure 14. Power on password architecture. Click the thumbnail for a larger image.

The password control panel is simply a Win32 DLL that exports two methods, for the applet to show within the Settings (Control Panel) on the Pocket PC, it must be renamed to use the CPL extension, as described in Table 5.

Table 5. Password DLL Exports

Method Description
CPlApplet This method enables basic message handling from the Settings (Control Panel) on the Pocket PC. For example it allows the CPL library to set the icon and caption in the Settings dialog and can process click event, to display the custom password functionality.
PromptForPasswd The registry is modified to redirect password calls to the custom password CPL library. This is called if a password is set and the user turns on the device.

The CPlApplet function provides a windows procedure handler to receive messages from the Settings (Control Panel).

LONG CALLBACK CPlApplet(HWND hwnd, UINT uMsg, LONG lParam1, LONG  lParam2) {
   switch(uMsg) 
   {
      case CPL_INIT:
         return TRUE;
      case CPL_GETCOUNT:
         return 1L;
      case CPL_IDNAME:
         // Registry subkey -- HKEY_LOCAL_MACHINE\ControlPanel\...
            lstrcpy((LPTSTR)lParam2, TEXT("password")); 
            return 0;
      case CPL_NEWINQUIRE:
        {
         LPNEWCPLINFO lpNewCPlInfo = (LPNEWCPLINFO)lParam2;
         if ( lParam1 != 0 ) // Applet index -- we only have one.
            return 0;
         // Set up our sole applet
            lpNewCPlInfo->dwSize = (DWORD)sizeof(NEWCPLINFO);
            lpNewCPlInfo->dwFlags = 0;
            lpNewCPlInfo->hIcon = (HICON)LoadImage(   g_hInstance,                                        MAKEINTRESOURCE(ICON_SIMPLEPASSWORD), 
                                       IMAGE_ICON, 32, 32, 0 );

            lstrcpy( lpNewCPlInfo->szName, g_pszAppletCaption );
            lstrcpy( lpNewCPlInfo->szInfo, TEXT("A simple password protection replacement.") );
            return 0;
        }

        case CPL_DBLCLK:
        {         
         if ( lParam1 != 0 ) // Applet index -- we only  have one.
            return FALSE;
         // Show custom password dialog
         ShowSecurityDialog((HWND)0, FALSE);
         return TRUE;
        }      
      case CPL_EXIT:
      case CPL_SELECT:
      case CPL_STOP:
      default:
         break;
   }
   return 0;
}

The CPL_NEWINQUIRE message is used to request information from the control panel applet, in our case to set the icon and text. The CPL_DBLCLK message is sent when the user selects the control panel applet, we then need to display our custom password provider. Note this message handler implementation is used for creating any custom control panel applet.

Additionally we need to implement the PromptForPasswd method, this is called when the device is powered on and it has passed a configurable time limit. This method should then display the custom password entry and return the password to the OS. If this is verified the user gains entry to the device, otherwise the method is called again re-displaying the dialog. Note the second parameter fTightSecurity is reserved and always true.

LPTSTR PromptForPasswd(HWND hwndParent, BOOL fTightSecurity) {   
   TCHAR*   pszPassword;
   // Prompt the user and handle all the custom security stuff
   ShowSecurityDialog(hwndParent, TRUE);   
   pszPassword = (TCHAR*)LocalAlloc(
0,
sizeof(TCHAR)*lstrlen(g_pszDesktopPassword) + 1 );
   lstrcpy(pszPassword, g_pszDesktopPassword);

   // Return the password entered by the user
   // This is verified by the OS
    return pszPassword;
}

The password applet needs to provide a custom user interface, in the sample code the password is simply a choice of three colors. This example uses a standard dialog with a dialog procedure for handling messages, as shown in Figures 15 and 16.

Figure 15. A simple custom password applet, screen 1

Figure 16. A simple custom password applet, screen 2

Finally we need to be able to check, set, enable, disable and clear the password on the system. We can use the following password APIs to achieve this, as shown in Table 6.

Table 6. Password API

Method Description
SetPassword This method requires the old (or null) and new password to set the password.
SetPasswordActive Sets the current password to be active. Additionally the StartUI component can be configured to check if this is set during power on and the custom password CPL PromptForPasswd method called. See the Registry Settings to configure this.
GetPasswordActive Returns true if the password is active
PromptForPasswd If a password is active and the OS is set to check the password at power on, this exported method in the custom password CPL is called. It must return the password as a string which is validated by the OS. This string must be allocated with LocalAlloc and is freed by the OS.

Note this is not strictly a password API since it is your password provider being called by the OS.

Before we can use these password methods in our code, we need to explicitly link to them.

extern "C" {
BOOL SetPassword( LPWSTR lpszOldPassword, LPWSTR lpszNewPassword );
BOOL SetPasswordActive( BOOL bActive, LPWSTR lpszPassword );
BOOL GetPasswordActive();
}

Finally to deploy the custom password applet, copy the CPL file to the \Windows directory. Next we need to modify some registry settings to ensure the password is applied correctly, EG when connecting via Desktop ActiveSync or turning the device on, as shown in Table 7.

Table 7. Password Registry Settings

Key [HKLM\ControlPanel\Password]
Value "Redirect"=STRING:"\windows\SimplePassword.cpl"
Description This is required to redirect password checks to the custom password CPL. Note for Pocket PC 2002 the provider must be called password.cpl.
Key [HKLM\Security\Policies\Shell] (Pocket PC 2003)

[HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Shell] (Pocket PC 2002)

Value "ActivePeriod"=DWORD:<minutes>
Description The time in minutes before the password provider is displayed.
Key [HKCU\ControlPanel\Owner]
Value "PowrPass"=REG_BINARY:(0x00 or 0x01)
Description If this is set of 0x01, the power on password is enabled and PromptForPasswd is called by the OS, otherwise the password provider is not called on power on.

Note when installing a custom password provider on the emulator, the emulator file system picks up the updated CPL file and the Settings dialog is refreshed. On a device it is best to soft-reset the device after install to ensure the new CPL is displayed.The Let Me In: Pocket PC User Interface Password Redirect Sample provides an example of an alternative password provider, basing input on a list of points. It stores this list within the registry and has a fixed password string. This can be further secured by converting the list of points into a string and using this to derive a password, as shown in Figure 17.

Figure 17. The Let Me In power on password sample

The Let Me In sample requires eMbedded Visual C++ 3.0 and the Pocket PC 2002 SDK, and is compatible with Pocket PC 2003. For more information and to download visit the Let Me In: Pocket PC User Interface Password Redirect Sample page.

Smartphone Application Security

Smartphone provides an extra level of security in comparison to Pocket PC by disabling certain applications from installing or executing. This is achieved by signing applications or cab files with a certificate which is then verified by the application loader. Additionally the device can have two execution modes, privileged and unprivileged. Privileged execution has access to all APIs whereas unprivileged does not have access to some APIs such as some SIM functions. Generally the majority of applications run fine in unprivileged mode and if you require privileged execution, work with the mobile operator of the device to test on hardware. This security is shown in Figure 18.

The application loader is highly configurable and default settings vary between operators. For example the first Smartphone to market, the Orange SPV, only allows applications signed and trusted by Orange to execute, whereas the MPx200 on AT&T is open, allowing unsigned applications to execute.

Click here for larger image

Figure 18. Smartphone execution scenarios. Click the thumbnail for a larger image.

The application loader can check the hash value of the binary file against the revocation list and, if present, the certificate against the revocation list. If present in the revocation list then execution will fail. If signed with a certificate, this is checked against the privileged store and if found execution will be in privileged mode, otherwise if successfully checked against the unprivileged store, execution will be unprivileged. If the certificate chain is not verified against either store, the application is treated as unsigned.

For example if we wanted to enable all unsigned applications to run we could use the following XML document to change the security policy.

<!-- Sample XML to change unsigned applications device policy  -->
<wap-provisioningdoc>
   <characteristic type="SecurityPolicy">
      <!--
      Policy ID 4102
      Possible values
      1 - Unsigned applications are allowed to run on the device
      0 - Unsigned applications are not allowed to run on the device
      -->
      <parm name="4102" value="1" /> 
   </characteristic>
</wap-provisioningdoc>

Note that the security policy may be read-only on some devices, so for development and test purposes you will need to contact your operator to unlock the security policies.

If every operator provided different privileged and unprivileged root certificates, software houses would have to sign each application for every operator. To help promote applications which are certified Microsoft has installed Mobile2Market (M2M) root certificates on the Smartphone 2003 platform. If your application passes M2M certification you will need to sign the application via a certificate authority such as Verisign or GeoTrust. The application can then be packaged into a CAB install file, which will also need signing. Mobile2Market provides more than just a root certificates on Smartphone 2003 including user interface guidelines and a Mobile Application Catalog of logo certified applications.

For more information on Smartphone security read A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers on MSDN.

XML Device Management

One of the requirements for Smartphone 2002 was to provide XML Provisioning, an API to configure device settings. Configuration changes can be processed locally on the device by an application or remotely over the air (OTA) from a mobile operator. This infrastructure has been incorporated into both Pocket PC 2003 and Smartphone 2003 platforms. XML Provisioning is extremely flexible in what it can achieve and has is implemented with a single simple method, DMProcessConfigXML. The configurable list of Configuration Service Providers (CSPs) is large, ranging from browser favorite management, connection manager (GPRS, VPN, Proxy entries), e-mail, application management to registry manipulation. Note that Smartphone and Pocket PC differ with many common CSPs and some unique to each platform.

If you are an enterprise deploying many devices, then the CSPs should be of relevance as you could create an application which could setup e-mail accounts, configure WiFi, GPRS and VPN connections for users. Table 8 shows the CSPs for both Smartphone and Pocket PC. Many operators that sell Smartphone or Pocket PC Phone Edition devices bundle wizard applications that ask the user for a small amount of information and then configure e-mail, browser favorites and GPRS settings automatically using the CSPs.

Table 8. Configuration Service Providers

CSP Description Smartphone Pocket PC
BOOTSTRAP Sets the Trusted Provisioning Server (TPS) for the device. Yes Yes
BrowserFavorite Adds and removes URLs from the favorites list on a device. Yes Yes
CertificateStore Adds security certificates and role masks to the device's certificate store. Yes Yes
Clock Sets the time and date on the device. Yes No
CM_GPRSEntries Configures the General Packet Radio Service (GPRS) entries on the device. Yes Yes
CM_Mappings Configures the URL mapping table. Yes Yes
CM_ NetEntries Configures additional network entries on the device. For example Desktop Passthrough (DTPT) network entries. Yes Yes
CM_Networks Configures network connections on the device. Yes Yes
CM_Planner Configures the preferred connections for Connection Manager. Yes Yes
CM_PPPEntries Configures the Point-to-Point Protocol (PPP) entries on the device. Yes Yes
CM_ProxyEntries Configures proxy connections on the device. Yes Yes
CM_VPNEntries Configures the Virtual Private Network (VPN) entries on the device. Yes Yes
CM_WiFiEntries Configures the wireless network (WiFi) entries on the device. No Yes
EMAIL2 Configures Internet Protocol e-mail services for Pocket PC 2003 and Smartphone 2003 devices. Yes Yes
FileOperation Manages files and directories on the device, for example creating a shortcut. Yes No
Home Configures the Smartphone Home screen on the device. Yes No
Install Handles the installation and removal of applications including the loading and unloading of setup.dll. Yes Yes
LoaderRevocation Used to add, remove, and query certificate or binary hashes in the revocation list to prevent applications from starting. Yes No
Locale Configures regional settings on the device. Yes No
Metabase Used to add, modify, and remove entries from the metabase. Yes Yes
NAPDEF Adds, modifies, and deletes Wireless Application Protocol (WAP) network access point definitions (NAPDEFs) and their settings. Yes Yes
Obex Configures the Obex server, which performs Bluetooth and infrared beaming to enable/disable incoming infrared and Bluetooth beams. Yes No
PXLOGICAL Adds, removes, and modifies Wireless Application Protocol (WAP) logical and physical proxies. Yes Yes
Registry Configures the registry on the device. Yes Yes
SecurityPolicy Configures the security policy settings of the mobile device. See the Device Management Policies section under Standard Perimeter Security. Yes Yes
Sounds Configures the sounds associated with various events on the device. Yes No
Sync Configures the synchronization settings on the device. Yes Yes
TAPI Configures the GSM settings on the device, for example configuring call forwarding. Yes No
UnInstall Removes applications from the device. Yes No

Let's look at how easy it is to use CSPs and configure an e-mail account. All we need to do is create the XML provisioning document for the EMAIL2 CSP, call DMProcessConfigXML passing in the XML, an action flag and a pointer to an output buffer for the response XML. The action flag dictates if the XML provisioning document processes the XML (CFGFLAG_PROCESS) or should look at XML and return any metadata for the param elements (CFGFLAG_METADATA), for example retrieving security policies.

HRESULT      hr;               //result
TCHAR      *XmlIn = NULL;         //xml provisioning doc
TCHAR      *OutputBuf = NULL;   //ouput buffer

VERIFY(XmlIn = new TCHAR[600]);

//create the provisioning doc. in this case to add a new POP3 account
//look up "email2 csp" in sdk help index for full syntax
_tcscpy(XmlIn, TEXT("<wap-provisioningdoc>"));
_tcscat(XmlIn, TEXT("<characteristic type=\"EMAIL2\">"));
//each account on the device needs a unique GUID
_tcscat(XmlIn, TEXT("<characteristic type=\"{4FE84006-9E8A-4158-864D-A2E1E98C3787}\">"));
_tcscat(XmlIn, TEXT("<parm name=\"SERVICENAME\" value=\"MyPOP2\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"SERVICETYPE\" value=\"POP3\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"INSERVER\"    value=\"pop3.myserver.com\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"OUTSERVER\"   value=\"smtp.myserver.com\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"AUTHNAME\"    value=\"alias\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"AUTHSECRET\"  value=\"password\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"DOMAIN\"      value=\"mydomain\"/>"));
_tcscat(XmlIn, TEXT("<parm name=\"REPLYADDR\"   value=\"emailAddress@server.com\"/>"));
_tcscat(XmlIn, TEXT("</characteristic>"));
_tcscat(XmlIn, TEXT("</characteristic>"));
_tcscat(XmlIn, TEXT("</wap-provisioningdoc>"));

//process the provisioning doc and create the e-mail account
hr = DMProcessConfigXML(XmlIn, CFGFLAG_PROCESS, &OutputBuf);

All the CSPs can also be sent over-the-air (OTA) over SMS using a WAP push gateway or by using RAPI. Note that OTA messages are checked for a valid signature and may be discarded depending on security policy, see the Effect of Device Management Policies on the OTA Process.

In addition to the CSPs, Windows Mobile also has device management polices which can be set using XML. See the earlier section Standard Perimeter Security for more details.

RAPIConfig.exe

It is also possible to send the XML configuration over RAPI to the device using a command line tool, RAPIConfig.exe. This is located in the \Tools directory of the Pocket PC 2003 and Smartphone 2003 SDK.

For example the same e-mail configuration could be saved in an XML file

<!-- email.xml -->
<wap-provisioningdoc>
   <characteristic type="EMAIL2">
   <!-- each account on the device needs a unique GUID -->
      <characteristic type="{4FE84006-9E8A-4158-864D-A2E1E98C3787}">
         <parm name="SERVICENAME" value="MyPOP2"/>
         <parm name="SERVICETYPE" value="POP3"/>
         <parm name="INSERVER" value="pop3.myserver.com"/>
         <parm name="OUTSERVER" value="smtp.myserver.com"/>
         <parm name="AUTHNAME" value="alias"/>
         <parm name="AUTHSECRET" value="password"/>
         <parm name="DOMAIN" value="mydomain"/>
         <parm name="REPLYADDR" value="emailAddress@server.com"/>
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

Note that one of the CSPs is the device security policy, enabling policy changes via XML.

When then device is connected over ActiveSync, this XML can be provisioned to the device from the desktop using:

RapiConfig.exe /P /M email.xml

RAPIConfig.exe parameters

The format for RapiConfig is RAPICONFIG [/P] [/M] XmlDataFile. Table 9 shows the RAPIConfig.exe parameters.

Table 9. RAPIConfig.exe parameters

Parameter Description
/P This tells RapiConfig to process the xml configuration and make changes on the device.
/M This tells RapiConfig to return any metadata for the call. This is saved to the RapiConfigOut.xml file.
XmlDataFile This is the xml file containing the xml configuration document.

When using the /M parameter to return metadata, RapiConfig will process the contents of the XmlDataFile and then extract the metadata for the settings in the XmlDataFile. For example the email.xml document above would return the metadata for the characteristic type EMAIL2/{4FE84006-9E8A-4158-864D-A2E1E98C3787}.

<wap-provisioningdoc>
   <characteristic type="EMAIL2">
      <characteristic type="{4FE84006-9E8A-4158-864D-A2E1E98C3787}">
         <parm name="SERVICENAME" value="MyPOP2"/>
         <parm name="SERVICETYPE" value="POP3"/>
         <parm name="INSERVER" value="pop3.myserver.com"/>
         <parm name="OUTSERVER" value="smtp.myserver.com"/>
         <parm name="AUTHNAME" value="alias"/>
         <parm name="AUTHSECRET" value="password"/>
         <parm name="DOMAIN" value="mydomain"/>
         <parm name="REPLYADDR" value="emailAddress@server.com"/>
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

This can be useful to return current settings for a given CSP or device management policy. EG this would return the same metadata for the characteristic type EMAIL2/{4FE84006-9E8A-4158-864D-A2E1E98C3787}.

<wap-provisioningdoc>
   <characteristic type="EMAIL2">      
      <characteristic type="{4FE84006-9E8A-4158-864D-A2E1E98C3787}">
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

Custom Storage using File System Filters

Mobile devices are typically small, lightweight and low power, so fixed disk storage has not really been viable. Instead inbuilt file systems are RAM and ROM based. Many Pocket PCs and Smartphones provide extendable storage via Compact Flash (CF) or Secure Digital (SD) slots, which are formatted using the FAT file system.

Windows CE .NET 4.0 introduced the ability to plugin custom file system filters (FSF). These sit between the file system (memory file storage or storage card) and applications that use the file system. Using FSFs standard file system functions such as CreateFile and ReadFile, can be intercepted and extra processing applied. Good scenarios for FSF usage include virus scanners, encrypted storage or compression on a CF or SD card, so only a device with the correct installed FSF can read/write to the card.

The Storage Manager provides access to file stores and can work with a variety of sources including hard disk, CD-ROM and CF/SD. The Storage Manager can receive notification when storage devices come online (PnP), whereas the File System Driver (FSD) Manager works with all the installed FSDs and FSFs loading up partition drivers for a file system. When a CF or SD card is inserted, the Storage Manager receives a notification and then tries to load up the relevant FSD, during this process it will search the registry to see if there is an appropriate FSF it should load, as shown in Figure 19.

Click here for larger image

Figure 19. Storage manager architecture. Click the thumbnail for a larger image.

If it finds a FSF DLL, the StorageManager will call into the FSD_HookVolume providing the FSF with information about the underlying file system. Note it is possible to chain together FSFs, so an underlying file system may not be a real FSD but another FSF.

The sample code for this paper has an example FSF that encodes all data written and decodes all data read from a CF or SD card using simple XOR hash operation.

When our FSF loads, the FILTER_HookVolume method is called, notice we set a hash key value, this will be used when reading and writing data to the file system.

BYTE *hashkey = NULL;
PVOLUME FILTER_HookVolume(HDSK hdsk, FILTERHOOK *pHook) {
   VolumeState *pState;
   pState = new VolumeState;
   pState->hDsk = hdsk;
   memcpy( &pState->FilterHook, pHook, sizeof(FILTERHOOK));

   // Set hashkey for encryption/decryption
   GetHashKey();

   return (PVOLUME)pState;
}

Below is an example of intercepting the ReadFile method, note how it reads the data into a temporary buffer which is unhashed back to the original data using the hashkey. This is read into the output buffer and up to the calling application.

BOOL FILTER_ReadFile(PFILE pfh, 
LPVOID buffer, 
DWORD nBytesToRead, 
LPDWORD lpNumBytesRead,
LPOVERLAPPED lpOverlapped) 
{
   BOOL fSuccess = FALSE;
   HandleState *pHandle = (HandleState *)pfh;

   try {
      // Work with the buffer
      DWORD off =0;

      // Find the offset into the file. 
      off = pHandle->pHook->pSetFilePointer(pHandle->h,
                                    0,
                                    NULL,
                                    FILE_CURRENT);
      if (off != -1) {
         BYTE * unhashBuff = new BYTE[nBytesToRead];

         // Read the bytes into a temporary buffer.
         fSuccess = pHandle->pHook->pReadFile( 
                        pHandle->h,
                        unhashBuff,
                        nBytesToRead,
                        lpNumBytesRead,
                        lpOverlapped);

         // unhash data
         if (fSuccess) {
            div_t startpoint = div(off,hashkeysize);
            // iterate the buffer copying XOR with the hashkey
            for (long x = 0, y = startpoint.rem; x < *lpNumBytesRead; x++, y = (y<(hashkeysize-1)?y+1:0)) {                
               ((BYTE *)buffer)[x] = unhashBuff[x]  ^ hashkey[y];
            }
         } 
         else {
            // unable to read file
         }
         delete [] unhashBuff;
         unhashBuff = NULL;
      }
   }

   catch (...) {
      // failed somewhere
      fSuccess = false;
   }
    
   if (!fSuccess)   {
      fSuccess = pHandle->pHook->pReadFile( 
                     pHandle->h,
                     buffer,
                     nBytesToRead,
                     lpNumBytesRead,
                     lpOverlapped);
   }
return fSuccess;
}

The FSF project references header files which are not part of the standard SDK. To compile this project you need to have Windows CE.NET 4.2 Platform Builder installed and explicitly reference the OEM Adaptation Kit headers located in C:\WINCE420\PUBLIC\COMMON\OAK\INC. Figure 20 shows the user adding the OEM Adaption Kit include files.

For more information including where to download an Evaluation Kit read the Windows CE .NET Product Overview.

Click here for larger image

Figure 20. Adding the OEM Adaptation Kit include files. Click the thumbnail for a larger image.

Once the DLL has been built, it needs to be deployed to the \Windows directory on the device and the following registry keys created. The FSD Manager will search for these keys and load up the FSF.

Create the following values in Table 10 under the HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\Filters\<Name of your FSF> key.

Table 10. Values to create

Name Type Value
Dll String MyFSF.dll
Order DWORD 0

It is possible to chain multiple FSFs on a file system, they are executed in order of the Order value.

Note on Smartphone 2003 you cannot easily implement FSFs as it is not possible to create any keys under HKEY_LOCAL_MACHINE\System\StorageManager\FATFS unless you are running in privileged mode, see the Smartphone Application Security section.

To turn off a FSF, delete the registry key, in our example MyFSF as shown in Figure 21, or rename the Dll string value to an invalid file. When the device is soft reset the FSF will no longer be in memory.

Click here for larger image

Figure 21. Registry settings for FSF. Click the thumbnail for a larger image.

For more detailed reference see File System Filters in the Windows CE .NET 4.2 SDK help.

Using the FSF all data can be written to and read from the SD/CF card seamlessly. If the FSF is not installed, file operations still work, however an application will not understand the resulting data, as shown in Figures 22 and 23.

Figure 22. Viewing files with the FSF installed

Figure 23. Viewing files without the FSF installed

This example uses a basic XOR technique to lock down data on a CF or SD card, for a more secure solution use a session key (see the CryptoAPI section) or asymmetric encryption, for example write/encrypt with the public key, so only the device with the private key can read/decrypt the data. Asymmetric encryption is costly in processing power, so today this may not be viable for a file system. Who knows, if there is demand for mobile PKI applications we may see silicon vendors produce PKI hardware accelerators for mobile devices.

SQL Server CE Security

SQL Server CE is a small lightweight database for Pocket PC, providing rich ANSI SQL functionality and various connectivity options with SQL Server. There are two main areas to consider when securing SQL Server CE:

  • The database on the device. What would happen if someone managed to get hold of the database file?
  • Communications between the Pocket PC and remote database server. Is the user authenticated and is the channel secure?

Local Database Security

Local database files (typically with an SDF extension) can be created with file level encryption and given a password for access. The current release (version 2.0) only supports a single connection to a local database, there is no concept of users, so only a password is required to limit database access. This is specified on the connection string and should be applied when creating the database.

Note all source in this section is managed C# for use in Visual Studio .NET.

protected string connCE = @"Data Source=\mydata.sdf;Password=Hell0!";

Subsequent calls to the database should use the same connection string with the correct password.

SqlCeConnection conn = new SqlCeConnection(connCE);
conn.Open();
// Execute commands against connection
// ...
conn.Close();
conn.Dispose();

Attempts to open the database without the correct password will result in a SqlCeException exception being thrown, as shown in Figure 24.

Figure 24. Local file level database security

Note providing a password does not encrypt the database, it only prevents the database from being opened. To encrypt the database modify the connection string when the database is created to include encryption. The database is then encrypted using RSA 128-bit file level encryption.

protected string connCE = @"Data Source=\mydata.sdf;Password=Hell0!; encrypt database=TRUE";
SqlCeEngine engine = new SqlCeEngine(connCE);
engine.CreateDatabase();
engine.Dispose();

Channel Security

Many applications require SQL Server CE data communications with remote SQL Servers or other external data sources. There are four main routes provided as shown in Figure 25. Table 11 describes each of these routes.

Click here for larger image

Figure 25. SQL Server CE connectivity options. Click the thumbnail for a larger image.

Table 11. SQL Server CE routes and descriptions

Route Description
SQL Server Client Data Provider(SqlClient provider on CE Device) This provider is useful for executing directly against a SQL Server instance, requiring permanent connectivity.

Note the SqlClient provider does not use the SQL Server CE engine, instead this uses the Tabular Data Stream (TDS) for communication to a remote SQL Server instance. Typically for devices TDS packets are encapsulated in TCP/IP packets.

Web Services This route is not direct to SQL Server, allowing custom functionality such as business and data access classes. Uses HTTP.
Merge Replication Allows multi-client updates of data using both client and server SQL Server CE agents. Uses HTTP.
Remote Data Access (RDA) Enables clients to pull down a result set from a SQL statement, automatic tracking of changes and sending back changes to server. Uses HTTP.

Microsoft provides its own implementation of the TDS protocol is used extensively in the desktop/server environment and is designed for a closed environment.

The remaining connectivity options work over HTTP. If you are using Web Services to transmit data, it is possible to provide a custom secure channel implementation, for example using SOAP Headers and encrypting the SOAP Body, but this is a lot of work and potentially not standard (unless you write your own WS-Security client). The current recommendation is to use Secure Sockets Layer (SSL) to secure the HTTP channel, this also works for Merge and RDA models.

For more information on configuring channel security see Security Models and Scenarios for SQL Server 2000 Windows CE Edition 2.0 or Configuring Security for Connectivity on MSDN.

The next release of SQL Server CE brings a whole set of really cool new features including support for multiple concurrent connections and integration with the desktop SQL Server tools.

Conclusion

In this article we have looked at various techniques you can use to help secure Pocket PC and Smartphone deployment, some of this involving infrastructure, such as Exchange Server, PKI and 802.1X WiFi, and some involving developer techniques such as custom power on passwords, File System Filters, SQL Server CE along with platform capabilities such as Smartphone application security and XML Provisioning.

Threat Modeling

Not all applications and deployments will require the full range of security options available and will depend on many factors. For example how will the devices be deployed? If they are deployed externally then loss of the device may have a large impact. Are the communications between the device and other systems internal or external? Internal interfaces may have less likelihood of network snooping and easier tracing of network traffic and origin.

It is good practice to assign security as a feature for an application, starting from requirements/design through to deployment and support. Threat Modeling uses an iterative, multiple stage approach to find and document threats. This consists of identifying your assets, such as the data in your application or the mobile device itself. Then creating an architectural diagram where you can track your internal/external interfaces and what areas are trusted and to what level. With this information you can dissect the functionality to profile your application security, including entry points to the application, trust boundaries and data flows. This helps in documenting the risks to these profiles, including not just application threats but also host (device) and network threats. Finally you need to run a risk assessment on all the identified threats. Start with using the following method:

Risk = Probablility * Impact

Threat Modeling can help provide a thorough analysis of what can happen when your application goes out the front door. Repeating this process throughout the project lifecycle can mitigate the risk of attack.

For more information visit Threat Modeling on the Patterns & Practices site or check out the book Threat Modeling (Frank Swiderski and Window Snyder).

The Future's Secure

Microsoft is making investments in security on all platforms including Windows Mobile. PKI has been a core part of Windows Server 2000 onwards and with Windows Mobile we can now take more advantage on the client and leverage PKI down to mobile applications. For managed development the Microsoft .NET Compact Framework team is looking at increasing security features and providing cryptography support for future releases.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.