“Hi. I’m from Budapest. My company is called NetLock Uzleti Tanusitvanykiado Tanusitvanykiadok. Would you trust me to secure your network?”
The odds are you would answer “no” to such a query. But if you’re running Microsoft Corp.’s Internet Explorer, you trust the aforementioned company to certify the identity of your trading partners. Go ahead, look at your Internet Explorer preferences. You’ll see NetLock in there as a trusted signer, right between Microsoft and Thawte. You didn’t know you were trusting a company you never heard of, with a name you can’t pronounce, in a country which, until a few years ago, was considered a part of the Evil Empire? Well, too bad for you.
The whole world of public-key infrastructure (PKI) has a Cold War feeling to it – trust, but verify. Trust a certification authority to sign certificates of strongly identified people, organizations and systems. Verify that those certificates were issued validly, that the identifications match up, and that they are still legal. But as the world discovered recently, all that PKI mumbo jumbo is poppycock getting in the way of good old corporate profits.
Earlier this year, VeriSign mistakenly issued two code-signing certificates to someone claiming to be a Microsoft employee. OK, anyone can be conned. But it turns out that VeriSign doesn’t include a pointer to its Certificate Revocation List (CRL), which would have told users the certificates had been revoked, in this kind of certificate.
But that’s OK, because it doesn’t matter anyway: Microsoft and Netscape Web browsers don’t check the CRL when they see a certificate, so even if the pointer had been there, you wouldn’t have been warned. Even if you ask the browser to verify, it doesn’t check the CRL.
Security managers should use the Microsoft/VeriSign blunders as an opportunity to re-evaluate whether their PKI design is improving corporate network security or making life easier for the help desk. PKI requires more than just software: it’s also a set of policies and procedures for managing the entire life cycle of certificates. Are you simply concentrating on the front end of PKI and not looking at what happens when someone loses his private keys, changes job titles or leaves the company? Certificates can be used for encryption and digital signatures. Are you issuing certificates properly so they are only used for the intended purpose? Learn a lesson from this error: Make sure your procedures for updating, distributing and checking CRLs are up to snuff.
I’d like to give PKI one more chance. Like any security tool, PKI can be misused and misconfigured to reduce security. However, the design of PKI can work, if you don’t cut corners in the name of corporate expediency and are willing to pay the price that always comes with security.
Snyder, a Network World Test Alliance partner, is a senior partner at Opus One in Tucson, Ariz. He can be reached at Joel.Snyder@opus1.com.