This issue (in French) can be found here:
ActuSecu at XMCO Partners

• Verisign distributes test certificates for people to try out their service. These certificates are limited to 60 days, delivered without any kind of verification, and clearly labeled as such. People use them mostly to validate that PKI-enabled software like browsers or mail clients can handle them fine.
• These certificates come with all bells and whistles. If you read the fine print, it is clearly indicated that these are intended for test purposes only.
• Many other certificate authorities offer the same kind of service for users to test. The same proof-of-concept could have been realized with any other certificate provider offering test tools, as long as they relate to a root CA trusted by iPhones.

You do not have to believe me: browse any certificate provider web site and look for test certificate generation.

The WTF lies in the fact that an iPhone would accept this kind of toy certificate as a token of proof to authenticate a remote configuration received over the air.

Hope that clarifies things a bit.

Introduction

The iPhone is obviously a consumer market product which was later enhanced to become an enterprise device. Unfortunately, it seems Apple messed up their corporate-oriented functionalities, ending up with something that proves to be hard to integrate in a public-key infrastucture in any secure way.

The following page summarizes our findings in terms of chain-of-trust management on iPhones, describes a major security flaw and how we could cope with the current situation (Jan 2010).

iPhone provisioning protocols

iPhones currently provide two provisioning protocols allowing to install certificates on a device. v2 was the version released with iPhone OS v2.0 and v3 released with iPhone OS v3.0.

iPhone OS v2

This protocol is quite straightforward: put an XML config file named something.mobileconfig served with filetype application/x-apple-aspen-config somewhere on a web server seen by the iPhone, point Safari to the corresponding URL and let it download the file.

XML configuration files are created with an Apple utility called the iPhone Configuration Utility (iPCU), which is a desktop-based program running on Windows or Mac OSX. Apple has not released specs for the XML config files it produces.

iPhone v3

This protocol is an attempt from Apple to streamline over-the-air provisioning to large numbers of iPhones. It is described in: Enterprise Deployment Guide

Provisioning an iPhone in v3 is done through several network exchanges:

1. iPhone accesses URL of provisioning server (hereafter: PS)
2. PS responds with a minimal mobileconfig file requesting credentials
3. iPhone POSTs a request to PS containing its signed credentials
4. PS responds with key specifications and the address of a SCEP server
5. iPhone performs SCEP request to SCEP server
6. SCEP server delivers a certificate

Shortcomings

There are several shortcomings to that process:

Certificate fail

In step 3, the iPhone signs its own credentials (including its IMEI or device serial number) using an Apple-signed certificate. To validate this certificate, the chain of trust must be established up to Apple’s root CA. Unfortunately, Apple does not provide access to this chain except by jailbreaking an iPhone and extracting it directly.

The following chain of trust was manually extracted from a jailbroken iPhone:

Signed requests from this iPhone use this key:
    CN=Apple iPhone Device CA
        keyid=xxxx
    issued by CN=Apple iPhone Device CA
        keyid=B2:FE:21:23:44:86:95:6A:79:D5:81:26:8E:73:10:D8:A7:4C:8E:74

The certificate for 'Apple iPhone Device CA' is:
    CN=Apple iPhone Device CA
        keyid=B2:FE:21:23:44:86:95:6A:79:D5:81:26:8E:73:10:D8:A7:4C:8E:74
    issued by CN=Apple iPhone Certification Authority
        keyid=E7:34:2A:2E:22:DE:39:60:6B:B4:94:CE:77:83:61:2F:31:A0:7C:35

The certificate for 'Apple iPhone Certification Authority' is:
    CN=Apple iPhone Certification Authority
        keyid=E7:34:2A:2E:22:DE:39:60:6B:B4:94:CE:77:83:61:2F:31:A0:7C:35
    issued by CN=Apple Root CA
        keyid=2B:D0:69:47:94:76:09:FE:F4:6B:8D:2E:40:A6:F7:47:4D:7F:08:5E

The certificate for 'Apple Root Certificate Authority' is:
AppleComputerRootCertificate.pem
    Serial Number: 1 (0x1)
    CN=Apple Root Certificate Authority
        keyid=2B:D0:69:47:94:76:09:FE:F4:6B:8D:2E:40:A6:F7:47:4D:7F:08:5E
    issued by CN=Apple Root Certificate Authority
        keyid=2B:D0:69:47:94:76:09:FE:F4:6B:8D:2E:40:A6:F7:47:4D:7F:08:5E

The last certificate in the chain is a self-signed root CA for Apple Root Certificate Authority.

Interestingly, the Apple root CA on top of the iPhone chain is not the same as the one published on the Apple web site. Fetching the root certificate published on Apple’s web site shows:

    Serial Number: 2 (0x2)
    CN=Apple Root CA
       keyid=2B:D0:69:47:94:76:09:FE:F4:6B:8D:2E:40:A6:F7:47:4D:7F:08:5E

Different name (CN), different serial numbers (1 vs 2) but the same key id. It looks like somebody reused the same keyset to generate a second certificate. Hard to tell whether this is an oversight or intentional, but the fact is: you cannot technically relate an iPhone signature to the Apple root CA certificate published on their web site. Even with the same keyset, verification will fail because Subject and Serial are different.

SCEP fail

It looks like the iPhone SCEP client implements an old (draft) version of the SCEP protocol. As an example: sending back a chain of trust containing several certificates will lead to an error, the iPhone only accepts one certificate upon request of the CA chain. If you need to talk to a SCEP server, make sure it will accept old-fashioned requests.

mobileconfig fail

As seen above, installing mobileconfig files can happen over the air through v2 or v3 protocol. It is also possible to connect the iPhone to a desktop running iPCU and use it to transfer mobileconfig files through cable.

An interesting difference is that profiles downloaded over the air are not trusted by default, whereas profiles downloaded through iPCU over a cable are trusted. This translates into a red icon for non-trusted profiles and a happy green flag for trusted ones. As demonstrated below, trust does not depend on the medium being a cable or over-the-air download.

A close study of iPCU revealed that:

• iPCU generates its own set of keys upon install, and self-signs its own certificate
• Whenever a new iPhone is connected to that iPCU instance, iPCU inserts its own certificate into the iPhone trusted keystore.
• Further exchanges between this iPCU instance and a known iPhone are always trusted, as long as the iPCU certificate is present in the iPhone. This is also valid for mobileconfig files sent over the air: as long as they are signed by a trusted iPCU, they are trusted upon download.

An even closer study of the certificate used by iPCU revealed that it only contains Signature in key usage. This lead us to discover a serious security flaw as described below.

Security flaw

What was found

We observed that iPhones will trust mobileconfig files they receive over the air or through wire if they are signed by a trusted entity. However:

• The keystore used to lookup trusted CAs includes the default Safari keystore
• A signature-only certificate is enough to sign mobileconfig files

There are 224 trusted root Certificates in the iPhone keystore (v3.1). See: http://support.apple.com/kb/HT3580 for a complete list published by Apple.

It is relatively easy to obtain a signature certificate from many of them without any sort of verification. A demo (test) signature certificate can be obtained from Verisign without need for anything other than a valid e-mail address (throwaway addresses work, too) for sixty days at no price and without providing any credit card details.

NB: Verisign is not to blame for this in any way. They distribute un-verified temporary certificates that you are not supposed to trust for anything, like most other certificate providers.

What was tried

• Create a throwaway e-mail address
• Use it to request a demo certificate from Verisign Level 1 for a person named Apple Computer, valid for sixty days
• Create a mobileconfig file on iPCU: name it Security Update, declare it as issued by Apple Computer. Export it to disk without signature as a plain XML file.
• Using openssl smime and the P12 you got from Verisign, sign the mobileconfig file including the complete CA chain and put it onto a public HTTP server
• Open the link from Safari on iPhone and observe that the configuration is trusted by the iPhone.

Edit 2010-02-04: Demonstration file taken away. Point was made

On an iPod Touch, the installation screen looks like this:

Downloaded mobileconfig file

To be successful, profile installation needs to be validated by the end-user. Unless they know about this flaw it is quite likely that a default end-user would trust an update that claims to be issued by Apple and indicated as trusted by the device. A bit of social engineering is needed to both get the user to click on the link and accept the profile installation.

Exploiting the flaw

Parameters that can be set through mobileconfig on an iPhone include root certificates. Modifying root certificates makes it possible to act as man-in-the-middle to hijack SSL (HTTPS) connections.

Obnoxious modifications can be brought to the phone like prohibiting the use of Safari, mail and other apps, or adding extra VPN, WiFi or e-mail settings. It is also possible to set up the profile as being non-removable by the end-user, which would force the iPhone owner to wipe it clean to remove the profile.

What could be done

There is absolutely no reason for an iPhone/iPod to trust root CAs for over-the-air mobileconfig downloads. Apple needs to define who should be able to download mobileconfig files onto a device, be it an end-user or a company, and devise a correct way to share keys between the device and its associated provisioning server.