You may have heard of certificate pinning.
Very simply put, it’s a funky name for a sort of “allowlist” of digital certificates. It is intended to supplement (or even to supplant) the chain of trust on which normal digital certificates, such as those used for HTTPS, rely.
1. You send out a site certificate that is a public key people can use to encrypt traffic to your site, combined with a digital signature that identifies it as yours.
But the name in a certificate is just a text string typed in when it was created, so anyone can make a certificate that says it’s yours. How do people know it is yours? Here’s how:
2. The site certificate is digitally signed with an intermediate certificate owned by a CA (certification authority) that vouches for you.
The intermediate certificate may itself be signed with another intermediate certifcate, and so on, until finally:
3. The last intermediate certificate in the chain is digitally signed by a root certificate that belongs to a CA that vouches for the CA (that vouches for the CA, etc.) that vouches for you.
And your browser, or your operating system, or whatever, contains a list of root certificates it trusts implicitly.
The browser I’m using now trusts hundreds of roots, from the resoundingly named “A-Trust Gesellschaft fuer Sicherheitssysteme im elelektronischen Datenverkehr GmbH” out of Vienna, to the spaceage-sounding “XRamp Security Services Inc”, now a subsidiary of Trustwave.
So there’s quite a lot that can go wrong. You can forge a certificate in my name by suborning, hacking, tricking or cajoling any CA that owns a trusted root certificate, and begging, borrowing or battering them into signing your bogus item. Most browsers will accept it, just like that.
In real life, we rely on extra checks and balances to prevent this sort of fraud.
Imagine, for example, that you’re a tall, thin female with a Minnesota driving licence and distinctive left-handed cursive writing with a loopy flourish.
You’d probably expect your bank to be suspicious if a short, chubby bloke turned up at a branch and tried to draw from your account using block capitals and a Canadian passport, even if his name was the same as yours.
Certificate pinning tries to provide the same sort of “this just isn’t the Mrs Jeanette Smith we’re used to” warning, by keeping an independent record – an allowlist, or whitelist – of what your certificate is supposed to look like.
Of course, this isn’t without its own problems. If you want or need to change your certificates, you can’t just let the new certificates speak for themselves: you have to update the pinning data, or allowlist.
Nevertheless, there is something unappealing about a crook being able to sign himself certificates for any web property he likes just because he’s broken into a root CA’s network.
(It’s happened, and on a huge scale. Security company Vasco’s Dutch subsidiary Diginotar “signed” more than 500 bogus digital certificates in the name of major brands such Facebook, Twitter, Microsoft and Google. It didn’t help that Diginotar apparently waited several weeks before coming clean about the breach.)
Anyway, Microsoft is experimenting with a similar idea for “pinned signatures” on signed software. This means that if I break into your root CA servers, I can’t just start minting my own signed versions of things like operating system drivers and core software that your computer will blindly trust.
Pinning has helped with web security. Will it work for program files?
Have a listen as Patrick Gray, host of the renowned Risky Business security podcast, and I discuss this very question:
Then let us know in the comments what you think about certificate pinning.
Do we really need yet more PKI (public key infrastructure) to bolster the PKI that we already have for the public keys signed by everyone from A-Trust to XRamp?