… but a recently published paper and demo drive the point home.

In summary, by exploiting collisions in the MD5 cryptographic hash algorithm, the authors were able to create bogus certificates signed by real/public/internet Certificate Authorities. As a result, signatures produced from those bogus certificates would automatically be trusted by a large number of client machines.

For example, I just performed a cursory examination of the root certificates currently trusted on my Vista SP1 machine, matching against the list in the above paper. I see that the “TC TrustCenter Class 3 CA” is trusted, and that it’s signature is indeed MD5-based. I also see one or more certs from Equifax and Thawte that meet the same criteria.

Why is this bad? It’s long been argued that trust decisions – such as what secure email code signing authorities to allow – should be taken out of users’ hands in an enterprise environment. That implies that those decisions are automated. For example, if software is signed by a certificate issued from such-and-such root CA, trust it and allow it to be installed.

But few enterprises have their own PKI, and even fewer can afford IT professionals who are qualified to administer it. Thus, the long list of root CAs that can be trusted by a typical client (Windows, Firefox, whatever) probably still are.

And home users are almost guaranteed to be vulnerable to this type of attack.

The assumption is that, if the cert chain is valid, then the intentions of the originator of that signature can be trusted. This in turn is partly based on the assumption that it’s not in the best interest of a typical public CA, especially the more well known ones, to issue certs to bad guys.

There are lots of reasons why those assumptions don’t work. This paper isn’t the best of those reasons, but it’s still an interesting one.

No Comments »