In a New Scientist article, mainstream popular press is starting to take notice that the big Wi-Fi standards have awful crypto. But there are some signs that the remedy is being pondered - I'll go out on a limb and predict that within a year, opportunistic cryptography will be all the rage. (links: 1, 2, 3,4 5)
(Quick explanation - opportunistic cryptography is where you generate what you need to talk to the other party on the fly, and don't accept any assumptions that it isn't good enough. That is, you take on a small risk of a theoretical attack up front, in order to reach cryptographic security quickly and cheaply. The alternate, no-risk cryptography, has failed as a model because its expense means people don't deploy it. Hence, it may be no-risk, but it also doesn't deliver security.)
Here's what has been seen in the article:
Security experts say that the solution lies in educating people about the risks involved in going wireless, and making the software to protect them easier to use. "Blaming the consumer is wrong. Computers are too complex for the average person to secure. It's the fault of the network, the operating system and the software vendors," says California-based cryptographer Bruce Schneier in the US. "Products need to be secure out of the box," he says.
Skipping the contradiction between "educating people" and "blaming the consumer", it is encouraging to see security people pushing for "secure out of the box." Keys should be generated opportunistically and on install, the SSH model (an SSH blog?). If more is wanted, then the expert can arrange that, but there is little point in asking an average user to go through that process. They won't.
Schneier is pessimistic. "When convenience and features are in opposition to security, security generally loses. As wireless networks become more common, security will get worse."
Schneier is unduly pessimistic. The mistake in the above logic is to consider the opposition between convenience and security as an invioble assumption. The devil is in those assumptions, and as Modadugu and Rescorla said recently:
"Considering the complexity of modern security protocols and the current state of proof techniques, it is rarely possible to completely prove the security of a protocol without making at least some unrealistic assumptions about the attack model."
(Apologies, but it's buried in a PDF. Post.) That's a green shoot, right there! Adi Shamir says that absolutely secure systems do not exist, so as soon as we get over that false assumption that we can arrange things perfectly, we can start to work out what benefits us most, in an imperfect world.
There's no reason why security and convenience can't walk hand in hand. In the 90s, security was miscast as needing to be perfect regardless of convenience. This simply resulted in lost sales and thus much less security. Better to think of security as what we can offer in alignment with convenience - how much security can we deliver for our convenience dollar? A lot, as it turns out.
Posted by iang at January 27, 2005 07:02 AM | TrackBackI'd like to see you make this prediction more concrete. What protocols do you envision using opportunistic cryptography? Ordinary (http) web browsing? But who would be on the other end of the cryptographic handshake, in that case?
Secure (https) web browsing already uses crypto, there's no need for opportunism. Likewise for VPNs.
What other protocols do people use that could benefit from this? IM? Are you predicting that AIM will start using crypto handshakes? What else? Email? I can already click a button in Outlook to make it use crypto in talking to the mail server; I think this does POP over SSL, so I imagine there's a cert.
What makes the most sense to me would be to do an SSL connection just to the wireless router and tunnel your packets through that. The router is probably already doing NAT so it is translating packets anyway. This wouldn't be opportunistic, you'd just turn it on and it would happen, similar to WEP. But it would solve the wireless security problem without the need for upgrading end to end protocols.
I think originally the wirelss people considered something like this but it was rejected because they weren't sure that wireless base stations could handle the complexity. Five or ten years ago when these standards were developed, computing power was more limited. But today, heck, these boxes are booting Linux. They ought to be able to handle SSL.
Posted by: Cypherpunk at January 27, 2005 05:25 PMConcrete?! Predictions are rarely concrete, but I'll try. What I specifically mean is that the view that rejects anything that isn't signed by a TTP will be gone. It will be acceptable to consider creating a self-signed certificate (or indeed just a key as SSH does) and using that to negotiate a secured connection. "Look Ma, no CA!"
Secure (https) web browsing uses only TTP-signed crypto. It could happily use non-TTP-signed keys, such as self-signed certs (these would be the way to go because they don't change the code base that much). In fact if self-signed certs were to be used in secure web browsing, we would be more secure on two counts:
One, phishing could be addressed because the browser could present to the user information on the relationship. Like, prior visits, and user statements like "this is my bank."
Two, those sights that don't have any concept of "I'm only who I am because a TTP says so" could use crypto. Like this one right now, which doesn't use SSL because it's too hard, because it is reserved for those who have to pay to get warnings turned off and all that.
Just doing encryption from / to a router doesn't make any sense to me. Which router? Why is that router the key one for protection? What happens when there are several? This is the old IPSec thing, which basically is a bit of a flop, not because of the stupid key management (that certainly didn't help) but because it was in the wrong place.
If the application needs security, then the app has to do it. Nothing else makes sense.
Posted by: Iang at January 27, 2005 06:59 PMSo let me understand your concept that it will become "acceptable" to use a self-signed certificate and apply it to web browsing. It wouldn't be applicable to plain http since no crypto is used there. So perhaps it would be used for https. Lots of sites would switch to using self-signed certificates rather than getting them from Verisign and Thawte. This would be, presumably, to save the $300 a year or whatever it costs.
Okay, maybe it could happen. But is that amount of cost savings really going to drive a major change like this? Most businesses don't mind paying such a small annual fee all that much. It's the equivalent of one extra business trip.
And really the only thing that could make it happen would be if a major browser (ie IE) turned off the warning when using a self-signed certificate, and made that the default. That's the only thing I could see motivating business people to stop paying Verisign and go self-signed. Otherwise they'll know that most of their customers will get evil-sounding warnings about the self signed certs.
And what is the motivation for IE to turn off these warnings? Isn't it likely that Microsoft got paid by Verisign and the other built in CAs specifically to put them into a privileged position? It might even be that disabling warnings on self-signed certs would violate Microsoft's contractual agreements with the CAs it took money from to give them an IE exclusive.
The bottom line is that the problem is that there is no correspondence between the parties which would receive the direct benefit, which is web site operators who want to offer secure browsing without paying for a cert, and those who would have to make the change, which is browser manufacturers.
Posted by: Cypherpunk at January 28, 2005 12:58 AMcypherpunk, we agree :) Your analysis is substantially correct. This is the stable deadlock that we find ourselves in, in that the browser manufacturers lack or have negative incentive to fix the problem and the server manufacturers and CAs won't make the first move.
I will make few remarks though. Firstly and most importantly, the structure is stable but is not about security. It is this blockage that lets phishing arise without any reasonable response from the PKI, which as we know was originally tasked to protect the browser user from spoofed websites. There are four companies that really really truley want to think long and hard about that.
Secondly, the costs you quote are just the invoice costs for each cert. For any real company the costs of the cert are much higher than the invoicing costs, as the system is slow and clunky. Yes it's getting better, but I still feel fairly confident that calling it a $1000 cost is close enough. (I mean, it could be more, and it could be less.) Secondly, b. when you switch from $x to $0, a lot of things change. If I can use HTTPS without paying anything, without using any of my time to configure it, then I will. That is, it's not the number of dollars, it's the fact that there are dollars involved, and by default, it's is turned off. That's wrong, and yes, that saving will drive a major change in the business. See http://iang.org/ssl/dr_self_signed.html for why the CAs are as trapped as we are and they want this to happen.
Thirdly, it's not about security, the structure is about extracting revenue from the companies. So what about security? Why can't I use free crypto on this site? Part of the answer is I have to buy a cert, because a CA "knows better" who I am. (Another part is that the SSL browsing system is designed to require an IP number.) I can use as much free SSH as I can fill up the pipe on but I can't use SSL without paying the piper. What's up with that? Conceptually, who are all these people at Apache and Mozilla and Microsoft working for?
(On the prediction: be careful. I am saying the concept of opportunistic cryptography will be acceptable. This means *new* crypto designs will use it. Stalwarts like SSL will be among the last to re-align. Also, try and apply the thinking to things like S/MIME and chat. There is no correspondence between CA assumptions and those markets, and using CA-signed certs in those markets is just plain stoopid. There, raw keys or self-signed is the only sensible way to go.)
Posted by: Iang at January 28, 2005 09:04 AMWhat about the objection that opportunistic crypto is totally vulnerable to a MITM who gets there first. What would stop a country like China from building a comm infrastructure with built-in MITM on every connection? Or for that matter, do we know it can't happen in the west? If we put all our eggs in the opportunistic crypto basket, security could be completely compromised by such measures. Even PGP, the archetype of P2P crypo, added key signers because of this problem.
The real problem with opportunistic crypto is that its benefits are global while its costs are local. The benefit is primarily political: that it can increase the amount of traffic which is encrypted, thereby making it harder to create a global surveillance network. But there is not much benefit to the actual end user, because he can never be sure that he is really getting any security. If he really needs security, like the case of a dissident in China, he better not depend on opportunistic crypto!
In PGP terms, that means he shouldn't just download a key from a key server and blindly use it to send sensitive messages to his fellow freedom fighters. That would represent dependence on opportunistic crypto but it could be a fatal error, because his adversaries could have put a fake key in place. What he should do is to specifically verify, himself or through a Trusted Third Party, that the key he is using actually belongs to the guy he is sending to.
The point is that opportunistic crypto USUALLY works but can't be RELIED UPON to work in the way that verified crypto can. This is why I say that the benefits are global rather than local. STARTTLS for email is a good example. It fills the net with a fog of encrypted data, but no one communication is guaranteed to be secure. It achieves a political goal, but doesn't provide hard core security when you need it.
End users pay the costs of using the crypto, without the benefits they deserve, of strong cryptography with a reliable reason to believe that they have a channel secure from end to end.
Posted by: Cypherpunk at January 31, 2005 02:14 PMCypherpunk,
"What about the objection that opportunistic crypto is totally vulnerable to a MITM who gets there first."
What about it? Honestly, have you ever seen it? Please correct me if I'm wrong - PLEASE!!! - but there is no recorded history of a credit card ever being sniffed and there is no fraud ever recorded due to MITM.
Consider MITM like stepping into a car and getting involved in an accident. How many times have you done that? Been in a car? Well, thousands of people die every day on the roads, but none of them ever stop going out there.
MITM is such a small risk it is totally unmeasurable. So is there any good reason to protect against it? I can think of a bad reason - coz it costs a lot of money.
The first thing that we have to get to grips with is that opportunistic crypto gives us a useful security model that is aligned with the risks that the user faces, but starts out at low cost. MITM is no risk so it doesn't cover it (thinking SSH here). If it was a risk, opportunistic crypto *would* cover it (thinking PGP WoT here) but at additional expense to the user that cares. But MITM is generally no risk so even the PGP users mostly ignore WoT.
Can we agree on that point? a) MITM is no risk, and that means it shouldn't be covered... especially if it is costly. There ain't no point in paying for something that ain't used. And b) opportunistic crypto covers what risks are actual real risks faced by users, and does so in a low cost fashion, leaving other risks for later.
Or, if we can't agree on that, I'm curious what brand body armour you wear when you go shopping?
(BTW, in all the above I mean protocol MITM, not injection/bypass MITM like phishing.)
Posted by: Iang at January 31, 2005 06:00 PMCypherpunk,
I see you're asking these questions ... seriously, so I'll attempt a serious answer. But I am curious where you got these ideas from?
> What would stop a country like China from building a comm infrastructure with built-in MITM on every connection?
Er, you and I. Opportunistic crypto works by ignoring the threats that aren't important. If MITM was important, we'd add it to OC. (You seem to be thinking that OC is vulnerable to MITM. No it's not, certain *implementations* of OC are, by design. OC says worry about what's a risk and leave the rest for later. For MITM, let's wait for China.)
> Or for that matter, do we know it can't happen in the west?
Not in terms of "future prediction" but yes in terms of practicality. MITM is the worst possible of all attacks because it leaves traces and it is difficult to hide. There is a large chance of discovery. So this means it is only operated by someone who has no fear of the consequences. That rules out most fraudsters, who rely on not being seen at all. There *are* models of who does MITMs and they are not the sort that you or I worry about, but as it happens, they are the sort that "dissident in China" needs to worry about. He should worry about them. Not us.
BTW, the most likely target for an MITM - direct protocol MITM - is SSL or S/MIME. IMHO. The rant's on the site somewhere, I'm sure you've read it.
> If we put all our eggs in the opportunistic crypto basket, security could be completely compromised by such measures.
No, OC is not a single basket of eggs, it is a way of constructing baskets. Yes some implementations might be vulnerable to MITM's. SSH, for example, but that just means some anti-MITM will be added in the next release after reports of MITMs. It'll happen so fast you won't even notice... Consider it like a buffer overflow.
(On the other side, we've been asking for anti-phishing MITM for what ... 2 years now?)
> Even PGP, the archetype of P2P crypo, added key signers because of this problem.
Right. They responded to a threat. I'm not sure it was a real threat or not, but they did respond. PGP is OC. It opportunistically does what is needed to get comms up and going. That's a perfect example.
> The real problem with opportunistic crypto is that its benefits are global while its costs are local. The benefit is primarily political: that it can increase the amount of traffic which is encrypted, thereby making it harder to create a global surveillance network.
Let's come back to that when we've stabilised what OC is and isn't.
> But there is not much benefit to the actual end user, because he can never be sure that he is really getting any security.
He has exactly the amount of security the system gives. No more no less! SSH protects him from most all attacks except those on the node and a rare exceptional MITM. SSL protects except from those attacks on the node and a possible CA attack. As attacks on the node dominate by 3-4 orders of magnitude, by what basis can you say one is more secure than the other?
I can show why SSH is 100 times more secure than SSL .. simply by counting up the 100% usability of SSH in its target market as against the If he really needs security, like the case of a dissident in China, he better not depend on opportunistic crypto!
If I am *not* a dissident from China, I don't want to pay for you to protect the dissident in China. If I *am* a dissident, I'd better know better than to trust a weak security model, else I'll be dead. Whether it be OC or no-risk Crypto (which hides the risks...).
By what theory of anything are you telling users that they have to be protected like dissidents in China?
Posted by: Iang at January 31, 2005 06:24 PMI can't agree with any security analysis of an INTERNET protocol that doesn't take the MITM threat seriously. Did you see the analysis yesterday by David Pollack of Skype security, http://www.interesting-people.org/archives/interesting-people/200501/msg00234.html ? He argues that super nodes can act as MITMs and intercept conversations. Would you suggest that this is not a realistic threat and we shouldn't design a communication system to deal with it? Should Skype users not be concerned about whether their conversations are at risk due to this class of attacks?
I can't agree with your claim that MITM is "no risk". The internet is an insecure network with many parties who are ideally situated to act as MITMs. I would certainly hesitate to use an internet protocol which was vulnerable to MITM attack, unless the data I was sending was so valueless that I wouldn't care if it were sniffed. And in that case, why would I be using crypto at all?
Posted by: Cypherpunk at January 31, 2005 11:18 PMOne other point though, I'm not sure I fully understand what you mean by opportunistic crypto (my earlier comments reflect this confusion). I would suggest that this term applies to STARTTLS in email; or to John Gilmore's original goals of the FreeSwan project, to "encrypt 5% of Internet traffic by Christmas". These projects use crypto when conditions are right, when both ends of the comm link happen to be set up to do it. You could get the same effect with a transparent PGP email proxy that would automatically encrypt a message if a key for the recipient happened to be available. Sometimes crypto is there, sometimes it isn't, and it may not be particularly apparent to the end user whether crypto is being used or not.
See for example http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/opportunism.spec which describes FreeSwan's concept. This actually was certification based, designed around DNSSec which never came into existence but would have put certified keys into the DNS. Opportunistic encryption in this sense is perfectly compatible with MITM resistance including TTPs and CAs.
My confusion is that you seem to use OC to apply to ssh, which certainly is not "opportunistic" in this sense. When you use ssh, you know that you are getting crypto. You may not be 100% sure who you are communicating with using your crypto; you are not fully protected against a MITM (hence my comments above), but you can be sure you're encrypting to some kind of key. This is not the case in the other examples of opportunistic crypto I just listed.
Are you using OC to refer to crypto where you intentionally don't worry about MITM attacks? Or could you more clearly define what differentiates OC from other cryptographic and risk assumptions?
Posted by: Cypherpunk at January 31, 2005 11:23 PM> I can't agree with any security analysis of an INTERNET protocol that doesn't take the MITM threat seriously.
So ... you don't agree with TCP, IP, Email, IM, HTTP, in fact ... the only protocol you would agree with would be SSL?
None of those protocols take MITM seriously, and they survive, more or less. Spam for example is a breach of the 'higher email protocol' in exactly the same way that phishing is a breach of the 'secure browser protocol.'
> Did you see the analysis yesterday by David Pollack of Skype security, http://www.interesting-people.org/archives/interesting-people/200501/msg00234.html ? He argues that super nodes can act as MITMs and intercept conversations. Would you suggest that this is not a realistic threat and we shouldn't design a communication system to deal with it?
Correct. I would argue that is not a realistic threat because a) it hasn't happened, b) it is too expensive. (Caveat: I skimmed it v. quickly, I am dealing with a *real* threat today....)
> Should Skype users not be concerned about whether their conversations are at risk due to this class of attacks?
No, they should be unconcerned. If someone goes to that degree of trouble to listen to their phone calls, then they have really serious problems, and they'd better know it. In which case they either take much more extreme steps than "download some OC tool off the net and use it out of the box" or they're dead.
Skype OTOH should be concerned because if it ever happens they'll look like idjits.
> I can't agree with your claim that MITM is "no risk".
OK, in economics terms it goes like this: there are practically no reported statistics or events of aggressive MITMs. Yes there are laboratory MITMs, and there are kits. But nobody uses the kits to conduct attacks (where an attack is an actual damage causing event as opposed to debugging their own networks).
So, if it doesn't happen, it is not a risk. Theoretical risks don't count, not in this life or the next. Body armour is not comfortable for sleeping in. And moving ones house away from the meteor can be a bit of a pain.
> The internet is an insecure network with many parties who are ideally situated to act as MITMs.
Yes, it could be done in theory. Economics predicts that it won't be done in most use cases, and experience supports the economics arguments. Only the crypto community doesn't get this: the crypto community continues to believe that which is not supported by economics nor by practical experience over the last N years.
(Caveat: I'm not saying it is never going to happen. In fact, we know where it is going to happen - with SSL. But until it happens, Internet protocol engineers would be wise to not put protection in for it.)
> I would certainly hesitate to use an internet protocol which was vulnerable to MITM attack, unless the data I was sending was so valueless that I wouldn't care if it were sniffed. And in that case, why would I be using crypto at all?
That's a rationalisation on your part, reversed to match your model. In practice you conduct risk protocols every day of your life. If you use a credit card in a restaurant then you engage in a risk protocol. If you purchase from Amazon you engage in the same. Like every consumer out there, you conduct your business with a risk approach so quickly you do not even realise it.
(The risks to using a CC with Amazon: an SSL protocol attack - probably about zero. Your PC is raided - about 1% risk, check the PC corruption figures. Amazon is hacked - about 0.01%. Amazon insider sells your info - about 0.1%. Banking infrastructure sells your info - about 0.2%. Chance the credit card company will stuff you - about 1%. Buying from Amazon is chock full of risks and I'm shocked that anyone would consider it ;-)
(Risk of an MITM over a non-SSL credit card accepting form - 0.00001% Why? It just ain't worth the grief, especially when it's much better to either pay of an insider or hack a DB.)
Posted by: Iang at February 1, 2005 01:16 PMCypherpunk,
You are quite right in that there isn't a good definition for Opportunistic Cryptography. It is a term of art that has arisen somewhat to explain the different way of doing things in opposition to the classical no-risk model.
A quick definition might be: do what you can with crypto for no cost, and leave risks that can't be covered to a higher layer or a more expensive variant. Or it could be considered to be risk-based cryptography at the cheap end.
SSH is opportunistic because it does a good secure connection, but it explicitly compromises on the M1TM because it can't do it without compromising on convenience. BUT note that it gives you tools to overcome the M1TM if you yourself desire to avoid convenience. It also covers M2TM and all others... (notice the cunning placement of digits!)
SSH is simply the most obvious of the examples, because it sits very well alongside SSL in characteristics, and also achieves more security (by deploying further). PGP is another one that is OC, but it looks very different, and it didn't succeed as well as SSH.
What FreeSwan was doing is OC. "Sometimes the crypto is there" is a compromise, as is "maybe an M1TM can sneak in." They're all just compromises that the authors felt packed the best punch for their crypto buck.
So, no. OC is not "accepts MITM." OC is "accepts and lists some compromises, but does the best it can."
(It's a good question though.... we need to define it somehow.)
Posted by: Iang at February 1, 2005 01:32 PMOk, having read the Skype attack, I concur with my earlier assessment. The main risk is of Skype looking like idjits.
http://www.interesting-people.org/archives/interesting-people/200501/msg00234.html
The author contradicts himself. This "easy" attack requires that the attacker dissassembler x86 code... mounts a box that sits there and acts as a supernode ... and hopes to set up an MITM. Roight.... In your dreams.
The author correctly picks up that this is the sort of attack that a government could do. For the most part you can be sure they won't be, unless they care not a jot. There are two cases where they won't care a jot. One is a very very high value target where they simply have to take the risk of interception or warning off the target.
The other is where they are a 3rd world govt that doesn't care about liability. I.e., they won't let the courts or anyone interfere, they'll just shoot you or lock you up forever without charge.
Otherwise, a government won't take the risk of being spotted doing this attack. They much prefer passive ones and pen traces. And in the meantime, no doubt, Skype will probably move to fix the attack.
So, theoretically, a nice attack! In practice, be careful not to hyperventilate, it's bad for you.
Posted by: Iang at February 1, 2005 02:56 PMThere seems to be an over-compensation in the dismissal of MITM attacks and the need for SSL.
I could agree with the statment:
"Attack againts the node are far more likely than attacks against the channel, so more attention to node security than channel security is warranted. Don't let the lock in your browser fool you into thinking you're safe."
But that's a far cry from "SSL and TTPs are unneeded"
The body armor and meteor analogies are misguided. People simply choose to accept the risk in favor or quality of life. Some folks ARE looking for ways to protect from meteors and there are thousands of dead people who wished they wore body armor. The vast majority of police officers never get shot or fire thier guns in their entire careers. That's not an argument to have them give up their guns or armor.
Similarly, MITM or sniff attacks are really uncommon because attacking the nodes is SO much easier...once we start really securing our PC, servers and databases, THEN crooks will move to softer targets...THEN they'll put the effort into MITM an sniffing. So might as well be protected now.
Posted by: Threat at April 22, 2005 02:12 PMThe body armour analogies are there to show that when people go shopping, they choose not to wear their body armour. They make a statistical calculation to deal with the risks, and indeed, a couple of years back in Washington DC, people *did* wear body armour going to the shops. Indeed, there are entire countries that have police without guns and without body armour, which means we can measure the effect.
In contrast, merchants are forced to use encryption to take credit cards. Yet they are not forced to secure their machines. So we have a risk that happens in bulk and we don't care ... opposed to a risk that happens never and we care an awful lot.
Dismissing MITM is a scientifically justified assumption. There are no stats, no measurements, and practically no recorded incidents on the net, over unprotected channels. Even over wireless, all the hype is there, but every reported case turns out to be something else. In fact the only case of MITMs that are known to occur are over SSL - in phishing, and in chinese proxies. Go figure.
Posted by: Iang at April 23, 2005 08:43 AMI agree with everything you say except for the "dismissal" part. I believe there are no documented thefts from listening to the wire. Yet. The space shuttle never blew up until it did, either, and passenger airliners were never used to attack buildings in the US, until they were. If we can see the risk, it's reasonable to try to reduce it if practical, but we must NOT, as I think we agree, let that act as a smoke screen that prevents us from addressing the far BIGGER risks (where all the attacks ARE happening).
My perspective is this: I'm not much of a hacker or a crypoanalyst, I probably couldn't locate and access even an unsecured credit card database from the Internet if you paid me. But I'm a decent technician and a decent social engineer. If _I_ wanted to to steal credit card numbers, I would probably try to gain physical access to some networking equipment in the vicinity of a shopping site that DOESN'T use SSL, and plug in a sniffer. Of course, even before that, I'd just put on a hard hat and tap the voice phone lines from outside. And before most places stopped using imprinters and blocking the account numbers from reciepts, I'd have probably just applied low tech social engineering to the teenager behind the counter at a retail outlet... but you get the point.
When people do start to secure thier machines, the threats will move to the areas that are less secure, and that's when people will be glad they already have SSL in place.
Posted by: Threat at April 29, 2005 03:20 PM