The impact of Diginotar on Certificate Authorities and trust

Published: 2011-09-10. Last Updated: 2011-09-10 16:59:41 UTC
by Mark Hofman (Version: 1)
8 comment(s)

It has been a little bit over  a week since VASCO announced the breach discovered on 19 July at Diginotar,resulted in fraudulent certificates being issued.  Apple, Microsoft, Mozilla, Adobe and others have pushed out updates revoking Diginotar certificates (except in the Netherlands). Looking at the press release this line caught my eye

"VASCO does not expect that the DigiNotar security incident will have a significant impact on the company’s future revenue or business plans"
http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx

That got me thinking, and during several virtual water cooler chats we discussed the potential impact of this breach.  However before we get to that we need to understand a little bit more of the true nature of Public Key Infrastructure (PKI) and the role the various certificate authorities play in it. You see in PKI it is all about trust.

We know certificates can be used for all kinds of purposes and many organisation will set up their own internal Certification Authority (CA) and start issuing certificates that can only be used internally. If used externally they will pop up as errors, invalid certificate. For certificates to be trusted by everyone, you need one that has been issued by a recognised certification authority such as Thawte, Verisign, Godaddy, Digicert, Diginotar, or others. Once they have signed a certificate you trust it, because …? We will get back to that in a minute, first we need a little bit more CA 101.

A typical CA will have a root CA which is used to sign the certificates for one or more intermediate CAs. The root CA is then often taken offline to protect the private key of the root Certificate.  The intermediate CAs are then used to sign further CAs or are used to start issuing certificates to customers for their web servers, email and so on. When you need a certificate for a web server a public/private key pair is generated. A certificate request is sent to one of the intermediate CAs. The CA creates and signs a certificate using its own private key and sends the certificate back.  Voila, you now have a certificate for your SSL site and browsers will no longer complain about the validity of the certificate.  However that is just the technical side, where does the trust come into it?

The trust we as user have, is in the processes and procedures that a CA has in place to ensure that the request for a certificate and the information in the certificate request is accurate. In other words checking that the person asking for the certificate is not lying. That is where a large part of trust comes from. The rest comes from having confidence that the organisation has the security controls in place to ensure the integrity of the process. Or in other words, fraudulent certificates cannot be issued and the private keys of the CAs are safe. The robustness of the process determines the level of trust and for us the price. A certificate costing $20, probably only needs a valid email address. One costing $1700 will typically have many more checks performed before issuing a certificate. Unfortunately for us security professionals most users won't know the difference between the two.

The onus however is not only on the CAs. CAs have to publish certificate revocation lists (CRL), usually on a url starting with crl, e.g. crl.verisign.com, or Online Certificate Status Protocol (OCSP). These lists contain those certificates that are no longer valid and should not be trusted. Applications using certificates (e.g. when using SSL) are expected to check the revocation list or send a OCSP query to verify that a web server's certificate is still valid. It is however up to the application, so we are trusting the various vendors that they will check. Browsers will typically send a OCSP request, but if they can't reach then the CRL is used. Other applications may do something different.

Trust in certificates rests on trusting the entity issuing the certificate and trusting that they have the protection and processes to maintain the integrity and therefore maintain our trust.  That is a lot of trust, something in my opinion, Diginotar and to some extent other CAs have lost. Governments typically do not get involved in the CAs business (unless the certificates are issued on the governments behalf). There is as far as I am aware no requirement for CAs to demonstrate the robustness of their processes or the security of their systems. Maybe they should?  Mozilla has called for a review http://news.cnet.com/8301-27080_3-20103615-245/mozilla-gets-tough-after-digital-certificates-hack/ or at least some assurance from the CAs who have certificates in the Mozilla certificate stores.

As for VASCO's statement, from what I can see the trust is gone and that is what Diginotar is selling, but I guess we will have to see.

Mark

Keywords:
8 comment(s)

Comments

"Browsers will typically send a OCSP request"

Not necessarily. The problem with sending out an OCSP request is added latency to the http request.

Some time ago, TLS was extended with a technology referred to as "OCSP Pinning"
or "Certificate Status Request"

rfc4366
http://tools.ietf.org/html/rfc4366#section-3.6

The client can request the certificate status within the TLS handshake, and then the onus is on the web server to present the signed recent OCSP response, rather on the application to "query the status" of the certificate against CRLs directly.






Mysid

Sep 10th 2011
1 decade ago

Given how bad their security was, how can we trust that DigiNotar would come back with anything trustworthy? Obviously, VASCO hired out the cheapest group of people they could find to run the business, or never cared enough to educate themselves about what it takes to run a CA to even bother auditing security if it was some income stream they bought. VASCO obviously doesn't give a damn about trust, so in the web of trust, they should be treated as a permanent pariah and be burned off the web of trust with a handy flame thrower. Ask any Iranian who'll be spending time in prison.

Sean

Sep 10th 2011
1 decade ago

Check out Moxie Marlinspike's "Trust Agility" alternative to permanently trusting certificates from limited CAs: http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity

aphex

Sep 10th 2011
1 decade ago

"There is as far as I am aware no requirement for CAs to demonstrate the robustness of their processes or the security of their systems."

Each browser CA Programme actually has this requirement. CAs must have an audit conducted annually using one or other CA audit standards and report the results to the browser vendor operating the Programme.

Microsoft's requirements in this area for example can be found here: http://technet.microsoft.com/en-us/library/cc751157.aspx (see 'General Requirements' Step 7.)

A person

Sep 10th 2011
1 decade ago

@mysid, Yep absolutely right, was trying to keep it simple. Thanks for the link.

@aphex Thanks for the link. I think soon enough we will be looking at alternatives.

@A Person, I meant regulatory requirements, rather than a vendors' requirement. However you are right. Microsoft and others do insist on some sort of audit of the CA environment before they include the certificates in the trusted store.

Reading the standards the microsoft process refers to is quite interesting. There is much emphasis on the issuing process, not so much on the security side. I'm also assuming Diginotar passed. Maybe a CA equivalent of PCI DSS is needed?

Mark

Sep 11th 2011
1 decade ago

OCSP Pinning, as Mysid points out, could definitely be an improvement. I regularly see temporary OCSP errors on various sites using Firefox.

However, the point I made in my comment under https://isc.sans.edu/diary.html?storyid=11533 (2011-09-08) still stands: it is a fundamental flaw that pointers to revocation data are in the certificate itself instead of in the parent/issuer certificate, as this mechanism does not take a compromised CA into account.

Bitwiper

Sep 11th 2011
1 decade ago

I agree with Mark, above.

I believe some standard policy/audit for security, and a consortium to decide this standard is needed.

Obviously, I feel it would only gain traction if the browser vendors (and OS vendors who have certificate stores locally) champion the standard. All this noise about implementing different layers of technology is great, and is valuable... but this places the cost (money, work and time) of integration where it belongs, with commercial entities that specialize in that area. Microsoft, Google, Apple, Mozilla, and Opera, to name a few, could easily consort (hah) and find a solution.

mbrownnyc

Sep 12th 2011
1 decade ago

"it is a fundamental flaw that pointers to revocation data are in the certificate itself instead of in the parent/issuer certificate, as this mechanism does not take a compromised CA into account."

In the event of a compromised CA, it is the CA itself that should be revoked.

There should be OCSP servers that the root certificates themselves can be checked against :)

Mysid

Sep 12th 2011
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives