How To Avoid Future Krack-Like Failures: Create Well-Maintained 'Fat' Protocols Using Initial Coin Offerings
from the blockchain-cryptocurrency-fashionable-moi? dept
It came as something of a shock to learn recently that several hugely-popular security protocols for Wi-Fi, including WPA (Wireless Protected Access) and WPA2, were vulnerable to a key re-installation attack (pdf). A useful introduction from the EFF puts things in context, while more technical details can be found on the krackattacks.com site, and in a great post by Matthew Green. As well as the obvious security implications, there's another angle to the Krack incident that Techdirt readers may find of note. It turns out that one important reason why what is a fairly simple flaw was not spotted earlier is that the main documentation was not easily accessible. As Wired explains:
The WPA2 protocol was developed by the Wi-Fi Alliance and the Institute of Electrical and Electronics Engineers (IEEE), which acts as a standards body for numerous technical industries, including wireless security. But unlike, say, Transport Layer Security [TLS], the popular cryptographic protocol used in web encryption, WPA2 doesn't make its specifications widely available. IEEE wireless security standards carry a retail cost of hundreds of dollars to access, and costs to review multiple interoperable standards can quickly add up to thousands of dollars.
The obvious way to avoid this issue is to ensure that key protocols are all freely available so that they can be scrutinized by the greatest number of people. But the Wired article points out that there's a different problem in that situation:
Even open standards like TLS experience major, damaging bugs at times. Open standards have broad community oversight, but don't have the funding for deep, robust maintenance and vetting
It's another well-known concern: just because protocols and software are open doesn't necessarily mean that people will find even obvious bugs. That's because they may not have the time to look for them, which in turn comes down to incentives and rewards. Peer esteem only goes to far, and even hackers have to eat. If they receive no direct reward for spending hours searching through code for bugs, they may not bother.
So if we want to avoid major failures like the Krack vulnerability, we need to do two things. First, key protocols and software should be open and freely available. That's the easy part, since openness is now a well-accepted approach in the digital world. Secondly, we need to find a way to reward people for looking at all this stuff. As Krack shows, current incentives aren't working. But there's a new approach that some are touting as the way forward. It involves the fashionable idea of Initial Coin Offerings (ICO) of cryptocurrency tokens. A detailed article on qz.com explains how ICOs can be used to fund new software projects by encouraging people to buy tokens speculatively:
The user would pay for a token upfront, providing funds for coders to develop the promised technology. If the technology works as advertised and gains popularity, it should attract more users, thus increasing demand for the token offered at the start. As the token value increases, those early users who bought tokens will benefit from appreciating token prices.
It's that hope of future investment gains that would encourage people to buy ICO tokens from a risky venture. But it's not just the early users who benefit from a technology that takes off. A key idea of this kind of ICO is that the coders behind the technology would own a sizable proportion of the total token offering; as the technology becomes popular, and tokens gain in value, so does their holding.
This novel approach could be applied to protocol development. The hope is that by creating "fat" protocols that can capture more of the value of the ecosystem that is built on top of them, there would be funds available to pay people to look for bugs in the system, which would be totally open. It's an intriguing idea -- one that may be worth trying given the problems with today's approaches.
Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: cryptocurrency, funding, ico, krack, protocols, standards, wpa2
Reader Comments
Subscribe: RSS
View by: Time | Thread
Sometimes shit happens, but having projects be open source, freely able to be contributed to by anyone in the world, *and* have no paywalls to view the spec itself, will go a long way in creating more secure wireless standards.
If it's a cat-and-mouse game, everyone needs to be free to make a better cattrap when bigger organizations can't or won't.
[ link to this | view in chronology ]
Re:
We could also use digital currency to fund code reviews and bug bounties. Right now people can get hundreds of thousands of dollars for a bug, if they agree to keep it secret. It's generally believed criminals and governments are the ones paying; Google, Apple, and Microsoft can compete by offering large amounts, but most open-source projects can't.
[ link to this | view in chronology ]
Also, heirs of King Canute continue to claim that the law of gravity infringes on the national sovereignty of littoral provinces. And the Department of Mental Health announces progress on a discovering a cure for irrational numbers.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Nibble harder!
[ link to this | view in chronology ]
Oh, yeah, yeah right, great idea...
... worked great for Ethereum with the DAO.
All that code review from people putting real money into the thing kept anybody from draining $100M out of it for like a whole week! Almost like every "investor" expected to free ride on the review of others...
And it's really, really hard to pull the artificial grafted-on toll out of a protocol, thus removing the "fat" aspect...
Just more idiocy from ICO morons. The market does not fix everything.
[ link to this | view in chronology ]
*
I thought they already had lots of bytes....
[ link to this | view in chronology ]
Re: *
[ link to this | view in chronology ]
If the technology works as advertised and gains popularity, it should attract more users, thus increasing demand for the token offered at the start.
Since neither this article, nor the article it references includes any real information on this, can somebody explain what tokens actually are?
Because the vague descriptions provided don't exactly sound like there's any reason for them to actually rise in value. Or to have value at all.
Or the other interpretation, they might be just like stocks and therefore we've just replaced a company owning and controlling a "platform" with a company owning and controlling a "protocol." Little real improvement there.
[ link to this | view in chronology ]
Re: What are "tokens"?
[ link to this | view in chronology ]
About tokens/blockchain/ICO
IEEE Spectrum has some good intro articles in the October 2017 edition.
[ link to this | view in chronology ]
The thing you know... and the thing on which you opine...
Scott Greenfield rails against "law prawfs" who offer legal advice but haven't a clue how the real world works.
Techdirt rails against LEOs chattering about "golden back door key cuffs magic" but really don't have a clue how encryption works.
This article is in the same boat suggesting ICOs, something financial advisers from Jordan Belfort ("Wolf of Wall Street") to Prince Alwaleed telling people to STAY THE HELL AWAY FROM ICOs and that they're going to be the next Enron. Posters above me have already excoriated you for missing the entire point that buying IC is not "investing" and it's not "payment" and it's only a "gamble" with little upside and lots of downside.
We don't want to create a system where we pay real life coders, developers, bug-hunters, or experts based on a gamble in which they don't have any control of the dice, the roll, the size of the bet, or the payoff odds.
Sorry, Glyn, you're usually on-point, but this one missed the point by somewhere just north of 179.9°.
Ehud Gavron
Tucson AZ US
Don't follow me.
[ link to this | view in chronology ]
It Is Really That Big A Deal?
[ link to this | view in chronology ]
Re: It Is Really That Big A Deal?
It does when the enc is broken
[ link to this | view in chronology ]
Re: It does when the enc is broken
[ link to this | view in chronology ]
Re: It Is Really That Big A Deal?
Yeah, it's a good thing that there aren't any examples of massive vulnerabilities in common SSL implementations going unnoticed for years.
[ link to this | view in chronology ]
Re: Yeah, it's a good thing that there aren't any examples of massive vulnerabilities in common SSL implementations going unnoticed for years.
[ link to this | view in chronology ]
Re: Re: Yeah, it's a good thing that I don't know, but I've been told, you never slow down, you never grow old.
You're fixating on a single detail instead of on the main point.
The point of the article isn't that patching wifi vulnerabilities is our top priority. It's that vulnerabilities get overlooked, often for long periods of time, and we need to look at ways of fixing that problem.
If you're skeptical of Glyn's proposed solution, then that's a reasonable response that's relevant to the point of the article. Arguing wifi versus SSL is an irrelevant distraction, because if Glyn had been talking about Heartbleed instead of Krack, it would have made no difference whatsoever to the main point of the article.
[ link to this | view in chronology ]
Re: You're fixating on a single detail instead of on the main point.
This whole article is fixating on a “single detail”. Moody never wrote this article when Heartbleed came up, he’s only writing it now because of Krack.
[ link to this | view in chronology ]
Re: Re: You're fixating on a single detail instead of on the main point.
[ link to this | view in chronology ]
Nope
What we do need is a better patching mechanism, so fixes can be widely distributed more quickly and efficiently, and a better abuse detection system, so that an unethical hacker can't easily fly under the radar abusing a flaw they discover.
But ICOs are trendy, so, hey, there's that.
[ link to this | view in chronology ]
Re: Nope
If maintainers leave or are found to be untrustworthy (or at worst, had their GPG key/computer compromised), the affected keys will be revoked and in case of a compromise, all packages last updated by this maintainer are peer reviewed before being re-allowed into the package repositories.
It isn't glamorous, but it works fairly well along with mailing lists notifying users when essential security updates are available and the relevant CVE(s) that were fixed/backported (Common Vulnerabilities and Exposures).
No idea how it's done in a corporate environment, but if they aren't doing at least this much towards software update security, I would be disappointed, but not surprised.
[ link to this | view in chronology ]
So, as I read it, you have to buy a token to use the protocol. And as the protocol gets more popular, the price of tokens is supposed to increase which should logically encourage people not to adopt the protocol but to use alternatives. Whoever proposed this scheme doesn't understand network protocols at all. Bitcoin, for instance, isn't a protocol. It's an application which uses a protocol to communicate between nodes and to store data, but the monetary value is in the stored data, not in the storage or communications protocols. I say dump this proposal on the scrap-heap along with all the other technical proposals created by technically-illiterate managerial types.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Network protocols are already complex without the need to incorporate a cryptocurrency into every security-sensitive protocol, and this new (and needless) complexity is likely to only introduce security flaws. Also while ICOs may be a great funding strategy when a cryptocurrency is a natural part of your protocol, not every protocol needs or wants a cryptocurrency. And the last protocol to need a cryptocurrency is WiFi authentication, as higher level protocols are needed/used to rely transactions.
But yeah! ICOs are cool! So let's use those to fund security reviews of WiFi authentication! Despite the fact the added protocol complexity would likely only make the security problem worse.
P.S. The reason for the complexity of network protocols is because of the various requirements for rudimentary computer-to-computer communication that need to be addressed ontop of the physical connections between computers. That, and the additional backwards compatibility needed to deal with each operating system, ISP, etc all patching their networking stacks at slightly different times.
[ link to this | view in chronology ]
How is this not DRM for protocols? Also, how does that improve security?
Also, how is paying protocol developers in this way supposed to improve security? Where's the incentive to not simply sell your coins when they become valuable? Where's the incentive to not simply sell your coins when you've been informed of a show-stopping bug?
It used to be "but... Internet!" was presented as a solution to all sorts of random ills. Now it's "but... cryptocurrency!"
[ link to this | view in chronology ]