CSO: The Resource for Security Executives

CSO Newsletters
CSO's free newsletter keeps you informed about the latest articles, analysis, news, reports and other developments at CSOonline.com. Sign up today.


Subscribe to CSO
CSO is free to qualified readers in the U.S. and Canada.


Read CSO Online
All the issues of CSO are available online.

Back in the 1970s, the inventors of public-key cryptography thought that people would one day publish their public keys in some kind of directory—such as a phone directory but with hundred-digit keys instead of phone numbers. That way, if someone you had never met wanted to send you a private message over an electronic network, that person could look up your public key in the directory and then use the key to encrypt the message. When you got the message, you could decrypt it with your private key. (Although the idea of using encryption for e-mail might seem visionary for the 1970s, it really wasn't: Professors and graduate students at MIT had been sending e-mail to each other since the early 1960s and were well acquainted with the privacy problems that arose from it.)

Shortly after the creation of public-key cryptography, people noticed a potential problem: I mean, how do you know that the key printed in the public directory next to the name "Simson Garfinkel" really belongs to me if you have never met me before? As it turns out, there's really no way to know for sure. You need to trust the company that published the directory and hope the key in the directory really belongs to me and not to some shadowy organization that's secretly intercepting my e-mail.

To protect the integrity of information, we rely on an aspect of public-key cryptography called digital signatures. Instead of having you encrypt a message with my public key and send it to me, I encrypt the message with my private key and send it to you. If you can decrypt that message with my public key, then you know that the message had to have been signed with my private key—mathematically there's simply no refuting this fact. So as long as I am the only person who has my private key, you can assume that the message, in fact, came from me!

Digital signatures can be used to sign any kind of digital information, such as an e-mail message or a purchase order. The company that printed the directory could digitally sign the entire directory with its private key. Before you use my key to send me a message, you first verify the digital signature using your copy of the publisher's public key.

In practice, publishers don't sign the entire directory; they sign each individual directory entry—called "certificates"—because they consist of a person's name, her public key and a digital signature created with the publisher's private key. The popular X.509v3 certificate format allows all kinds of information to be embedded into a certificate and digitally signed. Because they issue these certificates, we call the publishers "certificate authorities," or CAs. These days the whole system of directories, certificates and CAs goes by the buzzword public-key infrastructure, or simply PKI.

Early public-key systems used the same keys for both sealing and signing. Today's systems use separate keys for these two functions for a variety of technical and political reasons.

To send me an encrypted message, all you do is go to that directory, search for my name, download my certificate, verify it with your copy of the publisher's public key and then use the copy of my public key that's on my certificate to send me an encrypted e-mail message. It's a complicated process; but fortunately, the code that implements the process is built into Outlook, Netscape Navigator and many other programs.

Notice how the entire strength of this system rests upon four things: the software that does the encryption, your copy of the publisher's public key, the publisher's trustworthiness and the private keys. Your e-mail client might not actually encrypt the message, or it might send an encrypted blind copy to Siberia. Alternatively, someone could infiltrate the certificate authority and have it issue certificates in my name that have his keys. Or he could simply steal my private key. If any of these things happens, the security offered by PKI is lost.

That, in a nutshell, is what PKI is all about—it's a certificate authority's promise about the identity of a person or business that has possession of a private key. Of course, PKI is also much, much more complicated.

During the past 10 years, there has been a Herculean effort to incorporate the principles and technology of PKI into many aspects of our business and personal lives. The first step was to distribute software that could understand and verify digital certificates. Netscape Navigator, the first such program, used PKI to verify the digital certificates on so-called secure websites. By "secure," Netscape meant that the website could be accessed using the SSL encryption protocol. An aggressive public education campaign convinced many people that it wasn't safe to send credit card numbers over the Internet unless those numbers were encrypted with SSL. Because Netscape sold the only SSL-enabled Web server, the company took off.

But while the use of PKI increased Netscape's stock price, it didn't do a whole lot to actually provide security to credit card transactions. SSL server certificates give users an encrypted channel to a Web server, but it's up to the users to examine the certificate and see if the name matches with whom they wish to communicate. For example, if you connect to a website like www.store.palm.com and want to find out if the site is really operated by Palm or not, you should be able to look at the Organization and Organization Unit fields of the certificate and find out who it was really issued to—that is, provided that the CA that issued the certificate did its job properly, and provided that the company that got the certificate didn't lose control of its private key.

That's the theory. But in the years since SSL certificates have been widely deployed, practice has become quite lax. When I looked at the certificate that certifies the publisher of Palm Computing's Palm Store in July, for example, I discovered that there was no meaningful information inside the cert's Organization and Organization Unit fields. Most people don't notice this, of course, because the user interfaces of Internet Explorer and Netscape Navigator make it so very difficult to actually look at the fields on the certificate. Who is to blame? It turns out that the fault here lies with Equifax, the CA that apparently issued the certificate.

Of course, the big dollars in PKI aren't with server certificates—the big payoff comes when people like you and me start getting client-side certificates that allegedly verify our identity when we connect to a secure server using SSL or special purpose software. Client-side certificates let computers use possession of a private key as an identifier. In theory this is better than using passwords or biometrics because the computer that verifies your identity needs only your public key. That prevents the verifying computer from stealing your password and then impersonating you to a third party. This is what PKI advocates mean when they say PKI prevents identity theft.

One problem with client-side certs is that you need a way to prove your identity to the CA in the first place. Another problem is that you need a secure place to keep your private key; most people aren't good at memorizing hundred-digit numbers. Typically, keys themselves are encrypted with some sort of pass-phrase and either stored on a hard disk or in a smart card. As a result, the security of most PKI systems frequently degenerates into the security of traditional password-based systems instead.

Another problem is differing interpretations of what it means to use a client-side certificate. With Microsoft's Internet Explorer, when you use your digital certificate it's a big deal, like you are signing some kind of legal document. But with Netscape Navigator, your secret key can be used automatically, transparently, and without your knowledge, whenever you touch a website that asks for a signature. With either system, you don't always know exactly what you are signing—you just know what your computer says you are signing. It's entirely possible that your computer might be infected with a Trojan Horse that says you are signing one document, when in fact you are signing another. Supporters of PKI who claim that PKI provides "nonrepudiation" of business contracts and other legal documents invariably gloss over that point.

Not surprising, the most successful PKI deployments are at organizations that have already verified the identity of their employees and members: For these organizations, PKI helps improve security by eliminating passwords with an infrastructure that supports single sign-on. But in many other situations, a compelling case for PKI as it is currently envisioned has yet to be made.


Simson Garfinkel, CISSP, is a technology writer based in the Boston area. He is also CTO of Sandstorm Enterprises, an information warfare software company. He can be reached at machineshop@cxo.com.

> Fraud Finders

Recently, I've been working with a number of firms who are trying to either assess their risk in emails, or to address the risks identified so far. While S/Mime and PGP address the 'who sent it' problem, these standards prevent virus controls at the mail gateway, not to mention the distribution problems in the article. Whose job is it to force the email administrator to disable virus protection, either partially or completely, depending on the AV package? Who signs the exemption from company policy? Who takes liability when one party is in another company, and their gateway has to have email virus protecton disabled/reduced? When most email viruses come from someone you know, this is not a matter to ignore.

Lyal

Lyal Collins
CTO
Key2IT
Email
Print