A. Karl Kornel's personal blog

Main menu

Post navigation

An Analysis of the CAs trusted by iOS 8.0

iOS 8.0 ships with a number of trusted certificates (also known as “root certificates” or “certificate authorities”), which iOS implicitly trusts. The root certificates are used to trust intermediate certificates, and the intermediate certificates are used to trust web site certificates. When you go to a web site using HTTPS, or an app makes a secure connection to something on the Internet (like your mail server), the web site (or mail server, or whatever) gives iOS its certificate, and any intermediate certificates needed to make a “chain of trust” back to one of the roots. Using the fun mathematical property of transitivity, iOS will trust a web site’s certificate because it trusts a root certificate.

iOS 8.0 includes two hundred twenty-two trusted certificates. In this post, I’m going to take a look at these 222 certificates. First I’m going to look at them in the aggregate, giving CA counts by key size and by hashing algorithm. Afterwards, I’m going to look at who owns these trusted roots.

Perl is Awesome

Before I go on, a quick shout out: Perl is awesome! I used a Perl script to parse Apple’s list, and to generate the numbers below. If you want the script, here it is:

Key Sizes

The root certificates use either RSA or ECC for their keys. Here’s how the numbers break down:

4096-bit RSA: 44 CAs

2048-bit RSA: 138 CAs

1024-bit RSA: 27 CAs

384-bit ECC: 12 CAs

256-bit ECC: 1 CA

On the RSA side, the numbers don’t surprise me too much. 1024-bit RSA is fading away, and a fair number of CAs moved to 4096-bit RSA keys, rather than move to ECC (or before ECC started to become prevalent for certificates). Even though RSA has the supermajority, ECC has gotten a foothold in the land of the CA, and that’s good, but I am concerned by the algorithm choices.

The 256-bit ECC curve that one CA is using is identified as prime256v1. The 384-bit ECC curve that twelve CAs are using is secp384r1, also known as ansip384r1, or as P-384, the bigger brother to the infamous P-256. Neither of these curves are trustworthy, according to Safecurves.

I would not be surprised if the number of ECC keys stays stable, and the number of RSA 4096-bit keys goes up. Most (if not all) of the widely-supported ECC algorithms (in web browsers and servers) are of the P-XXX variety. The safer route (for now, anyway) is to move up to 4096-bit RSA, while waiting (and advocating) for the inclusion of more trusted curves into web browsers and servers.

Signature Hashes

When we look as the hashing algorithms used to sign these root certificates, SHA is the order of the day:

SHA-512: 1 CA

SHA-384: 17 CAs (including 12 of the CAs using ECC keys)

SHA-256: 42 CAs (including 1 of the CAs using ECC keys)

SHA-1: 149 CAs

MD-5: 10 CAs

MD-2: 3 CAs

First, some clarification: SHA-1 is a single algorithm. SHA-2 is a collection of algorithms, among which are SHA-256, SHA-384, and SHA-512. There are also other members of SHA-2, but they aren’t used here, so I’m ignoring them!

Again we see the slow move away from SHA-1, and that’s good, but what really surprised me was the number of MD-5 certificates, and *gasp* there are still three MD-2 CAs? Really?

Looking at MD-5, both Netlock and Thawte own three each, expiring in 2019 (for Netlock) and 2020 (for Thawte). GTE owns one (expiring in 2018), Equifax owns two (expiring in 2020), and one of them (owned by Globalsign) expired this January. Those all pale in comparison to the three MD-2 CAs, all owned by Verisign (the original “Class 1,2,3 Public Primary Certification Authority” CAs) and all expiring in 2028.

Hey, crypto people, if you thought MD-2 was dead, you were wrong! This inclusion really surprises me: If you try to load your own MD-5 root certificate into iOS, it will not be trusted. And yet, iOS 8.0 ships with 13 CAs that use MD-5 (or older) algorithms.

Update: As has been notedon Twitter, root certificate signatures are typically not validated by clients (browsers, OSes, etc.). Intermediates and lower certificate signatures are validated, but the root cert signatures are not.

Certificate Owners

Companies

It is no surprise that the vast majority of CAs in iOS are owned by for-profit corporations. What interested me is just how many of those corporations seem to go a little overboard.

The following vendors have more than 3 CAs in iOS 8.0:

AC Camerfirma SA: 4 CAs

Apple: 4 CAs

Comodo: 4 CAs

Digicert: 8 CAs

Entrust: 5 CAs

Geotrust: 4 CAs

Globalsign: 6 CAs

Netlock Kft: 5 CAs

Symantec: 6 CAs

TC Trustcenter GMBH: 6 CAs

Thawte: 12 CAs

The Usertrust Network: 5 CAs

Verisign: 17 CAs

All told, Symantec owns thirty-five CAs, thanks to Verisign’s purchase of Thawte, and Symantec’s purchase of Verisign. I don’t hold that against Symantec, though: Most of the CAs were issued before the purchase, and it’s too much trouble for all of their customers to switch over to Symantec roots.

Even so, I really start to wonder: How many certificate authorities does one company actually need?

When it comes to web sites, it looks like there’s no need to crack the encryption, and you probably don’t even need an inside line to Verisign! You can just issue your own faux-Microsoft cert (or faux-Google, or faux-Apple, or …) using one of your own governmental CAs, which iOS already recognizes.

Unfortunately, I can not see any way (in Safari on iOS 8.0) to get information on the certificate chain for a web site. In other words, I can’t tell if the certificate for secure1.store.apple.com was issued by VeriSign, or if it was issued by the US Department of Defense. Safari does show the green URL bar and company name for EV certificates, but I have no way of knowing ahead of time that Apple uses an EV certificate for their sites.

Final Thoughts

First of all, it’s good that Apple has posted the list, and I do believe it to be a complete list. That said, I do wish there was a way in iOS Safari for me to see the details of the site’s certificate, and the chain from the certificate up to the root. Maybe this is something that could be implemented as an extension?

The security-concious (or maybe security-paranoid?) will take note of the CAs that are using questionable ECC curves, and those CAs that are using MD-2 or MD-5 signature hashes. Other people will also take note of the countries whose governments have their CAs in iOS 8.0, making it so much easier for them to impersonate web sites of their choosing.

There is no way to disable any of the root CAs that comes with iOS, so it is very much a take-it-or-leave-it situation. I wonder, is Android the same way, or does Android allow you to uninstall or disable CAs that you don’t like? With all the work that Apple does to secure iOS devices, that makes me trust Apple enough to take it. I’m going to continue using my iPhone 5, with iOS 8.0.

31 thoughts on “An Analysis of the CAs trusted by iOS 8.0”

Apple made it easier for me by posting the entire list, with details, on their web site. Of course, we can’t easily look into the guts of iOS, so that really was the only way for people to see it.

For Android, you would need a way to get a copy of all of the certificates from the trusted root store. To get the certs in human-readable form, OpenSSL can be used (the command would be: openssl x509 -in CERT_FILE -noout -text), and then you could run it through my Perl script (or a modified version). I’ve been told on Twitter how to view the list graphically, so that’s a start!

One other question: Can individual carriers add CAs to the Android releases on their phones? If yes, then you would have to look at each Android release from each carrier, in addition to the stock Android distribution from Google.

Please note the signature algorithm used in the self signed root CA certificate does not matter, the signature is not really used for anything. What matters is the signature algorithm the CA uses to sign OTHER certificates.

Okay, some ca’s have recovation urls (I didn’t know and stand corrected). I wonder though if any real ssl clients bother to check the validity of the ca certificate with crl or ocsp? I doubt they do.

And even if they did, I would not worry. What good would it do an attacker if he/she can find a hash collision with a root ca certificate, i.e. put in whatever he wants in a certificate that has a matching hash to any existing root ca?

Also, “something important” cannot be changed with root ca certificates with hash collisions, as they are hard coded with clients. If (as an attacker) you can trick a victim to install your CA certificate, it’s game over for the user anyway, and you won’t need any forged signatures.

I haven’t checked all browsers, but I would not be surprised if all of them don’t, or if almost all of them don’t. If those signatures aren’t checked, and I decided to be malicious, I would write something that gets into a person’s computer and changes all the CA expiration dates to yesterday (of course, that assumes the CA expiration dates are checked). Would I get any benefit from it? No. It would just cause problems, but for some people, causing problems is enough of a reason.

Of course, now I’ve said that, if this does happen, then people are going to think I did it. *groan*

I have 156 root certs on a stock Nexus 5.
That app exports them as DER files so you need to use OpenSSL like so:
openssl x509 -in %%f -inform der -noout -text

They are individual DER files so you need to loop through them and append to a text file. In Windows (yeah yeah) create a batch file like this to get an input.txt file:
FOR /f %%f in (‘dir /b c:\dir\certs’) DO (
openssl x509 -in %%f -inform der -noout -text >>c:\dir\certs\input.txt
echo. >>c:\dir\certs\input.txt
)

Drop the extra echo line if you don’t want a blank line between them. I ran the perl script against it as-is but it’s not working out of the box. Haven’t bothered to try editing it yet.

Regarding issuing faux-microsoft.com with a government CA, this should be mitigated by HSTS. At least in Chrome, you can see that popular secure sites are not only hardcoded to be HTTS-only (aka HSTS) but also pinned to a certain subset of CAs:

Yup, I’m aware of HSTS and the static list of HSTS sites. When I look at that list, I see that the vast majority of sites are using HTTPS, but there is nothing that limits those sites to using specific CAs. Only a very small number of sites are pinned to specific CAs, and I’m noticing that the list is very Western-centric.

So yes, there are many sites in the HSTS preload list, but very few are pinned to a specific CA.

One other issue to consider: If a web site pins themselves to a CA, and then that CA decides to raise their prices, then what do you do? You can ask the Chromium team to update the list, but that would only apply to new versions of the browser, and it would take time for the updated list to be pushed. Plus, you are relying on the Chromium team to make the change.

Also, Apple may already be using this! Have a look in iOS under Settings->General->About->Legal->Legal Notices. It’s interesting to see all the stuff that Apple is using!

I’m trying to write code to read the trust store on a device and get the certs. Would you mind telling me how you got the list of certs used to write this article? I see in Apples Certificate, Key, and Trust Services Reference there’s a call SecTrustCopyCustomAnchorCertificates() that lets you ask about all the anchor certs for a given “Trust management object” but I have no idea how to get a list of available trust management objects.

After reading your article I got a little concerned about the Chinese government certificate in iOS, so I went and read the Apple lists you linked to myself in the KB article and checked both iOS8 and iOS9 – it looks like the CNNIC ROOT cert is listed under the “Blocked certificates”, along with things like the hacked mail.me.com and google.com certs which were blocked specifically after being fraudulently issued. So unless you’re looking at a different certificate to me, there doesn’t seem to be a Chinese government certificate installed, except in order to be specifically blocked by iOS?