Re: Ten Risks of PKI
On 13 Dec 1999 18:40:02 - lcs Mixmaster Remailer [EMAIL PROTECTED] writes:
While this is true, keep in mind that there is more to mounting
a successful cryptographic attack than adding root keys and fake
certificates. It is also necessary to intercept the messages which
might have gone to the legitimate recipient, and possibly decrypt and
re-encrypt them. All this implies an attacker who has at least temporary
write access to the victim's computer, and long term read/write control
over the communication channels he will use.
I do not believe this attack requires "long term read/write" access to
the victim's computer. If I want to get a forged certificate into a
clients Browser all I have to do is convince the user to browse my
secure server with Netscape (or another browser) that will prompt the
user to install my unrecognized root certificate.
That's a good point, most browsers are configured to make it easy to
install root certificates.
However this is just the first step in an effective compromise. Now you
need to get him to use a bogus certificate when he thinks he is using
a good one. He tries to connect to a secure site, and you need to step
in and play man in the middle. You must hijack his connection to, say,
www.amazon.com, and direct it to your own site. Then you can offer your
bogus cert for www.amazon.com and get it accepted.
Alternatively, the attacker could just register the domain anazon.com (if only
amazon.con were possible :-) or amazon.be ("Look, Amazon's just started a
Belgian branch!"), issue a certificate for that site, and start spreading
banner ads and URL's for this domain.
Jaap-Henk
--
Jaap-Henk Hoepman | Come sail your ships around me
Dept. of Computer Science | And burn these bridges down
University of Twente | Nick Cave - "Ship Song"
Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF
Re: Ten Risks of PKI
Carl Ellison and Bruce Schneier write: Certificate verification does not use a secret key, only public keys. Therefore, there are no secrets to protect. However, it does use one or more "root" public keys. If the attacker can add his own public key to that list, then he can issue his own certificates, which will be treated exactly like the legitimate certificates. They can even match legitimate certificates in every other field except that they would contain a public key of the attacker instead of the correct one. While this is true, keep in mind that there is more to mounting a successful cryptographic attack than adding root keys and fake certificates. It is also necessary to intercept the messages which might have gone to the legitimate recipient, and possibly decrypt and re-encrypt them. All this implies an attacker who has at least temporary write access to the victim's computer, and long term read/write control over the communication channels he will use. This is a very powerful attack model. Virtually no cryptographic system, whether public key, secret key, or even a one time pad, could be secure against such an attacker. If the attacker can get in and modify the set of trusted certs, he can probably also modify the software that checks them. He can weaken the generator of session keys, or arrange to log messages and access them later. He has many ways of getting access to the data beyond adding certs. This is not a threat for which is reasonable to expect a cryptographic defense, and it is not an issue specifically related to PKIs. The lack of clear analysis of the threat model in the "risks" being discussed makes it hard to evaluate how seriously to take them. If the goal is simply to raise fear, uncertainty and doubt about using public key cryptography, the authors have succeeded. But if they want to enlighten potential users about concerns which are serious and specific to the use of PKIs, they do not make that distinction clear. In fact the entire thrust of the article is against a poorly defined bogeyman, the PKI. What is this beast which is being critiqued? All we really learn is that it is being sold by security companies in a slick "sales pitch" which purports to guarantee security. There is no technical description of what the PKI is and how its weaknesses are manifest. In fact, a PKI is fundamentally any system which allows you to determine whether a public key is suitable for a given purpose. It can be as simple as a personal collection of public keys you know are good for specific purposes, or as complex as a full set of certification hierarchies with cross certification and automated policy translation. Carl Ellison himself is the chief designer of the Simple PKI. Presumably he does not mean to say that he has misled potential users into taking on ten new risks by his work on this protocol. By using this generic term "PKI" the authors leave a great deal of confusion about which systems they are criticizing. Some of their "risks", such as the one quoted above, would apply to all of these PKIs, including SPKI. Others are more specific to current X.509 based hierarchical certification systems. Some don't address the PKI at all, but worry about things like user interfaces, criticisms that can be directed at virtually any form of security software. Rather than a hodgepodge of "risks" which pertain to many aspects of cryptographic systems beyond the public key infrastructure, it would be more useful to see a clear description of the kind of PKI the authors want to criticize, followed by a discussion of the issues which arise in the practical use of such systems. This would provide useful information to the potential purchaser or user of a PKI system. As presented, the article is likely to raise confusion and concern, but not to lead users to ask enlightened questions.
Ten Risks of PKI
Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure By Carl Ellison and Bruce Schneier Computer security has been victim of the "year of the..." syndrome. First it was firewalls, then intrusion detection systems, then VPNs, and now certification authorities (CAs) and public-key infrastructure (PKI). "If you only buy X," the sales pitch goes, "then you will be secure." But reality is never that simple, and that is especially true with PKI. Certificates provide an attractive business model. They cost almost nothing to make, and if you can convince someone to buy a certificate each year for $5, that times the population of the Internet is a big yearly income. If you can convince someone to purchase a private CA and pay you afee for every certificate he issues, you're also in good shape. It's no wonder so many companies are trying to cash in on this potential market.With that much money at stake, it is also no wonder that almost all the literature and lobbying on the subject is produced by PKI vendors. And this literature leaves some pretty basic questions unanswered: What good are certificates anyway? Are they secure? For what? In this essay, we hope to explore some of those questions. Security is a chain; it's only as strong as the weakest link. The security of any CA-based system is based on many links and they're not all cryptographic. People are involved. Does the system aid those people, confuse them or just ignore them? Does it rely inappropriately on the honesty or thoroughness of people? Computer systems are involved. Are those systems secure? These all work together in an overall process. Is the process designed to maximize security or just profit? Each of these questions can indicate security risks that need to be addressed. Before we start: "Do we even need a PKI for e-commerce?" Open any article on PKI in the popular or technical press and you're likely to find the statement that a PKI is desperately needed for e-commerce to flourish. This statement is patently false. E-commerce is already flourishing, and there is no such PKI. Web sites are happy to take your order, whether or not you have a certificate. Still, as with many other false statements, there is a related true statement: commercial PKI desperately needs e-commerce in order to flourish. In other words, PKI startups need the claim of being essential to e- commerce in order to get investors. There are risks in believing this popular falsehood. The immediate risk is on the part of investors. The security risks are borne by anyone who decides to actually use the product of a commercial PKI. Risk #1: "Who do we trust, and for what?" There's a risk from an imprecise use of the word "trust." A CA is often defined as "trusted." In the cryptographic literature, this only means that it handles its own private keys well. This doesn't mean you can necessarily trust a certificate from that CA for a particular purpose: making a micropayment or signing a million-dollar purchase order. Who gave the CA the authority to grant such authorizations? Who made it trusted? A CA can do a superb job of writing a detailed Certificate Practice Statement, or CPS ó all the ones we've read disclaim all liability and any meaning to the certificate ó and then do a great job following that CPS, but that doesn't mean you can trust a certificate for your application. Many CAs sidestep the question of having no authority to delegate authorizations by issuing ID certificates. Anyone can assign names. We each do that all the time. This leaves the risk in the hands of the verifier of the certificate, if he uses an ID certificate as if it implied some kind of authorization. There are those who even try to induce a PKI customer to do just that. Their logic goes: (1) you have an ID certificate, (2) that gives you the keyholder's name, (3) that means you know who the keyholder is, (4) that's what you needed to know. Of course, that's not what you needed to know. In addition, the logical links from 1 to 2, 2 to 3 and 3 to 4 are individually flawed. [We leave finding those as an exercise for the reader.] Risk #2: "Who is using my key?" One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don't own a secure computing system with physical access controls, TEMPEST shielding, "air wall" network security, and other protections; you store your private key on a conventional computer. There, it's subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it's protected by a password, how hard is
Ten Risks of PKI
[One more time, for the non-linefeed impaired. Musta been a great christmas party, that... :-)] Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure By Carl Ellison and Bruce Schneier Computer security has been victim of the "year of the..." syndrome. First it was firewalls, then intrusion detection systems, then VPNs, and now certification authorities (CAs) and public-key infrastructure (PKI). "If you only buy X," the sales pitch goes, "then you will be secure." But reality is never that simple, and that is especially true with PKI. Certificates provide an attractive business model. They cost almost nothing to make, and if you can convince someone to buy a certificate each year for $5, that times the population of the Internet is a big yearly income. If you can convince someone to purchase a private CA and pay you afee for every certificate he issues, you're also in good shape. It's no wonder so many companies are trying to cash in on this potential market.With that much money at stake, it is also no wonder that almost all the literature and lobbying on the subject is produced by PKI vendors. And this literature leaves some pretty basic questions unanswered: What good are certificates anyway? Are they secure? For what? In this essay, we hope to explore some of those questions. Security is a chain; it's only as strong as the weakest link. The security of any CA-based system is based on many links and they're not all cryptographic. People are involved. Does the system aid those people, confuse them or just ignore them? Does it rely inappropriately on the honesty or thoroughness of people? Computer systems are involved. Are those systems secure? These all work together in an overall process. Is the process designed to maximize security or just profit? Each of these questions can indicate security risks that need to be addressed. Before we start: "Do we even need a PKI for e-commerce?" Open any article on PKI in the popular or technical press and you're likely to find the statement that a PKI is desperately needed for e-commerce to flourish. This statement is patently false. E-commerce is already flourishing, and there is no such PKI. Web sites are happy to take your order, whether or not you have a certificate. Still, as with many other false statements, there is a related true statement: commercial PKI desperately needs e-commerce in order to flourish. In other words, PKI startups need the claim of being essential to e- commerce in order to get investors. There are risks in believing this popular falsehood. The immediate risk is on the part of investors. The security risks are borne by anyone who decides to actually use the product of a commercial PKI. Risk #1: "Who do we trust, and for what?" There's a risk from an imprecise use of the word "trust." A CA is often defined as "trusted." In the cryptographic literature, this only means that it handles its own private keys well. This doesn't mean you can necessarily trust a certificate from that CA for a particular purpose: making a micropayment or signing a million-dollar purchase order. Who gave the CA the authority to grant such authorizations? Who made it trusted? A CA can do a superb job of writing a detailed Certificate Practice Statement, or CPS ó all the ones we've read disclaim all liability and any meaning to the certificate ó and then do a great job following that CPS, but that doesn't mean you can trust a certificate for your application. Many CAs sidestep the question of having no authority to delegate authorizations by issuing ID certificates. Anyone can assign names. We each do that all the time. This leaves the risk in the hands of the verifier of the certificate, if he uses an ID certificate as if it implied some kind of authorization. There are those who even try to induce a PKI customer to do just that. Their logic goes: (1) you have an ID certificate, (2) that gives you the keyholder's name, (3) that means you know who the keyholder is, (4) that's what you needed to know. Of course, that's not what you needed to know. In addition, the logical links from 1 to 2, 2 to 3 and 3 to 4 are individually flawed. [We leave finding those as an exercise for the reader.] Risk #2: "Who is using my key?" One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don't own a secure computing system with physical access controls, TEMPEST shielding, "air wall" network security, and other protections; you store your private key on a conventional computer. There, it's subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it's protected by a password, how hard is it to guess that password? If
Re: Ten Risks of PKI
BPM Mixmaster Remailer wrote: By using this generic term "PKI" the authors leave a great deal of confusion about which systems they are criticizing. Some of their "risks", such as the one quoted above, would apply to all of these PKIs, including SPKI. Others are more specific to current X.509 based hierarchical certification systems. Some don't address the PKI at all, but worry about things like user interfaces, criticisms that can be directed at virtually any form of security software. Slightly tangentially, but worth observing, I think: current X.509 based PKI is only nominally hierarchical. That is, X.509 would _like_ the DN to be allocated hierarchically, but in practice this does not happen. Each CA has its own namespace, there is no-one above CAs in the hierarchy, and only one layer below (the entity for whom the CA provides a certificate). This is pretty flat for a "heirarchy" by anyone's reckoning. SPKI's main beefs with X.509 (AFAIK) are that: a) X.509 tends to want to be identity-based, which is a poorly defined concept at best (SPKI leans towards roles or capabilities) b) X.509 is based on a lot of difficult-to-get-right stuff that just gets in the way of the real meat: signing public keys and attaching some attributes to them. The fact that every X.509 package of any breadth is peppered with exceptions to cater for every other package's cockups is definitely evidence is SPKI's favour, IMO. The downside of SPKI, of course, is the usual one that seems to dog good ideas: no-one uses it. Cheers, Ben. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Ten Risks of PKI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 06:40 PM 12/13/99 -, lcs Mixmaster Remailer wrote: However this is just the first step in an effective compromise. Now you need to get him to use a bogus certificate when he thinks he is using a good one. He tries to connect to a secure site, and you need to step in and play man in the middle. You must hijack his connection to, say, www.amazon.com, and direct it to your own site. Then you can offer your bogus cert for www.amazon.com and get it accepted. The Bloomberg attack didn't require connection hijacking. All that attacker did was post a newsgroup message with a URL in it. If you're depending on that little lock in the corner of the browser window to mean you're connected to the page you seem to be connected to, and the "seem to be" is derived only from the page contents, you're in trouble. That's more what we were talking about than connection hijacking -- although if you want to go to that trouble, feel free. :) This shows up more clearly with e-mail. Here again, you don't have to hijack a connection if the attacker initiates the exchange (sends the first message) and the victim uses the "reply to" button in his mailer. [E.g., the attacker asks for a copy of the victim's latest draft -- and the victim sends it.] -BEGIN PGP SIGNATURE- Version: PGP 6.5.2fc7 iQA/AwUBOFVYWJSWoQShp/waEQIz0wCgkqP8a5D7lPlWcG3bo7agUMFoj80An07r 4mVt/ebbleR6Pqhp1KIw2Vuo =jFYN -END PGP SIGNATURE- +--+ |Carl M. Ellison [EMAIL PROTECTED] http://www.pobox.com/~cme | |PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | +--Officer, officer, arrest that man. He's whistling a dirty song.-+
Re: Ten Risks of PKI
Carl Ellison writes: The Bloomberg attack didn't require connection hijacking. All that attacker did was post a newsgroup message with a URL in it. This is presumably a reference to the incident described in http://news.cnet.com/news/0-1005-200-341267.html, where a PairGain employee apparently created a fake web page which resembled that of trusted financial news source Bloomberg, reporting an impending acquisition of PairGain. He then posted to Yahoo discussion groups a reference to his page's URL, using its IP address to disguise the actual point of origin and claiming it to be a genuine Bloomberg news story. The result was a 30% rise in PairGain's stock. This kind of attack is one of the things that PKIs are intended to address, but in this case no cryptography was used. Perhaps it would make good fodder for your upcoming companion article, "Ten Risks of NOT Using PKI". If you're depending on that little lock in the corner of the browser window to mean you're connected to the page you seem to be connected to, and the "seem to be" is derived only from the page contents, you're in trouble. That's more what we were talking about than connection hijacking -- although if you want to go to that trouble, feel free. :) Okay, but in the context of the risk you identified with PKIs, that is in fact what we are talking about: ways to get that little lock to appear when it shouldn't. They aren't as easy as the Bloomberg attack. This shows up more clearly with e-mail. Here again, you don't have to hijack a connection if the attacker initiates the exchange (sends the first message) and the victim uses the "reply to" button in his mailer. [E.g., the attacker asks for a copy of the victim's latest draft -- and the victim sends it.] Again, isn't this a case where a PKI helps rather than harms security? Getting a cert accepted with the identity of the person the victim thinks he is responding to will be more difficult than simply sending an unsigned message which claims to be from that person. Many of the issues you raised in your article are legitimate (although not necessarily specific to PKIs), but there seems to be a danger that you will just end up sowing confusion and doubt. The result will be that people will continue to use the old ways and fall into the traps you have described here. It's fair to criticize PKIs with an eye towards improving them, but your article seems more directed at questioning the value of cryptography itself.
