Sunday, May 19, 2002

A Matter of Trusting Trust
Ten Risks of PKI

The authors of both articles challenge the widespread assumption that PKI and digital certificates provide a safe method of authentication "out of the box". The second article is co-authored by Bruce Schneier, the author of "Applied Security".

In 2001 Verisign, the market leading digital certificate issuer, issued a certificate for the name of "Microsoft" to someone who pretended to be working for Microsoft, but in fact, was no Microsoft employee at all.

How do I know that I can trust a digital certificate? The trust evaluation mechanism that is implemented in Windows verifies that a certificate is signed by a "trusted" signer. A list of "trusted signers" is pre-installed in Windows. On my WindowsXP system this list currently contains 109 "Trusted Root Certification Authorities" - most of them I've never heard of, and of course I have no idea what policies and processes each of these "authorities" have to identify persons or legal entities they issue certificates for (each certification authority describes these polices in its CPS - Cryptographic Practice Statement, however these are large documents that read like a combination Law Review and Computer Programming Essay, and are therefore - intentionally or unintentionally - not understandable by most people).

"Certificates provide an attractive business model. They cost almost nothing to make, and if you can convince someone to buy a certificate each year for $5, that times the population of the Internet is a big yearly income ... It's no wonder so many companies are trying to cash in on this potential market. With that much money at stake, it is also no wonder that almost all the literature and lobbying on the subject is produced by PKI vendors."

While certificate providers pride themselves in their nuclear weapon safe data centers, the main weak link in the security chain is in fact somewhere else: how do they verify the identity of the person or legal entity they issue the certificate for, and how do they authorize the correctness of additional content of the certificate? Organizations that can naturally make authoritative statements are banks for their customers, goverment institutions for citizens, or companies for their employees. But today these institutions are often not the ones issuing the certificates. The certificate issuers are large global corporations like Verisign, that do not really know for whom they issue their certificates.

The whole current concept of pre-installed Trusted Root CAs in browsers seems to be flawed. It does not make sense to trust all these organizations "by default". In fact, today's server SSL certificates main purpose is to enable an encrypted connection, but not really to establish the identity of a website or merchant (with hosted shops the certificate often carries the name of the hoster, not of the merchant, and it's questionable anyway if SSL CA's really can make authoritative statements if someone legally owns a DNS entry or not). So we can have SSL encryption without any of those pre-installed Trusted Root CA's. For authoritative statements about the identity of a certificate owner I would trust government-issued certificates (for individual persons) or the official commercial register for companies. Further I would want to trust certificates that a company I regularly do business with has issued for their employees (but I may not want to add this company to my list of trusted root CA's!)

Abuse of private keys can also be an issue. Viruses or Trojans could steal the private key and even when the key is stored on a SmartCard it could be abused to sign things the key owner isn't aware of. With today's digital signature laws that could mean you would have to prove that you didn't sign something that has been signed using your private key. However that's probably a similar situation like when you have a perfect fake of your conventional paper+pen signature. But a mechanism to declare a private key as invalid seems to be absolutely required. Certificate revocation lists (CRLs) are supported by most systems but rarely checked in realtime when a certificate is validated for performance reasons.