Communications of the ACM
Home/Magazine Archive/January 2000 (Vol. 43, No. 1)/Inside Risks: Risks of PKI: Secure Email/Full Text
Communications of the ACM
Inside Risks: Risks of PKI: Secure Email
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 per 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 email? What about free certificates, as with PGP?
For email, you want to establish whether a given keyholder is the person you think or want it to be. When you verify signed email, you hope to establish who sent the message. When you encrypt email 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. However, using one involves risks.
The first risk is that the 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 personally to know the person whose key is being signed; commercial CAs often operate online, without meeting the people whose keys they sign. One CA was started by a credit bureau, using its existing database for online authentication. Online authentication works if you have a shared secret, but no secrets exist in a credit bureau's database because the data is for sale. Therefore, normal identity theft should be sufficient to obtain 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 people's names are used. 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 J. Wilson, did you ask which one he was? Did you even know you needed to ask? And that's just one company, not the whole Internet. Name confusion in unsecured email leads to funny stories and maybe embarrassment. Name confusion in certificates leads to faulty security decisions.
To a commercial CA, the more clients it handles the better. But the more it succeeds, the less meaningful certificates become. Addressing this problem requires work on your part. You need to keep your namespace under control. With PGP, keys could be marked "trusted" (acting as a CA) only if they certify a small community (for example, 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 clients and instead personally mark individual keys trusted. Meanwhile, you can print your public key fingerprint (a hash value, sometimes called a thumbprint) on 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 password protected, and if so, how strongly? 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.
©2000 ACM 0002-0782/00/0100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2002 ACM, Inc.
No entries found