Risks of PKI: Secure E-Mail

  • Carl Ellison and Bruce Schneier
  • Communications of the ACM
  • January 2000

Public-key infrastructure (PKI), usually meaning digital certificates from a commercial or corporate certificate authority (CA), is touted as the current cure-all for security problems.

Certificates provide an attractive business model. They cost almost nothing to manufacture, and you can dream of selling one a year to everyone on the Internet. Given that much potential income for CAs, we now see many commercial CAs, producing literature, press briefings and lobbying. But, what good are certificates? In particular, are they any good for E-mail? What about free certificates, as with PGP?

For e-mail, you want to establish whether a given keyholder is the person you think or want it to be. When you verify signed e-mail, you hope to establish who sent the message. When you encrypt e-mail to a public key, you need to know who will be capable of reading it. This is the job certificates claim to do.

An ID certificate is a digitally signed message from the issuer (signer or CA) to the verifier (user) associating a name with a public key. But, using one involves risks.

The first risk is that the certificate signer might be compromised, through theft of signing key or corruption of personnel. Good commercial CAs address this risk with strong network, physical and personnel security. PGP addresses it with the “web of trust” – independent signatures on the same certificate.

The next risk is addressed unevenly. How did the signer know the information being certified? PGP key signers are instructed to know the person whose key is being signed, personally, but commercial CAs often operate on-line, without meeting the people whose keys they sign. One CA was started by a credit bureau, using their existing database for online authentication. Online authentication works if you have a shared secret, but there are no secrets in a credit bureau’s database because that data is for sale. Therefore, normal identity theft should be sufficient to get such a certificate. Worse, since credit bureaus are so good at collecting and selling data, any CA is hard pressed to find data for authentication that is not already available through some credit bureau.

The next risk is rarely addressed. ID certificates are good only in small communities. That’s because they use people’s names. For example, one company has employees named: john.wilson, john.a.wilson, john.t.wilson, john.h.wilson and jon.h.wilson. When you met Mr. Wilson, did you ask which one he was? Did you even know you needed to ask? That’s just one company, not the whole Internet. Name confusion in unsecured e-mail leads to funny stories and maybe embarrassment. Name confusion in certificates leads to faulty security decisions.

To a commercial CA, the more clients it has the better. But the more it succeeds, the less meaningful its certificates become. Addressing this problem requires work on your part. You need to keep your namespace under control. With PGP, you could mark keys “trusted” (acting as a CA) only if they certify a small community (e.g., project members), otherwise, you could sign keys personally, and only when the certified name is meaningful to you. With some S/MIME mailers, you could disable trust in any CA that has too many (over 500?) clients and personally mark individual keys trusted instead. Meanwhile, you can print your public key fingerprint (a hash value, sometimes called a thumbprint) on your business cards, so that others can certify/trust your key individually.

There are other risks, also.

Did the issuer verify that the keyholder controlled the associated private key? That’s what the certificate claims.

Does your mail agent check for key or certificate revocation? Few do.

Finally, how well are the computers at both ends protected? Are private keys protected by password, and if so, how strong? Are they used in tamper-resistant hardware or merely in software? Do you have to provide the password for each operation or is it cached? Is the encryption code itself protected from tampering? Are public (root) keys protected at all? Usually they aren’t but they need to be to prevent false signature verification or encryption to an eavesdropper’s key. Can a physical passer-by sign something with the signer’s key or tamper with the software or public key storage? Is your machine always locked?

Real security is hard work. There is no cure-all, especially not PKI.

For more details, see http://www.schneier.com/paper-pki.html.

Categories: Computer and Information Security

Sidebar photo of Bruce Schneier by Joe MacInnis.