iPhone PKI handling flaws
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:
- iPhone accesses URL of provisioning server (hereafter: PS)
- PS responds with a minimal mobileconfig file requesting credentials
- iPhone POSTs a request to PS containing its signed credentials
- PS responds with key specifications and the address of a SCEP server
- iPhone performs SCEP request to SCEP server
- 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 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
- Grab certificate in browser, back it up to a P12 on disk
- 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.
A demonstration file can be found here:
http://dl.dropbox.com/u/4377334/update.mobileconfig
This config file is relatively harmless: it installs a new link to a famous Youtube video and is set to be removable by the end-user. You can visualize the certificates that were used to sign it with:
openssl pkcs7 -in update.mobileconfig -inform der -print_certs
NB: If you open the above link with Safari on an iPhone/iPod, it will not try to install as a mobileconfig because the file is not served with the correct file type. To see it in action you need to place it on a web server that serves these files with mime type application/x-apple-aspen-config and open the link on your iPhone.
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:
- Web proxy name and port
- Root certificates
By setting a new HTTP proxy, it is possible to re-direct all HTTP traffic from the iPhone to an arbitrary server on the net. Modifying root certificates makes it possible to act as man-in-the-middle to hijack SSL (HTTPS) connections too.
Edit (2010-02-03): subverting HTTP traffic by setting the APN proxy is far from obvious as it relates to settings active with your phone carrier. This would not work e.g. on a WiFi hotspot.
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.
In other words, iPhone lack an OTA (Over The Air) set of policies and associated keys for remote terminal control.
Possibly related posts: (automatically generated)
Spread the word! Help us find bugs and add features! Retweet the news!
