How to get a backup pin for TrustKit framework's SSL pinning under iOS?

Question

I'm currently implementing the TrustKit framework in my iOS app to enable SPKI pinning for SSL connections. I'm stumbling upon the "backup pin" which is mandatory for a correct TrustKit configuration. Unfortunately the API documentation only states that a backup pin is needed but it doesn't tell me what it should be. The chain of trust looks like this:

GeoTrust Global CA
| GeoTrust SSL CA - G3
   | myServer.com

So I pin the SPKI hash for myServer.com-certificate as the primary pin. What is my backup pin?

Unfortunately I didn't find a lot of information about this topic. One of the few resources I found is this article by Hubert Le Van Gong from PayPal. He says about backup pins:

"Whatever the number of pin values, a backup pin is an absolute must-have. Note that the existence of a backup pin is a mandate in HPKP (i.e. for the web case) but it is equally important in the mobile app space. In both cases, the key pair corresponding to the backup pin should be kept offline until an issue arises with the primary pin/key."

I especially don't get the part with "should be kept offline".

About the question what to pin:

Root CA certificate are probably best. Therefore, when pinning to multiple values (e.g. 2), intermediate CA – root CA is a sound approach in my opinion. That said, it is also perfectly OK to only pin to a single certificate as long as that certificate is a root CA.

From this I understand my backup pin could be the root CA (it's SPKI hash to be exact). However I wonder how an intermediate or even root CA can be good pins. From my understanding this would validate the pinning for every certificate that has this intermediate/root CA in it's chain.

What am I getting wrong here?

Answer 1

I wonder how an intermediate or even root CA can be good pins. From my understanding this would validate the pinning for every certificate that has this intermediate/root CA in it's chain.

What am I getting wrong here?

You are not getting anything wrong at all. The pinning configuration you choose comes down to a compromise between the level of security that you are comfortable with and practicality. There are 3 options and trade-offs:

Pin to leaf certificates (Maximum security)

You have full control and ownership of everything and no outside influence can compromise your SSL without compromising your infrastructure. Further, the compromise of any one of your certificates will not impact the others.

The downside here is that it will require a good deal of sensitive infrastructure to issue, audit, manage and deploy more than a few dozen certificates. Consider a publisher with 5,000 SSL certificates across various magazine and news properties.

Pin to an intermediadary CA that you own (Very High Security)

Effectively similar benefits of pinning to leaf certificates, except here if your intermediary certificate is compromised, all issued certificates are compromised. This is a balanced approach for pinning a huge number of SSL certificates.

Downside is that it’s incredibly expensive to obtain one of these.

Pin to a trusted root CA (High Security)

If you pin to a root CA or intermediate CA that you don’t own, you are in effect handing the keys to the owner of that certificate. This does mean that you are accepting any certificate that the root or intermediate issues for your domain. However, the reality is that this may be sufficient security to thwart most attacks. The business model of a mature global authority is predicated on trust. It is unlikely that a root CA will issue a malicious certificate for your domain.

A few downsides here:

1. CA Employees – In rare cases CA employees have been known to do bad things.
2. State Actors – We have no idea if governments have been able to get global authorities to issue malicious certificates. Perhaps even without them knowing via extralegal domestic espionage.

In the end, the most common strategy tends to be pinning to 2 or 3 trusted certificate authorities. When any one CA is compromised or breaks, you have other trusted certificates already issued and ready to go.

Answer 2

Here's a blog post with a section about the backup pin: https://noncombatant.org/2015/05/01/about-http-public-key-pinning/

Specifically:

You could, and likely should, also use an alternate intermediary or root issuer certificate for your backup. Additionally, it is best to get your backup signed by a valid issuer, before disaster strikes, so that you really can put it into production at a moment’s notice!

For your App, you should pin the root CA of the server's current certificate (GeoTrust Global CA) and then buy a certificate from a different CA and use that other CA as the backup pin. Pinning the leaf certificate (myServer.com) is more work to manage as this certificate's key is going to change more often that the root's.

Also, the most important thing about the backup pin is that it should be for a completely different certificate chain.