Secure e-mail with Windows Mobile 6

eXTReMe Tracker
Last update: Feb 19, 2008

Executive summary

Both Windows Mobile 5.0 and 6 support S/MIME secure e-mail. But:
  • Windows Mobile 5.0 and 6 do NOT support S/MIME with Internet standard compliant SMTP servers. You are forced to use Microsoft Exchange Server.

  • Windows Mobile 5.0's support of S/MIME is seriously flawed. Security is very low. You should not use it for secure e-mail (details).

1.1 Introduction

So you want to encrypt and/or sign e-mails on your Windows Mobile device. There are two dominant systems for secure e-mail: S/MIME and PGP. For PGP you would have to buy a third-party application such as PGP Mobile. Unfortunately this product has been discontinued, but PGP representatives told me that they are reconsidering their position and a new version may be in the pipeline. For S/MIME there are the following options:
There is very little documentation about using S/MIME on Windows Mobile 5.0 and 6. This webpage describes my experiences with it.

1.2 Author

The author of this document is Jacco de Leeuw (contact me). Corrections, additions, extra information etc. are much appreciated.


2. Contents

3. Background information

Windows Mobile 6 has built-in support for S/MIME secure e-mail. Windows Mobile 5.0 AKU 2 and later also support S/MIME. Devices running older versions of Windows Mobile 5.0 require an update from the vendor. Unfortunately, few vendors have released this "Messaging and Security Feature Pack" (MSFP) update for older Windows Mobile 5.0 devices. (Warning: if you install the MSFP update, it will wipe everything on your Windows Mobile device, including any personal certificates that you may have installed. Make sure that you keep a backup copy of your personal certificate on your PC before you install it on your Windows Mobile 5.0 device.)

There is very little documentation about this S/MIME feature (or it is well hidden!). I have attempted to write down some instructions that you can find below. Some informaton about S/MIME can be found in Microsoft's "Deploying MSFP" document (officially: "Deploying Microsoft Exchange Server 2003 SP2 Mobile Messaging with Windows Mobile 5.0-based Devices"). There is also a blog post by the Microsoft Exchange Server team.

If you don't own a Windows Mobile device you can download the standalone version of the Microsoft Device Emulator. Microsoft has released Windows Mobile 6 Localized Emulator Images for this emulator. These images contain S/MIME support.

3.1. Requirements and limitations

The S/MIME secure e-mail setup described in this section requires Windows Mobile 6 clients or Windows Mobile 5.0 clients with at least AKU2 (go to "Start" -> "Settings" -> "System" -> "About" to see what version you have). Exchange Server 2003 SP2 or later is also required, plus Windows Server 2000 or 2003 and possibly also ActiveDirectory with Windows Certificate Services. If you use Exchange Server 2007, you need to install Service Pack 1 because Microsoft "just didn't have time to complete [S/MIME support] by RTM". Certificates generated by independent software such as OpenSSL may or may not work, I have not yet tried. Note that some of these Microsoft products require purchasing separate Client Access Licences ("CALs") so your total cost of ownership may become a factor.

Sadly, Microsoft decided to not support S/MIME with SMTP, the Internet industry standard for e-mail. If your company or ISP uses another mail server than Exchange you will not be able to use the features "Encrypt message" and "Sign message" in Windows Mobile's "Messaging" application. The option "Security" is ghosted. This is clearly an example of vendor lock-in. It is an attempt by Microsoft to lock Windows Mobile users into Exchange and their other product offerings. I cannot think of a technical reason why Microsoft could not support SMTP for secure e-mail. Storing certificates on mobile devices takes valuable memory, but most certificates are only 1-2 KB. The least they could have done is use open standards such as LDAP for looking up certificates of recipients. (There is a "Check Names" option in WM6 where you can lookup names in an online server but I don't know if that means LDAP and if certificates are actually checked).

Microsoft does kind of support S/MIME with POP3 (and probably IMAP4 too) on Windows Mobile 6. You can receive encrypted e-mail and signed e-mail, but not send them, with Internet standard protocols. When you receive a signed e-mail, the signature is ignored. No indication is displayed about the status of the signature. When you receive an encrypted e-mail, the e-mail is decrypted automatically but there is no indication that the e-mail was encrypted. So the practical use of S/MIME with POP3 and IMAP4 is close to zero. Receiving encrypted e-mail does work because when you delete the personal certificate from your device the encrypted e-mail can no longer be decrypted.

After disabling SSL I examined the network traffic between the Windows Mobile device and Exchange server. The communication between client and server appears to be based on HTTP(S), WebDAV and WBXML. Fortunately Windows Mobile does not appear to offload cryptographic operations or send private keys to the Exchange server, but it does delegate some trust operations to it. I don't know if any of the free Open Source competitors can be used with Windows Mobile for secure e-mail.

3.2 WM5 security flaw

Windows Mobile 5.0 with the MSFP update supports S/MIME but it contains a security flaw. I discovered that WM5 uses the RC2 algorithm to send encrypted e-mail, as is evident in this screenshot of a test e-mail sent from WM5 to Outlook 2003. RC2 is known to be flawed. Well-known cryptographer Bruce Schneier recommends against using it. To make matters worse, WM5 uses only a 40-bits key. Therefore e-mails sent with WM5 are relatively easy to decrypt by adversaries. The problem lies only with sending encrypted e-mail because WM5 can decrypt received e-mails that were encrypted with 3DES (a much stronger algorithm). It looks like Microsoft purposely chose RC2-40 for maximum compatibility with other S/MIME clients, at the expense of security. Bad move.

Microsoft has been informed of this issue. It has been fixed in WM6: e-mails are encrypted with 3DES in WM6. But Microsoft says they will not release an update for WM5.0 users, nor will they inform users about the existence of this problem. There is a workaround: if you set the "Encrypted Mail Policy" (4126) to "2", WM5.0 will use 3DES instead of RC2. Unfortunately, this workaround requires every(!) e-mail to be encrypted, which will be unacceptable for most users. S/MIME support was added to WM5.0 on the request of certain organisations with high security requirements, that did not mind encrypting each and every e-mail.

Microsoft claims that the S/MIME component in Windows Mobile 5.0 is FIPS 140 compliant. If they use RC2, I don't see how they got their FIPS certification as RC2 is non-approved by FIPS. In a nutshell: do not use WM5 for sending S/MIME encrypted e-mails!

Back to Contents


4. Secure e-mail: initial configuration

Before you can send or receive secure e-mail with your Windows Mobile device you need to configure a few things. First, you will have to configure your mail server and then your mail client.

4.1 Configuring your Windows Server, IIS and Exchange Server

For documentation on how to configure Exchange Server 2003 or higher for secure messaging, see the Microsoft website. See also Daniel Petri's articles "How can I Synchronize a Pocket PC with Exchange Server 2003?" and "Problems in Synchronizing a Pocket PC with Exchange Server 2003 when using SSL and Forms-Based Authentication in OWA".

4.2 Installing a personal certificate on your Windows Mobile device

An installed personal certificate is required if you want to send signed e-mail or decrypt encrypted e-mail on your Windows Mobile device. A personal certificate (also known as a client certificate) can be obtained through different methods:
Most users will already have a personal certificate on their desktop PCs. Additionally, many third-party CAs such as Thawte, Verisign and CAcert only support desktop operating systems such as Windows, Mac OS X and Linux. So probably the simplest solution would be to export your existing personal certificate from your desktop PC to a (password protected) certificate file, and then import this certificate file on your Windows Mobile device. The PKCS#12 format is the most popular format for certificate files. WM6 supports PKCS#12: you can import these files without having to install extra software. But for WM5 you need a certificate import program such as PFXimprt.

For details about installing a personal certificate for S/MIME on Windows Mobile 6, see my webpage "Installing certificates on Windows Mobile 6".

Web enrolment is a completely different method. According to the "Deploying MSFP" documents, ActiveSync 4.1 and higher support web enrolment. You connect your device (running WM5 AKU2 or higher) to your desktop PC and then the device retrieves a certificate from the certificate authority while connected through ActiveSync. Unfortunately, the setup described in the "Deploying MSFP" document is very complex. I have not been able to get it working. It involves generating XML, using Rapi and installing CAB files. Ask your vendor (or contact Microsoft Support) if you run into problems with the setup described in the "Deploying MSFP" document.

Web enrolment is also supported by ActiveSync 4.5. It appears to be different (read: less complex and it actually works for me) from the setup described in the "Deplying MSFP" document. But there is a drawback: it only works with devices running WM6 or higher. More details can be found on my other webpage.

4.3 Configuring ActiveSync on your Windows Mobile device

For S/MIME you have to use ActiveSync to synchronise your Windows Mobile device with an Exchange server. Securing the connection with SSL is optional (but highly recommended; see the next section for that).
On Smartphone the procedure is slightly different: ActiveSync -> Menu -> Configure Server -> (enter server address) (require SSL connection) -> Next -> (enter username / password) -> Next -> Options -> (select E-mail) -> Menu -> Settings -> Menu -> Advanced -> Menu -> Choose Certificate -> Select a Certificate.

4.4 Configuring ActiveSync with SSL (optional)

It is probably a good idea to secure the ActiveSync connection with SSL (note that this is unrelated to the actual signing and encrypting of e-mails with S/MIME).

For SSL you will need a CA and a server certificate from this CA for the IIS / Exchange server. There are two options: either you create your own root and server certificates (free) or you buy a server certificate from a commercial CA. If you create your own certificates, you need to use File Explorer to install your root certificate on all Windows Mobile devices involved. If you have a large number of Windows Mobile clients this may turn out to be a bit of a hassle. In that case you could simply give up, pull your wallet and buy a server certificate from one of the few "trusted" root certification authorities that are present in Windows Mobile devices. In WM5 these are Cybertrust, Geotrust, GlobalSign, Entrust, Thawte and Verisign. The MSFP update for WM5 adds root certificates from Valicert and GoDaddy to this list. And WM6 adds the following: AAA Certificate Services, AddTrust External CA Root, Baltimore CyberTrust Root, GeoTrust Global CA and Starfield Class 2 Certification Authority.

Next, in the IIS Manager, expand "Default Web Site". Click "Properties" and then "Directory Security". Assign the server certificate by clicking "Server Certificate". Afterwards, you can view the one that you selected with "View Certificate". Go to "Microsoft-Server-ActiveSync" and select Properties -> Directory Security -> Edit -> Require SSL. This will secure the ActiveSync connection. ("Enable client certificate mapping" may be required?)

If the server does not have a server certificate or the client does not have a suitable root certificate you may encounter an error with support code 0x80072F0D: "The security certificate on the server is invalid. Contact your system administrator or ISP to install a valid certificate on the server and try again." You need to install a server certitificate on the Exchange server and possibly a suitable root certificate on the client (if you import a personal certificate from a PKCS#12 file the root certificate is often included in that file).

Note: do not install the certificate of the server on your Windows Mobile device! That is plain wrong, even though the Windows Mobile (5.0) device happily installs the server certificate in the root certificate store (which is a bug in my opinion, because the certificate is not self-signed).

Back to Contents


5. Secure e-mail: sending and receiving with Windows Mobile

Now that you have configured your Windows Mobile device and the Exchange Server, you can continue with sending and received encrypted and signed e-mail.

5.1 Sending a signed e-mail to another person

I will start with the procedure for sending signed e-mail, followed with the other procedures (in suspected order of complexity).
 5.2 Receiving an e-mail encrypted by another person
5.3 Receiving an e-mail signed by another person

Windows Mobile can check if the signature attached to a signed e-mail is valid. It does this by going online and asking the Exchange server whether the signature is valid. For some reason Windows Mobile does not check the signature against its own list of root certificates! Again, this proprietary online check only ties Windows Mobile to Exchange which means that you cannot use any other mail server. Windows Mobile asks the Exchange server to see if the root CA that issued the sender's certificate is available in the root certificate store of the Exchange server (in the "Computer" account). If the sender's certificate was not issued by one of the "well-known" CAs such as Thawte or Verisign, you may need to import a root certificate to the Trusted Root Certificates Authorities on that server. For example, in the previous screenshot I imported the root certificate of CAcert. See also "How to Import the Digital Certificate for the Sender's Root CA into the Trusted Root Certification Authorities Folder in the Local Computer Certificate Store of the Recipient's Exchange Server". Screenshots of this procedure can be found on  Thomas Shinder's TACteam site.

Windows Mobile will go on-line and consult the Exchange server to check if the sender's certificate is valid. I don't know exactly what it does but it appears to forward the sender's certificate to the server. So it seems to delegate some trust to the server. I have not checked if Exchange actually verifies the sender certificate's revocation status, e.g. against a CRL or with OCSP.

The remainder of this section describes how you can validate the signature of a signed e-mail:
5.4 Sending an encrypted e-mail to another person

If you want to send an encrypted e-mail to a person you will need that person's personal certificate. (Note that you do not need the person's private key, because private keys are private, as the name implies. Do not install the other person's personal certificate on your device). On desktop e-mail clients such as Mozilla Thunderbird and Outlook (Express), the usual way for obtaining the recipient's personal certificate is that the recipient first sends you a signed e-mail. Alternatively, the recipient's certificate is looked up in a directory server. Once you have obtained this person's certificate you can send him an encrypted e-mail. These desktop e-mail programs automatically store certificates from received e-mail, mostly in some sort of certificate manager (e.g. in the "Other People's" list).

It does not work that way at all on Windows Mobile. You can only send encrypted e-mail if the recipient's certificate has been published in the Global Address List (GAL). This feature is exclusively supported by Exchange so again this is an example of vendor lock-in.

How does one get certificates into this GAL? As far as I know there are only two options. The first option is to use the desktop version of Outlook 2000 or later. In in the menu Tools -> Options -> Security, click "Encrypted e-mail: Settings..." Import a personal certificate from a PKCS#12 file or "Get an ID" from a CA of your choosing. Click OK. Click "Publish to GAL". The second option to publish certificates in the GAL is to use Windows Certificate Services on the Exchange server. Those certificates are automatically published in the GAL. Windows Certificate Service also seems to be required when you use the first option ("Publish to GAL"), because when I had installed Exchange but not Certificate Services, there was no "Publish to GAL" button. Only after I had installed Certificate Services (Start -> System -> Add or remove programs -> Add/remove Windows components) the button was displayed in Outlook.

The remainder of this section describes how you can send encrypted e-mail, once the requirements mentioned above have been met:
5.5  Combinations of the above

You can also sign and encrypt e-mail messages to others at the same time. Or decrypt and verify signatures.

Back to Contents


6. Assorted remarks

6.1 Creating certs with OpenSSL

Windows Mobile 6 appears to support certificates that were not generated by Windows Server (I am not so sure about WM5 but that is probably not a good idea anyway). I have tried WM6 with third-party certificates such as those from Thawte, Comodo and Trustcenter, and also with my own OpenSSL generated certificates. It is probably a good idea to add the following parameters to your openssl.cnf configuration file, because certificates generated by Microsoft Certificate Services have these properties too:
[ usr_cert ]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = 1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4, 1.3.6.1.4.1.311.10.3.4
subjectAltName=email:copy
Here is a sample personal certificate generated by Microsoft Certificate Services on Windows Server 2003. You could try to generate your own certificates with OpenSSL and mimic this sample certificate for maximum compatibility.

6.2 Trustcenter bug

There is a bug in PFXimprt which pops up with free personal certificates issued by Trustcenter. For more details see the PFXimprt page. In a nutshell: use P12imprt instead.

6.3 Comodo intermediate cert

Comodo issues personal certificates for free. Its root CA ("UTN-USERFirst-Client Authentication and Email") is not included in WM5 or WM6. But it has been signed by "AddTrust External CA Root", which is included in WM6. Therefore if you import your Comodo personal certificate on WM6 you will get an error about the AddTrust root certificate. This certificate cannot be overwritten. It will work nonetheless, just skip importing this particular root certificate. On WM5 you may prefer to include only the UTN root certificate in your PKCS#12 file (and not the AddTrust root certificate). The UTN certificate will then be imported as a root certificate instead of an intermediate certificate, as the case would be on WM6.

6.4 AES

I don't know if WM6 supports AES encryption with S/MIME. This would probably mean support for "S/MIME Capabilities" where the sender of a signed e-mail indicates which algorithms it supports. WM6 ships with AES support but for some reason it is not used with all protocols (e.g. not with L2TP/IPsec).

Back to Contents


7. Certificate based ActiveSync authentication

In the previous sections certificates were used for secure messaging with S/MIME. However, certificates can also be used for authentication when ActiveSyncing to the Exchange / IIS server ("Exchange ActiveSync" or EAS). The ActiveSync connection is an SSL connection, after all, so the use of client certificates are optional. See this section on my other webpage.

Back to Contents


8. Acknowledgements and disclaimers

My crack team of lawyers advised me to include the following text. This page shows screenshots of a device resembling a Pocket PC but this does not necessarily mean an endorsement of or by any company. I disclaim everything anyway :-). Windows, Windows Mobile, Pocket PC and Windows CE are trademarks of Microsoft Corporation. The author of this webpage is not associated with Microsoft or any other company mentioned on the page. All trademarks are owned by their respective companies.

Back to Contents


9. Revision history

Jun 6, 2007: S/MIME problem resolved in P12imprt v0.3 and Crtimprt v0.3.
May 31, 2007: Tested with Thawte, Comodo certs.
May 24, 2007: Initial version.

Jacco de Leeuw