WiFi routers: from lockdown to lock-open
Lockdown worries
The FCC's concern in this area relates to spectrum use, of course. WiFi routers are radio transmitters, so they must abide by the rules on how they can transmit; these include limits on allowable frequencies, maximum power, and more. To gain the required FCC certification, a vendor must demonstrate that a router cannot be operated in ways that violate those rules. Regulatory compliance was used as an excuse for years by WiFi chipset manufacturers that did not want to release drivers or hardware documentation. That excuse has broken down over the years, but, for a while recently, it seemed that the FCC was contemplating a required lockdown of router firmware as a way of ensuring compliance. By some readings of the proposed rules, the installation of distributions like OpenWrt on home routers would no longer be allowed.
Blocking third-party firmware installation would be a clear step backward for a number of reasons. Routers as shipped by vendors are often insecure from the outset and, given that almost none of them ever receive software updates, they all become more insecure over time. Independent router distributions, instead, can be updated to fix security problems; they can also enable all kinds of functionality that was not envisioned or enabled by the original vendor. And free-software distributions, in particular, have been the platform on which a great deal of networking development has been done. Improvements in IPv6 functionality, bufferbloat reduction, and more have been implemented by the free-software community on open routers.
In an attempt to head off a router lockdown, a group of influential developers has filed a letter to the FCC [PDF] calling for the proposed rules to not be implemented. Since the filing of the letter, the FCC has stated that it does not intend to block third-party firmware installation. But the letter goes far beyond simply asking the FCC not to lock down routers; indeed, the FCC has been asked to open them up radically.
New mandates requested
The letter asks the FCC to change its certification requirements for WiFi
routers and add a new set of mandates. The first of those is that the
source code for the router's "device driver and radio
firmware
" must be made freely available in a
"buildable
" form so that this code could be reviewed by
outsiders. There is no mention of requiring that this code be made
available under a free license, though the rest of the document makes it
clear that this is what the authors would prefer. It also does not require
that users be able to install modified versions of the software; this was,
your editor has been informed, an oversight during the drafting process.
Requiring the release of this code would clearly change the situation for router developers and users. It would bring about an end to binary-blob WiFi drivers, which would be a welcome change indeed. Even if a given driver were to be made available under an incompatible license, clean-room techniques could be used by others to develop a free driver. Opening up the radio software would shine a light into a dark corner of these systems, teaching us a lot about how they work, even if the software could not be replaced. A crucial piece of consumer-level infrastructure would become more open.
The advantages of this openness would be many, starting with the ability to audit the software for security issues and to fix them when they are found. Given the record of vendors in this area, improving the community's ability to provide security support can only be a good thing. The letter, though, asks the FCC to go further and to require the provision of security updates. In particular, any vulnerability with a CVE number that affects a router must be fixed by an update within 45 days of disclosure during the warranted lifetime of the router.
Finally, the FCC is asked to make it clear that lockdown of router devices is not required by its regulations:
The letter appears over a large number of well-known names, including Dave Täht and Vint Cerf (the principal authors) along with Jim Gettys, David P. Reed, Bruce Schneier, Daniel Geer, Kathleen Nichols, David Farber, Steven Bellovin, Linus Torvalds, Paul Vixie, and many more, including an obscure LWN editor. As a whole, it makes an impassioned case for free-software development as the best path toward high-quality and secure networking software.
Toward a better Internet
As a defense against further lockdown-oriented rules, it is likely to be effective, especially since the FCC is claiming that it does not intend to impose such rules. The mandates may find a more difficult reception, though. There seems to be no doubt that there would be fierce resistance from vendors and manufacturers; overcoming such resistance could be hard in the absence of wider public understanding of the nature of the problem.
To some, an open-routers mandate might actually look like a step backward for security, and for the security of the wireless spectrum in particular. But most users have no desire to run their routers out of compliance; there does not appear to be anything resembling a widespread interference problem caused by modified devices. On the other hand, routers with security vulnerabilities and even deliberate back doors are widespread indeed. Rules that address the latter problem will do far more to ensure that our routers behave themselves than anything aimed at locking down access to the radio hardware.
It would be surprising if this letter to the FCC were to convince them of
that point on its own. But one has to start somewhere, and this is a
strong start with a lot of big names behind it. With luck, it may just
push us toward a world where our networks work better, our hardware is more
secure, and routers serve the interests of their owners. That seems like
an outcome worth going for.
| Index entries for this article | |
|---|---|
| Security | Home network |
| Security | Internet/Routers |
Posted Oct 14, 2015 13:51 UTC (Wed)
by Darkmere (subscriber, #53695)
[Link] (1 responses)
Posted Oct 14, 2015 15:52 UTC (Wed)
by Felix.Braun (guest, #3032)
[Link]
Posted Oct 14, 2015 16:08 UTC (Wed)
by ch (guest, #4097)
[Link] (26 responses)
Posted Oct 14, 2015 16:37 UTC (Wed)
by fhuberts (guest, #64683)
[Link]
At least these people took action and I applaud them for it.
Posted Oct 14, 2015 16:51 UTC (Wed)
by jg (guest, #17537)
[Link] (23 responses)
Posted Oct 14, 2015 17:51 UTC (Wed)
by rahvin (guest, #16953)
[Link] (2 responses)
Posted Oct 14, 2015 19:57 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (1 responses)
Posted Oct 14, 2015 20:12 UTC (Wed)
by rahvin (guest, #16953)
[Link]
WiFi isn't going to fall under a broadcast medium any time soon. Wifi has also been exempted from many of the restrictions by the very nature of being under part 15, but also because the FCC considers it point to point not broadcast. Any attempt to regulate it like they do broadcast is going to get the FCC stomped in court.
Posted Oct 14, 2015 18:05 UTC (Wed)
by xtifr (guest, #143)
[Link] (4 responses)
A reasonable complaint for the Federal Trade Commission (FTC), perhaps, but this was addressed to the Federal Communications Commission (FCC).
A multi-pronged attack might be a useful thing to pursue in the future, though.
Posted Oct 14, 2015 22:19 UTC (Wed)
by smckay (guest, #103253)
[Link] (3 responses)
The FCC is charged with managing the EM spectrum for the public good, and often that means commercial use, which means a market. If the use of a particular band isn't benefiting the public, or isn't benefiting the public as much as it could, that's the FCC's business. Whether the cause is market failure or not isn't super relevant.
Posted Oct 23, 2015 4:26 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (2 responses)
... in the US.
Posted Oct 24, 2015 18:15 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Oct 24, 2015 20:59 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Posted Oct 14, 2015 18:48 UTC (Wed)
by wahern (subscriber, #37304)
[Link] (14 responses)
And the question here is not whether there _are_ sufficient such forces at play here to fix the problem[1], but whether there _could_ be within a reasonable time frame. We should try to answer those questions before enlisting the power of the state--at the very least it informs us how we should enlist the state, and how successful the state could be.
It seems to me the reasons firmware rots are 1) upgrading firmware on older hardware is currently quite risky and thus costly, and 2) there's little financial incentive for vendors to invest in the problem. Hypothetically, the former could be addressed by the FOSS community making it easier to upgrade the most at-risk components, and the latter by making upgradeability a marketable feature.
I believe the FOSS community could accomplish #1--doubtless the solutions already exist, they just need some polish. The hard part is #2. But there are models. Contemporary organic food[2] preferences of most consumers are largely based on non-sense promulgated by small groups of activists; and yet those activists and the preferences they've crafted are transforming the largest industries in society. So if we want to be coldly rational about it, we should try learn from successful activists, especially how they appeal to and shape public preferences. Not just activists, but corporations. Look at Apple--while I like Apple hardware and think OS X is pretty neat, most Apple customers' preferences aren't substantiated by knowledge--it's all branding. We need to move beyond the EFF and similar organizations technical arguments, which have had checkered success, and examine how the public makes value judgments in general.
[1] The problem being the general social cost of insecure routers. But let's not forget that for the most part my neighbor's insecure wi-fi router doesn't directly effect me, and the indirect cost is negligible--mostly because his preferences will effect the quality of COTS solutions available to others. Where it does strongly effect me is when a handful of entities--gov't, financial institutions, etc--use insecure infrastructure. So partial solutions might be almost as advantageous as global solutions. For example, it might be more efficient to enlist privacy law to increase the the cost of insecure infrastructure and thus drive demand for better solutions that way, rather than simply mandating particular technical solutions. (I'm not a fan of European-style privacy rights--like most Americans I happen to place more value on free speech and transparency--but I'm cynical enough to accept leveraging the debate for other benefits.) We should always remember that many technical mandates can and will be worked around, especially when there's a strong financial incentive to do so, diminishing the benefit of the mandate.
[2] To be clear some organic preferences are sound, and some debatable. But if we're being honest, most of the preferences that have been internalized and expressed by the public are pretty much irrational on their face.
Posted Oct 14, 2015 19:04 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
The real world would strongly disagree with your assertion.
> In the real world there are _always_ counterveiling forces against pure, self-interested, coldly rational behavior.
If by "counterveiling forces" you mean "something else comes along and renders the whole thing moot", I might agree with you. Microsoft won the BSD wars, after all.
Posted Oct 22, 2015 9:11 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
> The real world would strongly disagree with your assertion.
Actually, as it is commonly understood, there really is no "tragedy of the commons". In a LOCAL market, the LOCALS manage resources very successfully. Yet as commonly understood, the tragedy of the commons is when the commons is destroyed by insiders for short term gains.
The term comes from the enclosure of the English commons. As London grew and food needed to be brought in, the local gentry realised that if they could get more land, they could make big profits shipping food. So, contrary to naive expectation, enclosure started CLOSE to London and spread outwards.
Likewise, the Scottish Lairds realised they could make more money raising and selling sheep, than by charging rent to the peasants on the land.
In both cases, the tragedy was driven by EXTERNAL forces.
Like in Africa too - the big city politicians saw all these nomadic people and thought "this should be farmland". So they enclosed it, gave some of to the nomads, and most of it to their cronies - who promptly overfarmed and desertified it! Again, EXTERNAL forces.
The tragedy of the commons is just a normal power-play, where outsiders come in, think they know best, impose their version of how things should be, and it almost invariably goes badly wrong because they don't have a clue ...
Cheers,
Posted Oct 28, 2015 9:12 UTC (Wed)
by pjm (guest, #2080)
[Link]
Can we get back to discussing what to tell the FCC to tell router manufacturers what they should be doing?
Posted Oct 14, 2015 19:44 UTC (Wed)
by klbrun (subscriber, #45083)
[Link] (3 responses)
Posted Oct 14, 2015 20:16 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Hey, it worked for organic food!
Posted Oct 28, 2015 18:52 UTC (Wed)
by markhahn (guest, #32393)
[Link] (1 responses)
Posted Nov 12, 2015 14:20 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Oct 14, 2015 21:10 UTC (Wed)
by dskoll (subscriber, #1630)
[Link]
In the real world there are _always_ counterveiling [sic] forces against pure, self-interested, coldly rational behavior.
Yes, but in the real world a lot of those countervailing forces are government regulations---at least those countervailing forces that have any effectiveness.
Posted Oct 15, 2015 9:39 UTC (Thu)
by NAR (subscriber, #1313)
[Link] (4 responses)
Posted Oct 15, 2015 13:00 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (3 responses)
Automatic updates that you can opt out of would be a reasonable compromise. Most consumers wouldn't know or care about opting out and the few who do care because they want custom firmware presumably are more savvy than average and are more likely to keep on top of security fixes. Even if they don't keep on top of things, there will be far fewer of them to damage the ecosystem than if no-one had automatic updates.
Posted Oct 20, 2015 19:08 UTC (Tue)
by erwbgy (subscriber, #4104)
[Link] (2 responses)
Posted Oct 20, 2015 19:12 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link]
Posted Oct 22, 2015 9:15 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
So no change there, then.
At least if we have updates, the ISPs can then block routers which have been compromised or not updated and we have some sort of stick to make people care (not that that's what we want to do, it's what we may have to do). Oh - and many people have their routers supplied by their ISPs, so they can do bulk updates and/or replaces, as required.
Cheers,
Posted Oct 23, 2015 4:49 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Organic food preferences are driven by recurrent food scandals. Whether such scandals are blown out of proportion or not (and unlike you I won't pretend I know either way[*]) they're effective anyway because human beings react to emotions and not to proportions or any other kind of number. Numbers are just too abstract. One interesting exception: money. Money is about numbers... and about emotions even more.
Whether some important change happens through regulation or free market forces, it's always rooted in people's emotions either way. In other words, in democracies not much will change as long as John Doe doesn't give a sh*t about his Wifi router. Try some scandal?
[*] except for induced sugar addiction and obesity; this scandal doesn't even need to be blown out of proportion.
Posted Oct 19, 2015 3:01 UTC (Mon)
by zblaxell (subscriber, #26385)
[Link]
Very little purpose-built AP hardware in the field today is this clean.
L1/L2 binary blobs are stored on flash in a filesystem, loaded into RAM and validated by the host CPU running way above L2. To regulate L2 is to regulate all of the layers above L2 that touch code on its way from persistent storage into the CPU of L2 hardware. Open source people don't want the higher layers locked to protect L2, but if the higher layers are not locked then L2 is (in theory) accessible to unqualified users.
L2 CPUs sometimes have unfettered read/write access to all the RAM in the system. Why hack a two-month-old Linux kernel running all the latest CVE mitigations when there's a five-year-old binary RF blob that can read out all the secret keys and install implants? This is probably where the request for mandatory CVE updates is coming from. Open source upper-layer people want L2 to protect the higher layers from attacks from below, and if the vendors won't do it (which they won't), then the open source people want to handle L2 themselves.
Posted Oct 14, 2015 18:10 UTC (Wed)
by felixfix (subscriber, #242)
[Link] (3 responses)
Posted Oct 14, 2015 18:36 UTC (Wed)
by speedster1 (guest, #8143)
[Link]
Posted Oct 16, 2015 14:45 UTC (Fri)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Oct 22, 2015 9:17 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Oct 16, 2015 14:44 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link] (1 responses)
Posted Oct 16, 2015 16:27 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link]
The compatibility with open-source software seems to me to be superficial at best. The proposed rule would require an FCC-approved "GROL+Radio-licensed developer" to sign off on the source code for any binary distribution of a WiFi driver. As I see it, that means that no one can compile their own standard Linux kernel (with the WiFi drivers enabled) and distribute the binaries to others without obtaining approval from someone with that license. Every Linux distribution would need to keep someone around with that license to sign off on any updates to the kernel.
The proposed rule should be modified such that only OEM software requires sign-off. Anyone installing third-party software is responsible for their own compliance. Or better yet, scrap the proposed rule entirely; this isn't a problem which needs fixing. Either way, individuals should be permitted to work together to develop, share, and utilize their preferred software, including WiFi drivers, on their own hardware without licensing requirements or other third-party interference.
Posted Oct 16, 2015 16:34 UTC (Fri)
by joshuagay (guest, #88423)
[Link]
I think you should add a correction making it clear that this is not a true statement. Or in the very least that it is a bit cofusing or misleadig. Obviously when people discuss firmware in this context they are talking about firmware that could in some way control the operation of the RF devices (e.g., setting the region via he kernel Linux can have some devices operate in ways not permitted by the FCC). In that blog post you link to, the FCC makes it pretty clear that it *does* intend to block owners from doing third-party firmware installations on their device: "the proposed rules would require manufacturers to select the security method they deem appropriate to prevent modifications that take the device out of compliance."
The FCC goes on to create furthr confusion around the issue by stating that the proposed rules are also trying to provide the ability for the company seeking authorization to be able to list authorized parties (aka third parties) that are also allowed to provide firmware udpates. However, this certainly would not allow the owner of a device to have the freedom to install third-party firmware of their choice on the devices they purchase. It will only allow owners of a device to install firmware updates provided by authorized parties, and those authorized partie may be the authorized seller or a third-party partner of the authorized seller that has also been granted the authority to provide software udpates. This is a peculiar and misleading use of "third-party" in this context and I think we should all be careful not to spread this sort of confusion.
Posted Oct 22, 2015 11:31 UTC (Thu)
by toyotabedzrock (guest, #88005)
[Link] (1 responses)
Posted Oct 23, 2015 20:41 UTC (Fri)
by dlang (guest, #313)
[Link]
specifically the channels shared by weather radar in some locations (DFS channels)
Posted Nov 3, 2015 22:02 UTC (Tue)
by poruid (guest, #15924)
[Link]
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
So much so that I signed the letter as OLSRd mesh protocol maintainer.
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
We have here a classic market failure, [...]
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
Wol
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
The problem with automatic upgrades is that if the keys to push the upgrades were to be stolen then it would be possible to push out malicious software to a large number of devices. And if it were not possible to somehow update these devices then users would have no other option but to switch them off, if they even noticed that there was an issue.
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
Wol
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
Wol
Bruce Perens has proposed a compromise proposal that still enables FLOSS, but doesn't require proprietary vendors to release their source code. I suspect that's far more likely to be an acceptable change to the proposal. For more: http://apps.fcc.gov/ecfs/comment/view?id=60001303304.
Perens' proposal
Perens' proposal
Please post correction about FCC claim to permit firmware installation
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
WiFi routers: from lockdown to lock-open
Joep Lunaar