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:

• The quick-and-dirty Perl script (signature)
• The list of CAs (signature)

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 noted on 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?

Governments

There are a number of governments whose CAs are included in iOS 8.0:

• China: 1 CA, via the China Internet Network Information Center
• Hong Kong: 1 CA, via the Hongkong Post e-Cert.
• Japan: 3 CAs, via GPKI and the Ministry of Public Management, Home Affairs, Posts, and Telecommunications (MPHPT)
• Netherlands: 3 CAs, via PKIoverheid
• Taiwan: 1 CA, via the Government Root Certification Authority
• Turkey: 1 CA, via the Scientific and Technological Research Council of Turkey
• United States: 5 CAs, via the Department of Defense

Those were just the countries whose names I was able to pick out.

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.