Note: The November 15, 2000 issue of Bruce Schneier's Crypto-Gram has a link to this page as a rebuttal. I did not intend this "response" to be a rebuttal since I think the article raises some very valid points such as PKI being oversold as a one-stop solution for all your security needs. I just felt that the article left the reader hanging and didn't tell the whole story, hence my response below.
Gentlemen,
I recently downloaded your article "Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure" from the Counterpane site. While I think both of you raise very valid points, I do have the following comments:
What's the purpose of your article?
I am confused as to why you wrote the article. While you raise valid points/risks, you do not offer any alternatives and/or solutions. Are you "Chicken Little, crying out 'The sky is falling...'"? I'm sure that many people who read your article are asking themselves "What do I do now?" How about the risks of NOT using a PKI? A logical conclusion of your article is to stick with symmetric encryption systems because, since they don't have a PKI, they must therefore have less risks.
It would seem that you should be writing about the correct ways of using a PKI and hence minimizing the risks. Since primarily it's the X.509 vendors providing the information, well respected experts in the field should be pointing out what is correct and what is marketing fluff. Your article should have pointed out how to minimize the risks you point out.
Your use of the term "PKI"
I'm surprised that you continue this fallacy that a PKI requires a CA (even though you do mention PGP, and Carl, you are a big proponent of SPKI). You are right that most of the literature and lobbying is done by PKI vendors, but they are X.509 PKI vendors, not general PKI vendors (if any such vendors exist). Any system that uses any kind of public key encryption needs an infrastructure to validate the public key. But not every PKI needs a CA. A common misconception of PGP users is that they don't think they are using a PKI.
The risks of PKI
If I believed 100% of your article, then I wouldn't use any type of public key system (again, any public key system needs a PKI). I don't use a security system to eliminate all the risks, I use it to reduce the risks to an acceptable level. I fly commercial airlines once in a while (and I know both of you do the same) and I drive a car some 600 miles a week. There are plenty of risks (more than 10 ;-) associated with those activities, but I will continue to do them.
E-commerce and PKI
While I do believe you are correct about e-commerce and PKI, e-commerce is not the only application for a PKI. Also, most of the e-commerce taking place on the Internet today is because of SSL which is based on an X.509 PKI. Whether SSL provides a false sense of security is a different issue. However, enough people and organizations believe it provides an acceptable level of risk and hence the large amount of e-commerce based on SSL.
Risk #1
In the "real world" (or "bigger world"), businesses are always relying on third parties. Most commonly, retailers use a person's drivers license (issued by a third party, the state) to determine whether they will sell that person liquor, tobacco or admit the person to an R/X-rated movie. And these businesses continue to do so even though they are fully aware that there are people who make a living by producing fake drivers licenses. As of today, I'm not aware of anyone making a living by producing "fake" certificates.
You should have provided the answer to your exercise. I'm sure the majority of your readers don't understand the subtle difference between identity and authorization. Since when is my driver's license an authorization for me to get drunk? My drivers license is an authorization by the state of California to drive a car, not an authorization for the bar to sell me liquor. Authorizations are not granted by CAs, they are granted by owner of the service or good. And whether we like it or not, and whether we agree or not, it is acceptable practice to use an "identity" as proof of authorization. But this has nothing to do with using a PKI.
The PKI literature (written by you know who), likes to use the drivers license analogy for certificates. You often read or hear something to the effect that "digital certificates are your drivers license to the Internet". You also read or hear that all you have to do is "present your certificate" (just like you present your drivers license) to "prove your identity". People don't seem to realize that, assuming they trust the identity in the certificate (Risks 4 & 8), you prove your identity by proving that you "control" (Risk 2) the private key corresponding to the public key in the certificate.
How do you minimize the risk: Don't confuse identity with authorization.
Risk #2
You state "One of the biggest risks in any CA-based system is with your own private signing key." You are not telling the whole truth: you have this risk with any encryption system. The whole basis for modern cryptography is the protection of the secret (symmetric) key or the private (asymmetric) key, whether or not a CA is involved. If either the secret or private key is exposed or used by the wrong person, you lose all security offered by cryptography.
I totally agree with your statements on non-repudiation. You can check the PKIX archives for my views on the issue of non-repudiation. When you verify a digital signature, all you know (assuming the algorithms involved have not been "broken") is that the data was not modified and that the private key was used to create the signature. You do not know who "authorized" the use of the key and what the conditions were when the signature was created.
How do you minimize the risk: Protect your private key! I think that both of you would agree, that in general, storing your private key in a smart card is "more" secure that storing your private key in a file on your computer. At least with a smart card, only one copy of the private key exists and I carry it with me. With today's operating systems, in general, I have no idea whether someone made a copy of my private key file.
Risk #3
I totally agree with all but your last statement. You fail to point out that "root" public keys MUST be verified with an out of band mechanism, even if the certificate verification is performed on a "computer system that is invulnerable to penetration by hostile code or to physical tampering".
How do you minimize the risk: Whether or not you do certificate verification in an "invulnerable computer system", you must verify root public keys with an out of band mechanism!
Risk #4
Your statements are correct but you don't provide an answer for your "bigger world". Even in my "small world", when I send this email to "cme@jf.intel.com", how do I know that the Carl Ellison I know is getting it? The Carl I know (and sort of trust ;-) has never told me his middle name. So how do I know that "cme" are the initials for the Carl Ellison I know? Why isn't his email address "ce@jf.intel.com"? I know that Carl works for Intel and the the ".com" is the domain for a commercial entity, but what does the "jf" mean? I happen to know that it refers to "Jones Farm". But I also once worked for a "Jones Futurex". Does it matter or do I care?
According to accepted Internet practice, "cme" refers to a unique person within the Intel domain. But I'm sure that Intel uses more that just "cme" to refer to Carl. I'm sure that the JF phone directory does not use "cme", it probably uses "Carl Ellison", "Carl M. Ellison", "Ellison, Carl", "Ellison, Carl M." or some similar variation.
When I was in grade school, "Linda" was a very popular girl's name and we had at least 3 girls named Linda. So how did we resolve the "identification" issue? Each Linda "extended" her name with the initial of her last name, so we ended up with a "Linda B", "Linda M" and "Linda R". So having a CA extend a "common name" to make it unique is not a new solution.
How do you minimize the risk: Have the appropriate procedures for tying a "name" to a person or entity.
Risk #5
I don't see what risk you are trying to point out. As I pointed out above, since when does the state of California have the authority to allow me to get drunk?
You ask "What harm is done if an uncertified server were allowed to use encryption?" and you answer "None." Your are misleading your readers. The purpose of the SSL certificate is not to give permission to the server to do SSL, but it's to bind the server's public key to an identity *when* it does SSL. And the identity issue was risk 4.
How do you minimize the risk: What risk?
Risk #6
What is the risk you are trying to point out? I recently bought a Chevy car. Were all the components of that car built by Chevy? Of course not! Did that fact prevent me from buying it? No. I have a Bank Of America Visa card. Was it really issued by BofA? Not likely, it was probably issued by First Data. Do I use it? Yes. Do I care that it really wasn't issued by BofA? Absolutely not! Why, because I "trust" Chevy and BofA. I will only use the CAs (if I'm using a PKI that requires a CA) that I trust.
How do you minimize the risk: What risk? I live with this risk all the time.
Risk #7
This is a variation of Risk 6. Why is the RA+CA model "categorically less secure that a system with a CA at the authority's desk"? Why is my Chevy less a car because Chevy didn't build all the components? Why is my BofA Visa not as valid because BofA didn't really issue it?
How do you minimize the risk: What risk?
Risk #8
With exception of the last paragraph, this is a variation of Risk 4. The last paragraph brings up an issue/risk that is largely being ignored. Although CMP and CMC both include "Proof Of Possession" (POP), in my opinion, they are putting the cart before the horse. How do you have POP if you don't trust the public key yet? How do you prevent man in the middle attacks? Ironically the vendors that use the drivers license analogy forget that a state requires you to physically show up before issuing a license.
How do you minimize the risk: Same as Risk 4.
Risk #9
I'd like to address each paragraph. You are totally correct with paragraph 1.
In paragraph 2 I believe that you are mixing apples and oranges. The lifetime of a key is not directly tied to the lifetime of a certificate. The "owner" of a key/key pair should perform his/her own risk analysis to determine the lifetime of the key/key pair. In addition to the considerations you state, the risk analysis should consider the key size, the algorithm, the use of the key/key pair (confidentiality/authentication/etc.) and what the key/key pair will be protecting. The lifetime of a certificate is determined by the CA based on its risks analysis and business practices. As you state, CAs are motivated to issue as many certificates as possible. The only "link" between the lifetime of a public key and the lifetime of the certificate is the lifetime of the certificate should not exceed the lifetime of the public key.
Paragraphs 3 and 4 are risks inherent in any cryptographic system: How do you detect key compromise and how are the appropriate parties notified. Bruce, if I hire your company to monitor my system, how do I know your company is not finding holes and then trying to exploit them?
How do you minimize the risk: Develop the appropriate security practices (not just certificate practices) for the whole system. Make sure you "trust" the software you are using.
Risk #10
Once again you seem to be mixing apples and oranges. All your statements about SSO are correct, however SSO is NOT inherently tied to a PKI. Yes you can implement SSO with a PKI, but most SSO's are not. Kerberos is the most popular SSO mechanism that does not use any PKI (although the latest version of Kerberos does support a PKI). While I was at Apple, we developed an SSO mechanism for password based authentication that did not use a PKI.
In my opinion, the most important paragraph of your entire article is the last one. But as I stated before, the industry needs experts like yourselves to inform the "busy system administrators and IT managers" how to make sure that PKIs are correctly implemented to minimize the risks you present without the hype that PKI vendors are putting out there.
How do you minimize the risk: What risk? If you use a CA-based PKI, you have to use CA processes.
Just my opinions,
Aram Perez