WPA2 was kracked because it was based on a closed standard that you needed to pay to read


#1

Originally published at: https://boingboing.net/2017/10/17/sdo-eschaton.html


#2

because it was based on a closed standard that you needed to pay to read

No, I don’t think that’s the reason why.


#3

Exactly. It was cracked because there was a bug.

It took this long to find publicly because you needed to pay to read the spec. It should have been found (and fixed) years ago.

Cory’s argument is sound, but his wording flawed.


#4

bugs this age are found in open standards as well, and it certainly wasn’t cracked BECAUSE one had to pay for a copy of the standard. you can’t logically conclude one from the other, that is nonsensical.

it would be great if more of our standards were open and free to review, and there are honest reasons to want this without resorting to non sequitur.


#5

I would LIKE to see a court ruling that since standards constitute “A method or means of operation,” they were not subject to copyright protection, and instead were subject to patent law. Very similar to the way that copyrighting a cookbook does not protect the underlying way of baking a cake. The protection of the description of HOW to comply with the underlying standard would seem to be so tightly bound to the actual means of operation to fall afoul of the Idea/expression divide. But then, sometimes I’m a dreamer.


#6

it isn’t really.

the spec is and has been available online in pirated form since the beginning to hackers.

the $170 dollar price for a copy isn’t even a deterrent to most security researchers who regularly have to spend much more to research various security protocols or equipment.

bugs of the same age exist in open free specs as well.

It is a logically fallacy to infer one from the other. the term for this sort of logical fallacy is non sequitur. the argument is not logically sound. the wording is fine, it is the logic that doesn’t follow.

I’d love to see most standard be open and free for review, and there are legitimate arguments for doing so without justifying based on false arguments. If the EFF wants to win any victories for freedom they should take care to make sure the arguments and reasoning are sound otherwise they set the causes back and make their side too easy to dismiss. also know as doing more harm than good. (see pretty much every w3c article on BB)


#7

It should have, but keep in mind it wasn’t just a bug in the protocol itself (which certainly wasn’t developed in a vacuum), but a big reason for the severity of the issue is another (related) bug in a widely used and open source implementation of this standard.

What it really comes down to is “shit happens”. Being open source vs closed source or free to play vs fee to pay doesn’t make you immune from mistakes. I mean, a single missing curly brace in an open source component used by Mac OS/iOS completely broke SSL/TLS.


#8

I myself have participated in ISA standards committee activities and I can tell you that what they are saying here is absolutely true. ISA works jointly with the IEC (International Electrotechnical Commision) to develop standards for automation and manufacturing. I could go on for many boring pages about prescriptive standards that describe how a technology works (like a network protocol for example), and these types of highly prescriptive standards committees can get really bogged down in vendor interests. I have personally seen technology vendors paralyze and hobble standards committees, burying standards in technical comments to prevent their progress, putting representatives on the committee that deliberately create chaos and confusion, etc. Standards are good. Standards ultimately promote choices, but it’s too easy to pervert and sabotage the standards process. The old saying in the automation business is that if you really want to screw up a standard, join the committee!! Most of the people on these committees are well meaning hardworking people that want the standard to succeed. It’s really too bad.


#9

Here’s a much better (IMHO) write up of the same argument:

I found this on Hacker News this morning.


#10

I totally fell for that picture, and assumed the price was $8,888. That made the whole article seem reasonable.


#11

Not precisely the same because it was an implementation-level bug and not a protocol-level bug, but Heartbleed is an excellent example of The Power Of Open Source failing to live up to its “many eyes” promise.


#12

The part about dysfunction in standards committees is salient, if possibly over exaggerated. Thats the down side of bringing together people in different sectors and competitors to try to hammer out a standard. Everyone has their own use cases and agendas, and it is not easy to make everyone happy on the best of days, and when some members push choices that are worse because they will have a competitive advantage it can get really bad.

The open standards issue on the other hand is not a factor. I am all for open standards, but they don’t stop people from making mistakes. In practice the 802.11 family of standards are widely available to anyone who wants them. The cost of official copies is negligible compared to the hardware and personnel costs of carrying on this type of research in a professional or academic environment, and they are easy enough to find online that any curious hobbyist could have easily downloaded a copy for free.


#13

isn’t wpa2 part of 802.11? which is free to download from IEEE?


#14

Interesting, thanks for sharing, that was a better writeup.

from that writeup:

one of the primary flawed pieces required for the exploit isn’t even in the spec…

ironically, it was an often reused bit of common shared pseudo code (open source) implementation of the handshake state machine, which resets the counter in an unsafe way that is the basis for this exploit.

also the exploit is worst on android where replaying message #3 actually sets an all-zero key, and that code implementation has been completely open to scrutiny for free by anyone.

so um yeah…the minimal amount of investigation pretty much eliminates the conclusion in the title.


#15

The only way I’ve seen that work is when the government writes the rules (not references to the rules, the ACTUAL SAME RULES) into the law. They almost never do this. I can think of one instance. But it works.


#17

So is there an open source alternative to WPA2?

If not why not?

If so why don’t I know about it?


#18

WPA2 is already open in the sense that it’s an open standard. Despite what Cory seems to imply, I don’t think “spending hundreds of dollars” to access the full documentation is really going to deter a researcher. Then again, WPA2 is well known and understood so I’m not sure I buy that nobody found this bug up until now just because the IEEE had a paywall.

Part of the reason Wi-Fi works is because of its ubiquity due to standardization and industry adoption.

You could certainly write your own super awesome alternative to WPA2 but how do you get anybody else to use it? Then, of course, you run into this:

What it comes down to is KRACK is a problem. It’s not an insurmountable problem despite all the FUD out there.


#19

Reminds me of heartbleed.

Not many people work on these infrastructure projects and it requires more math than many programmers have learned.


#20

Any shitty programmer can throw together some sort of crypto. Doing it well requires very specialized skills. Even the experts get it wrong more often than they get it right.


#21

As you say, people fail at this even when it’s their job/product.