On the diginotar breach and the current PKI model

Originally intended to publish this in the second part of my SSL rant, but can’t resist to give it a go with all the noise made by the diginotar breach.

Stayed on Twitter more than usually regarding this and  along read various blog entries.

Although it may seems strange the noise had something positive. People start to understand the current PKI system or more exactly start to think more about it.

One major issue is that some people want to change the current model because is wrong but the plain fact is that most of them don’t understand how it works; especially they confuse the business model with technology.
They think that if you change the technology you can shape a different business model.

The current model is a defective business model faultily implemented with an almost working technology by humans.

I say almost because the current design of the PKI cannot itself offer protection against a failure of the model like in the diginotar case. Some parts can be easily fixed, some not so.
But the current business model, the implementation and the human factor are the ones at most fault.
Can a new technology radically change all these ? I doubt it.

What better way to exemplify than the diginotar case?

  • Diginotar messed things up and issued some certificates to wrong folks.
  • Particularly no biggie; the PKI can take the hit. That’s what for certificate revocation is. But that means it should be implemented correctly and harmonized correctly with the business model; you cannot revoke a certificate if you don’t know if you issued it.
  • For end users SSL + PKI is nothing more than UI(User Interface), that little padlock; what happens in the back is irrelevant.
  • The UI fails on most browsers because a fatal or downgrade UI change does not occur in all bad cases, e.g. certificate revocation fails.
  • UI blames it on usability, the servers to respond revocation queries might not always be online. Usability blames it on incompetence.
  • The business model should deal itself with incompetence through competition and other means; but it does not do that.
  • Also there is another hole in the implementation that lefts a window of opportunity for attackers; the freshness of the revocation status answer, an old answer can be replayed during a certain amount of time so that the certificate to appear still valid. The technology can deal with this. But the business model questions the technology’s scalability. Still the window of opportunity does not have to be of a week or so in some cases.

Where first the technology does not keep up with the technology?

  • So there are many root CAs; too many some say. More important there are many, I mean a lot, of intermediate CAs.
  • normally a root CA cannot be compromised that easy; the private keys are stored in hardware in a physical secure location.
  • Note that certificate issuing CAs are the intermediate CAs not the root CAs.
  • The PKI can take out these issuing CAs as the entire status of the certificate chain is verified; the certificate of the issuing CAs can be revoked.
  • It’s not particularly the number the issue here.
  • When a business, say Google, decides to buy trust from a certain CA for various reasons, it has no way, with the current PKI means, to make sure that only this CA is to offer trust for it.
  • that is, any of the other CAs can wrongly issue a certificate for Google and for the end users the trust to be the same. The diginotar issue would not have happened the way it happened if there would have been a way to bind this on-the-fly.
  • The UI cannot be blamed because it does not have from where to take that info. Google attempted to solve this with certificate pinning on their own browser; but this does not scale. The prove the binding would work is that Chrome users appeared to signal a MITM attack using a diginotar certificate.
  • The UI can be better in other area; the way the trust is displayed.
  • There are many types of certificates. For example the Domain Validated certificates are great as a decent anti-MITM solution and almost everyone can get one; but they do not bind the trust to a certain organization.
  • Extended Validation certificates do this. The UI tends to remain too minimalist when it comes to the level of trust; in the fact the UI is too minimalist when in comes to SSL, e.g. the entire browser window can change when a web site is viewed over SSL.

More on technology.

  • the revocation status of a certificate can be verified on the fly with existing technologies. But the trustworthiness of a CA cannot.
  • You can’t take out a root CA on the fly with existing technology; the diginotar case showed that with current technologies we cannot impose the death penalty to a CA on the fly.
  • For two reasons: there is no way to query for that and if would be you could not do it.
  • First: there is no way to query for that; we trust root CAs, actually we don’t it by ourselves. The process of trusting a CA is a rigid and confusing one.
  • Some keep downloading updates for their root certificates store, some need to issue entire new versions of their software.
  • Both way don’t work if you want to trust no more a CA in that they leave a window of opportunity for attackers till the updates are in place.
  • Second: if would be you could not do it; think the Comodo breach, if the death penalty would have been imposed to Comodo(among top players in the CA business) it would have created more insecurity than security because suddenly would have revoked the trust of many organizations that have valid certificates in place.
  • The UI would have been useless, users would have clicked blindly through warnings; MITM heaven window opportunity.
  • So we actually have two issues: cannot query on the fly if the root CA can be still trusted and how to safely untrust a CA.
  • The diginotar case revealed that technology cannot deal with bad business practices and implementations, particularly you cannot revoke a certificate if you don’t know if you issued one.

More on the business model.

  • it’s a lazy one since it’s like a closed club; little pressure and transparency.
  • liability it’s key. Imagine that real sanctions can be imposed; diginotar said it the CA business revenue was at around 100000 euros/dollars/whatever this year, not so much. Really heavy financial sanctions would take out CA businesses that are lazy on security. I’m curios to see what insurance companies are willing to back for real the current security practices of the CAs.
  • plus liability on auditors, no more checkbox guys; if they audit a CA and say it’s OK but turns out is not, the business model takes them out of the business by itself.
  • Keeps technological progress on hold; better protections could have been in place.
  • new root CAs are automatically pushed into browser’s store certificates; if you disable auto update you have to manage all CAs(decide which is EV which not, etc.) on your own. That's not easy.
  • issuing intermediate root CAs are stealthy and can be owned by almost anybody; if you trust a root CA you will likely auto trust the new issuing intermediate root CA on-the-fly.

On the users and the business model.

  • Google, Microsoft, Mozilla announce the death penalty to diginotar. Some users jump with joy, protection for the masses.
  • Some wanted to impose the death penalty to diginotar on their own.
  • They quickly learnt the hard way that you cannot manage the current PKI on your own; by the way, how many people managed to take out digicert as well? [edited to add] Note that DigiCert is not affiliate in any way with DigiNotar. If you manually remove trust for DigiNotar from your brower make sure you do not remove the trust for DigiCert too by mistake.
  • Knocking a root down does not take out a CA’s business.
  • diginotar, like many CAs, has a couple of root CAs; you need to take out all these. There are various reasons for that.
  • plus, again, like many CAs diginotar has certificates cross signed; this means you can take out all of its root certificates and you still trust the diginotar business through another (more important) separate root CA.
  • If you find the intermediate CA certificates, you can take them out too; and put vital systems(government in this case) with (apparently) valid certificates in a MITM-able posture.
  • furthermore, after the audit, how long do you think it would take for diginotar to be back in the trusted root CA store again? [edited to add] it appears that Google, Microsoft and Mozilla will actually blacklist diginotar permanently; note that this is rather an unusual case possible due to diginotar having a small market share.
  • remember, even when users expressed angry that China, linked many times to espionage, has a trusted root CA by major vendors, no vendor removed its trust.
  • An important lesson learnt: the CA business model protects itself (in a bad way) against existing implemented technological means meant to take it out when it misbehaves.

The PKI is not all about SSL and server certificates.

  • certificates issued by the very same CAs are used for other stuff like digital signature of software.
  • varying from OS to OS and from software to software there are various means to ensure the integrity of a software package; one is through digital signatures.
  • the package is downloaded over a MITM-able channel like HTTP and then at installation(automatically or manually) the signature is verified.
  • so even if you impose the death penalty to a CA in your browser, the underlying OS may have other views and trust the CA for digital signature of software.
  • so with a wrongly obtained certificate an attacker can force users to install a compromised software package on their machines and take control of this.
  • so one more time; you cannot manage PKI yourself.

The strange case of Opera.

  • Opera did not impose yet the death penalty to diginotar; they rely on the certificate revocation status.
  • If you do not understand the current PKI model it may appear strange.
  • Some fumed, Opera must follow Google, Microsoft, Mozilla.
  • But the Opera guys are sharp, very sharp.
  • If you read carefully so far, you would already know why what Google, Microsoft, Mozilla did has not much more value than what Opera did.
  • Google, Microsoft, Mozilla users still trust the diginotar business, their joy was a short one; Opera users too.
  • Even if diginotar business deserves the death penalty it cannot be imposed on the fly.

Comments (4) -

  • Interesting and well-thought out article.  It is clear that the new attack vector is intermediate or smaller, less fortified CA's.  Unfortunately, breaches in these less recognized organizations can have an impact on the entire trust landscape!  DigiCert is actively researching and assisting those that may have removed the DigiCert root while in process of removing DigiNotar.  It should be noted that DigiCert and DigiNotar are *not* affiliated in any way.
  • Just to be clear DigiCert is Not DigiNotar. Not the same company/CA.
  • Updated the blog entry to reflect that DigiCert and DigiNotar are not affiliated in any way.

    Thanks,
    Adrian
Comments are closed