Certificates for Windows Mobile 5.0 and Windows Mobile 6
6/2/2010
Digital certificates play a significant role in network authentication and in helping to secure a device. Certificates are electronic credentials that bind the identity of the certificate owner or the device to a public and private pair of electronic keys used to encrypt and digitally sign information. Signed digital certificates assure that the keys actually belong to the specified application, device, organization, or person and that they can be trusted.
Digital certificates are used on Windows Mobile powered devices in two essential roles:
- In code signing, determining whether an application can be run on the device and if so, the permissions (privileged or normal) with which it will run.
- In authentication, presenting trusted credentials for connecting to a corporate e-mail server or network or verifying the identity of a remote server.
For example, in order for an application to be installed and run on the device, the application must present a digital certificate that proves it was accepted and signed by a trusted source, such as the Mobile2Market program. In an authentication example, before an SSL connection can be established with the network server, the mobile device must present a certificate from its root store that is recognized and accepted by the server.
Mobile2Market is the Microsoft certification and marketing program for mobile applications for independent software and hardware vendors. This program, in conjunction with privileged certificate authorities, allows application developers to distribute their applications across the vast majority of Windows Mobile-powered devices while working with a single certificate authority and maintaining just one signed version of their application.
Certificates Shipped on Windows Mobile Powered Devices
By default, Windows Mobile-powered devices are shipped with a variety of certificates:
- Trusted root certificates from major certificate vendors that can be used for authentication purposes.
- Mobile2Market and other trusted certificates that designate applications that are signed for use on Windows Mobile devices.
- Additional certificates that may be added by the OEM or network carrier.
The following table lists the certificates shipped Windows Mobile powered devices that run Windows Mobile 5.0 at this printing.
| Vendor | Certificate name |
|---|---|
Cybertrust |
GlobalSign Root CA |
Cybertrust |
GTE CyberTrust Global Root |
Cybertrust |
GTE CyberTrust Root |
Verisign |
Class 2 Public Primary Certification Authority |
Verisign |
Thawte Premium Server CA |
Verisign |
Thawte Server CA |
Verisign |
Secure Server Certification Authority |
Verisign |
Class 3 Public Primary Certification Authority |
Entrust |
Entrust.net Certification Authority (2048) |
Entrust |
Entrust.net Secure Server Certification Authority |
Geotrust |
Equifax Secure Certificate Authority |
Godaddy |
http://www.valicert.com/ |
The following table lists the certificates shipped with devices that run Windows Mobile 6 at this printing.
| Vendor | Certificate name |
|---|---|
Comodo |
AAA Certificate Services |
Comodo |
AddTrust External CA Root |
Cybertrust |
Baltimore CyberTrust Root |
Cybertrust |
GlobalSign Root CA |
Cybertrust |
GTE CyberTrust Global Root |
Verisign |
Class 2 Public Primary Certification Authority |
Verisign |
Thawte Premium Server CA |
Verisign |
Thawte Server CA |
Verisign |
Secure Server Certification Authority |
Verisign |
Class 3 Public Primary Certification Authority |
Entrust |
Entrust.net Certification Authority (2048) |
Entrust |
Entrust.net Secure Server Certification Authority |
Geotrust |
Equifax Secure Certificate Authority |
Geotrust |
GeoTrust Global CA |
Godaddy |
Go Daddy Class 2 Certification Authority |
Godaddy |
http://www.valicert.com/ |
Godaddy |
Starfield Class 2 Certification Authority |
Certificate Stores
The certificates in a Windows Mobile powered device are located in the certificate store in the registry.
The certificate Root and Certificate Authentication (CA) stores on Windows Mobile 5.0 devices are locked to everyone except those with Manager role permissions to help ensure the integrity of the digital certificates.
In Windows Mobile 6, the certificate stores have been expanded with separate User Root and CA stores to allow device users with the less-powerful authenticated user permissions to add or to enroll for trusted digital certificates. The system Root and CA stores remain locked without Manager or Enterprise role permissions.
The following table shows the certificate stores and their uses and permissions.
| Certificate store | Physical Store | Description |
|---|---|---|
Privileged Execution Trust Authorities |
HKLM |
Contains trusted certificates. Applications signed with a certificate from this store will run with privileged trust level (Trusted). |
Unprivileged Execution Trust Authorities |
HKLM |
Contains normal certificates. On a one-tier device, an application signed with a certificate in this store will run with privileged trust level (Privileged). On a two-tier device, applications signed with a certificate from this store will run with normal level (Normal). |
SPC |
HKLM |
Contains Software Publishing Certificates (SPC) used for signing .cab or .cpf files and assigning the correct role mask to the file installation. |
Root (system) |
HKLM |
Contains root certificates, which can be certificates signed by Microsoft, the OEM, or the Mobile Operator. These certificates are used for SSL server authentication. These cannot be changed without Manager role permissions. Users with Manager role can add certificates in this store. OMA-DM transport client only checks this store for root certificates when establishing an SSL connection. |
Root (user) |
HKCU |
Applies to Windows Mobile 6: Contains root, or self-signed, certificates that can be installed by someone with Authenticated user role. |
CA (system) |
HKLM |
Contains certificates and information from intermediary certification authorities. They are used for building certificate chains. In Windows Mobile 5.0, users with Manager role can add certificates in this store. OMA-DM transport client only checks this store for intermediate certificates when establishing an SSL connection. Applies to Windows Mobile 6: Certificates are added to this store by Microsoft, the OEM, or the Mobile Operator. |
CA (user) |
HKCU |
Applies to Windows Mobile 6: Contains certificates, including those from intermediary certification authorities, which can be installed by the device user with Authenticated User role. They are used for building certificate chains. |
MY |
HKCU |
Contains end-user personal certificates used for certificate authentication or S/MIME. |
Adding Certificates to Windows Mobile Powered Devices
Because digital certificates are a key component of the Windows Mobile security model, there are restrictions on the permissions and requirements for adding and managing certificates.
The processes and tools for adding and managing certificates are different for Windows Mobile 5.0 and Windows Mobile 6.
Installing Certificates on a Windows Mobile Devices that run Windows Mobile 5.0
Network managers and device users can place additional certificates on Windows Mobile 5.0 devices if they have either Manager permission on the device or have the ability to run trusted code.
OEMs and mobile operators determine the security policies shipped on their devices. Confer with your device vendor or mobile operator to ensure that the devices you intend to purchase will either work with the certificates you currently have deployed, that you can add the necessary certificates, or that you can replace your certificates in a cost-effective fashion.
If you wish to install root certificates for certificate-based authentication, you can use the tool for deploying Exchange ActiveSync certificate-based authentication; it can be downloaded from the following Microsoft Download center Web site. https://go.microsoft.com/fwlink/?LinkId=54738.
For more information, see the Microsoft Knowledge Base article, How to install root certificates on a Windows Mobile-based device available at the following Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=89647.
Note
Windows Mobile 5.0 does not support the use of wildcard certificates for device-to-server authentication. This restriction applies to all communications, including Exchange ActiveSync.
Note
In Windows Mobile 5.0, users cannot disable SSL checking for Exchange ActiveSync (EAS) by running the certchk tool because it was being used to circumvent SSL security.
Installing a Root Certificate on a Windows Mobile Powered Device Powered device
- Convert the root certificate (.cer) to a Base-64 Encoded x.509 certificate.
- Create a provisioning file to install the certificate on the device.
- Deliver the certificate to the device.
Converting the Root Certificate
You must first find the desired root certificate, import it, and then export it so that it can be passed to the mobile device.
To convert the certificate
Open Microsoft Management Console, and then expand the Certificates – Current User node. If the node does not appear, you need to add the Certificates snap-in.
Choose Personal, and then double-click Certificates.
On the Action menu, point to All Tasks and then choose Import.
Follow the onscreen instructions to import the root certificate, and do the following:
- Import the root certificate file (.cer) as a x.509 certificate (*.cer;*.crt) file.
- Add the imported root certificate to the Personal certificate store displayed in Microsoft Management Console.
Choose the imported root certificate.
On the Action menu, point to All Tasks and then choose Export.
Follow the onscreen instructions to export the root certificate, and then do the following:
- Export the root certificate as a base-64 encoded X.509(.CER) file.
- Save the exported certificate file in the same folder as the imported certificate file.
Creating a Provisioning File
This XML file includes the instructions and specific locations for adding the certificate to the desired certificate store on the device.
Note
Your provisioning XML must not contain Byte Order Markers (BOM). Use a text editor that does not insert BOMs when saving files in UTF-8 format.
Create a provisioning file
Add the following XML code to a document:
<wap-provisioningdoc> <characteristic type="CertificateStore"> <characteristic type="ROOT"> <characteristic type="CERTHASH"> <parm name="EncodedCertificate" value="BASE64ENCODEDCERT"/> </characteristic> </characteristic> </characteristic> </wap-provisioningdoc>Replace STORELOCATION with ROOT.
In Windows Explorer, double-click the exported root certificate.
Choose the Details tab.
Choose Thumbprint in the list box, select the text, and then press CTRL+C.
In the XML code, to add the root certificate thumbprint to the provisioning XML, replace CERTHASH with the copied text.
Delete the spaces in the thumbprint text.
Open the exported root certificate using a text editor.
Delete BEGIN CERTIFICATE and END CERTIFICATE, and then remove line breaks from the remaining text. This text is the encoded contents of the root certificate.
Select the text, and then press CTRL+C.
In the XML code, to add the root certificate to the provisioning XML, replace BASE64ENCODEDCERT with the copied text. The completed provisioning XML document will appear as shown in the following example.
<wap-provisioningdoc> <characteristic type="CertificateStore"> <characteristic type="ROOT"> <characteristic type="{hash of certificate}"> <parm name="EncodedCertificate" value="{encoded hash of certificate}"/> </characteristic> </characteristic> </characteristic> </wap-provisioningdoc>Save the XML document as an ASCII file named _setup.xml.
Delivering the Certificate
You can deliver the completed provisioning file to a Windows Mobile-powered device using any one of the following means:
- Over the air using an OMA DM Server
- Over the air using an OMA Client Provisioning (formerly WAP Client Provisioning) server
- Wrapped in a .cpf file and sent by using Internet Explorer Mobile, ActiveSync, SI/SL, or Storage Card.
Note
Microsoft recommends that you provision the device using over-the-air (OTA) methods when possible. If you must deliver the XML in a file, we recommend that you package and sign provisioning documents in the CAB Provisioning Format (.cpf). An XML provisioning document may not install on a Windows Mobile-powered device if the file containing the document is not signed.
Note
Cabinet files and each DLL and executable within a cabinet file must be signed, including resource-only DLLs.
Installing Certificates on a Device That Runs Windows Mobile 6
In Windows Mobile 6, the Mobile Operator or Enterprise IT Professional can create a CAB file with a certificate appropriate for use within the corporation. The Manager or Authenticated user role can use this CAB file to add certificates to the user (HKCU) Root and CA stores on the device.
Note
Windows Mobile 6 supports the use of wildcard certificates for device-to-server authentication.
The certificate installer on Windows Mobile 6 devices will install certificates delivered in the following file formats:
- PFX/.P12 – Public-Key Cryptography Standards #12 (PKCS #12) format files that include personal certificates with private keys as well as certificates that install into the intermediate and root certificate stores.
- CER – Base64-encoded or DER-encoded X.509 certificates that install into the intermediate and root certificate stores.
- P7B - Public-Key Cryptography Standards #7 (PKCS #7) format files that install multiple certificates to any certificate store on the device.
The files can be delivered to the device via desktop ActiveSync, removable storage card, e-mail attachment, or Mobile Internet Explorer file download. Windows Mobile 6 Professional devices also allow download from a file share. When the file is opened from the file explorer, the certificate installer processes and installs the file automatically. The following table shows what kinds of certificates and keys the different types of files support.
| File Type | Private key support | Installs a certificate chain | Installs only one certificate | Installs multiple certificates (can include chains) |
|---|---|---|---|---|
.PFX/.P12 |
Yes |
Optional |
Optional |
Yes |
.CER |
No |
No |
Yes |
No |
.P7B |
No |
Optional |
Optional |
Optional |
Certificate Enroll operation |
Yes |
Yes |
No |
No |
Certificate Chains
A certificate chain consists of all the certificates needed to certify the subject identified by the end certificate. In practice this includes the end certificate, the certificates of intermediate CAs, and the certificate of a root CA trusted by all parties in the chain. Every intermediate CA in the chain holds a certificate issued by the CA one level above it in the trust hierarchy. The root CA issues a certificate for itself.
Algorithm for Adding Certificate Chains
When importing the certificate for a client, the certificate chain may be included in the .PFX file. This enables the device to authenticate the intermediate and root certificates associated with the end certificate. All certificates in the chain will be added to the appropriate certificate stores on the device in order to enable trust validation.
If the chain certificates are included in the .PFX file, the application processes the chain certificates as follows:
- Store the subject certificate in the MY certificate store. The subject certificate has a public key associated with the private key that is being added to the device as a part of the PFX import.
- Check for existence and install any certificate that meets both of the following requirements into the ROOT Certificate store,
- The certificate is self-signed by its own private key.
- The issuer of the certificate is the same as the subject of the certificate.
- Check for the existence of and install any other certificates provided in the chain (intermediate certificates) to the CA certificate store.
Certificate-based Authentication
Windows Mobile 5.0 with MSFP and later devices can use SSL with Transport Layer Security (TLS) client authentication in place of SSL basic authentication. Certificate-based authentication offers a potential security advantage over the use of single-factor password-based authentication. This advantage comes from two factors. First, the strength of the key is pre-determined by the administrator and can be very strong. Windows Mobile and Windows Server together support up to 2,048-bit keys. Second, requiring certificate-based authentication greatly reduces the risk that a user’s credentials will be compromised. A user can’t “loan out” their password, and an attacker who can sniff over-the-wire traffic won’t be able to recover usable credentials.
To use certificate-based authentication with Windows Mobile, the mobile device must contain the root certificate for the Exchange Server front-end or client access server it’s communicating with; the mobile device must also have its own client user certificate with the associated private key. The user certificate enrollment process can only occur when the device is connected to a desktop in the same domain as the enrollment web site.
Certificate-based Authentication for Windows Mobile 5.0
The certificate enrollment process for Windows Mobile 5.0 MSFP devices uses ActiveSync desktop to connect to the corporate CA to receive the required user certificate and associated key. Once the user certificate and key are on the device, cradling with Desktop ActiveSync 4.1 or later is required only to renew the certificate when it expires.
Microsoft has created a tool for deploying Exchange ActiveSync certificate-based authentication; it can be downloaded from the following Microsoft Download center Web site. https://go.microsoft.com/fwlink/?LinkId=54738.
For an overview of setting up certificate-based authentication for use with Windows Mobile and Exchange ActiveSync, see Appendix A, Overview of Deploying Exchange ActiveSync with Certificate-Based Authentication, of the Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2, available at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=81200.
Certificate-based Authentication for Windows Mobile 6
With Windows Mobile 6, the process for implementing Transport Layer Security (TLS) certificate-based authentication has been streamlined and made easier to maintain. The system administrator creates a certificate type and makes it available through Active Directory. The user then authenticates to the network, navigates to the designated location, and the client user certificate with the associated encrypted private key is passed to the user’s device.
Note
Wildcard certificates or certificates not supplied by a Microsoft Certificate Authority Server can be used with devices that run Windows Mobile 6.
Managing Certificates with the CertificateEnroller Configuration Service Provider
Applies to Windows Mobile 6
The CertificateEnroller Configuration Service Provider in Windows Mobile 6 devices enables you to generate certificates and associate them with a key pair to produce and install trusted certificates for your mobile devices. You can define each certificate type and publish them for other client devices and servers in your corporate network. The CertificateEnroller also provides management and certificate renewal features.
Using the CertificateEnroller Configuration Service Provider with the SECROLE_USER_AUTH role on a device, you can add, delete, or query certificates in the HKCU (User) CA and ROOT certificate stores. If SECROLE_USER_AUTH is granted the SECROLE_MANAGER on the device, you can also add certificates to the HKLM (system) certificate stores. For more information about the certificate stores on mobile devices, see Certificate Management in Windows Mobile Powered Devices.
The CertificateEnroller Configuration Service Provider allows you to
- Configure a certificate type
- Configure a certificate type and trigger device enrollment
- Securely enroll for a certificate using a pre-configured certificate type
- Query for and renew existing certificate types
The CertificateEnroller will download the full chain of certificates including the root and any intermediates by requesting the .pb7 file from the certificate server. The path to the file is specified in ServerPickupPage parameter of the CertificateEnroller Configuration Service Provider.
Note
This Configuration Service Provider can be managed over both the OMA Client Provisioning (formerly WAP Client Provisioning) and the OMA DM protocol.
Using the Desktop ActiveSync, your device users can install the certificate from the corporate server to their cradled Windows Mobile-powered device. The existing corporate desktop logon procedure -- password, smartcard, or other means of user identification, authenticates the enrollment, streamlining the distribution of the certificate/encrypted key pair.
Using Desktop Enrollment
To prepare for using desktop certificate enrollment, the system administrator should do the following:
- Set up or have access to a Windows 2000, 2003 or later Windows Certificate Server.
- Create the certificate type or use an existing certificate published to Active Directory.
- Inform users of the location of the certificate on the corporate network.
- Provide users with instructions for using the Get Device Certificate user interface.
Once you have published the certificate to Active Directory and directed the users to enroll for the certificate, the users will step through the following process:
To enroll for a certificate with a device that runs Windows Mobile 6
From Advanced Tools, the user chooses Get Device Certificate, navigates to Active Directory on the corporate network, selects the desired certificate, and clicks Add.
The desktop processes the enrollment while the user waits a short period of time. During this time, the device generates a public/private key set and proxies the enrollment to the Windows Certificate Server through the desktop.
The CA returns a signed certificate to the desktop which, in turn, delivers the certificate to the device.
The device stores the certificate and its chain of certificates to the root CA. If the root certificate is not already in the root certificate store of the device, the user is asked to accept the certificate.
The user sees a success dialog to denote the end of the enrollment process.
Once the certificate is in the user Root or CA store, the mobile device will be ready to authenticate with the desired protocol.
Revoking a Certificate for a Signed Application
The certificate model allows you to stop applications from executing by revoking the certificate used to sign the application. This is helpful if a malicious signed application was installed on the device, or you do not want users to use a particular application.
With revocation, you can block a specific application or group of applications from running on the device:
- A whole class of applications or all applications from a specific ISV can be blocked by revoking a code-signing certificate or a Certificate Authority (CA) certificate.
- An individual executable or DLL can be blocked by revoking the hash of the binary.
Revoking an unsigned executable/dll only helps to protect against off-line modification if the device doesn’t allow unsigned code to run. Otherwise, someone can use a hex-editor to change a byte in the executable, which will change the hash of the module and thus the device would allow it to run.
When revoking a certificate, you should use the thumbprint of the certificate's hash. You can use the revoke.exe tool in the SDK to inspect or generate the appropriate hash, then use the LoaderRevocation Configuration Service Provider to create a revocation XML.
You would send the revocation XML that has the hash for the revoked certificate to the device over the air (OTA) or by pushing it in a cab provisioning file (cpf). In both instances, the message must originate from a source that has a manager role on the device.