The weakness of the certificate authority model, illustrated

September 11, 2011

There are two leading models for checking identity via public key cryptography. When someone demonstrates that they know the private key for a given public key, you can either check that you know the public key itself (the SSH model) or check that the public key is itself signed by an authority you approve of (the SSL CA model). In theory SSL can be used for either model; in practice, many SSL tools and APIs seem to be strongly convinced that you should use the certificate authority model. The problem with this is that the SSL CA security model has a major flaw, one that we have seen on display in the DigiNotar breach.

Any model needs to deal with the possibility of compromised or improperly issued certificates. The CA model's answer is a CRL, a list of certificates that you should not accept even though they have a valid CA signature. This is the problem: to create a CRL entry, you need to know the bad certificate. In fact you need to know some relatively specific information about a certificate in order to revoke it. In short, the SSL CA security model requires perfect CA knowledge.

In other words, the mechanism designed to cope with security breaches only works if the CA has a limited security breach; if they were broken into sufficiently badly that the attacker could issue certificates but not so badly to allow the attacker to prevent those certificates from being recorded correctly. If the security breach is not limited, or even if you don't know whether it was or was not limited, the only recourse in the SSL CA model is to revoke your approval of the CA itself, which results in all CA-signed signatures being rejected.

This is more or less exactly what happened with DigiNotar. No one believes any more that DigiNotar knows what bad certificates have been issued with its signature (their list of such certificates has already grown several times, and may yet grow again). In the absence of trustworthy knowledge, the only remedy possible is dropping DigiNotar's root certificate.

The SSH model does not necessarily scale when you are dealing with a large and unpredictable set of identities, but it works perfectly well when you are dealing with a smaller, enumerable set. And it does not require perfect knowledge of what identities you may have been compromised (or just fooled) into certifying. Hence my long standing desire to see SSL tools support direct certificate checking.

(When I wrote that original entry, I did not expect that we would get such a perfect illustration of the problem. Sadly, we did.)


Comments on this page:

From 71.56.100.181 at 2011-09-12 11:51:35:

Don't forget the PGP/GPG or "web of trust" model. In that model, a key is signed by multiple trusted authorities, instead of a single one. This makes it much more difficult to forge a certificate since multiple authorities needs to be compromised.

This should have been the route SSL took from the beginning, which would have avoided many of the current issues.

By cks at 2011-09-12 13:19:11:

There are two different models here: the 'web of trust', which requires people to decide on trust authority themselves, and multiple signatures from known authorities. Multiple signatures is simply an extra tax on SSL certificates (sure to be popular with the CAs, extremely unpopular with everyone else). Web of trust has the same problem as every other attempt to delegate security to end users; you are pushing the hard problem (picking trust roots) to a lot of people who have neither the experience nor the interest to do it well. I wrote about the whole issue in WebOfTrustFlaws and WhoManagesSecurity.

(I've also written about general SSL issues before, here and here and in things they link to. And other entries too. It's a rant topic for me.)

From 71.56.100.181 at 2011-09-13 11:12:23:

One of the biggest sins of tech people is dismissiveness. You have dismissed multiple signatures and focused on what appears to be your preferred flame target, web of trust. However, multiple signatures clearly is the answer here. If a certificate is signed by multiple trusted authorities and trust in those signatures is considered ANDed instead of ORed (as implied in your WebOfTrustFlaws page), once any one of the signatures are called into question, then the certificate becomes invalid.

This is the clear answer given that it's already been shown that governments, in addition to hackers, have been able to breach a single root CA and forge certs as much as they like. With multiple signatures, this becomes much more difficult.

By cks at 2011-09-13 14:04:13:

I wrote about multi-signed certificates in MultiSignedProblem. The brief version is that if multi-signed certificates are optional, no one will buy them (they are insurance against a very rare event), and if they are mandatory they are effectively just a tax on SSL certificates. Mandatory multi-signed certificates are the SSL CAs effectively saying 'you have to pay several of us because we can't be confidant that any of us are actually doing our job right'. The obvious answer is 'if you think that you may not be doing your job right, why am I paying you at all?'

(The answer to that is 'because SSL is an extortion scheme'. You pay a SSL CA to make the browser bar turn colours without your visitors getting scary warnings.)

Written on 11 September 2011.
« You really want to put your switches in server racks
An operational explanation of Python metaclasses (part 1) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 11 00:51:40 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.