Last year, the FCC introduced new regulations requiring router manufacturers to implement software security to limit the power output in specific 5GHz bands. Government regulations follow the laws of unintended consequences, and the immediate fear surrounding this new directive from the FCC was that WiFi router manufacturers would make the easiest engineering decision. These fears came true early this year when it was revealed a large router manufacturer was not following the FCC regulations to the letter by limiting the output of the radio module itself, but instead locking down the entire router.
The FCC’s rules regarding the power output of 5GHz routers was never a serious concern; the FCC is, after all, directed to keep the spectrum clean, and can force manufacturers to limit the power output of the wireless devices. The problem comes from how manufacturers implement this regulation – the easiest solution to prevent users from modifying the output of the radio module will always be preventing users from modifying the entire router. Developers don’t like it, the smart users are horrified, and even the FCC is a little flustered with the unintended consequences of its regulation.
While the easiest solution to preventing the modification of a radio module is to prevent modification to the entire router, there is another way. The folks at Imagination Technologies have come up with a virtualization scheme that allows router manufacturers to lock down the radio module per the FCC directive while still allowing the use of Open Source router firmware like OpenWrt.
A demonstration of the capabilities of this next-generation router comes from the prpl Security Working Group and uses MIPS Warrior CPUs to create multiple trusted environments. The control of the router can be handled by one secure environment, while the rest of the router firmware – OpenWrt included – can be run in an environment more conducive to Open Source firmware.
The demo of a compartmentalized, virtualized router uses a dev kit consisting of a dual-core MIPS P5600 CPU running at 1GHz, and a Realtek RTL8192 WiFi adapter plugged into the USB port. The driver for the WiFi adapter runs under a secure hypervisor, making it secure enough to pass the FCC’s muster.
This build wouldn’t be possible without hardware virtualization in microprocessors and microcontrollers. Imagination Technologies has been working on this for a while, and only a few years ago demonstrated a PIC32 with baked in virtualization.
In the video below, Imagination Technologies demonstrates a MIPS board running three virtual machines. The first machine is running OpenWrt, the second is running a WiFi driver, and the third is running third-party applications. Crashing one machine doesn’t bring down the others, and the WiFi driver is locked away in a secure environment in accordance with the FCC regulations.
While it’s hard to imagine a router based on a MIPS board that would be cheaper than the already inexpensive router SoCs found in today’s routers, this method of secure virtualization is the best way to give consumers what they deserve: an open source option for all their devices.
It may be great for passing the rules, but not so great for users’ ability to patch gaping holes in security once the manufacturer stops supporting that device.
That’s precisely what it is good for – the radio MAC can run in one Vm, managing power output levels, while the higher level Wifi protocols (e.g. WPa, etc.) can run in the user upgradable VM.
I think he means the current locked down setup, where the entire firmware is locked. Or at least thats how i read it.
The poster specifically means bugs and holes in the locked down VM they’d be releasing. With an open router firmware, you can continue updating it to fix security problems or bugs as long as you like.
+1
Yup, all the ugliness of binary blobs. Firmware bug? Too bad. Remotely exploitable security bug? Too bad.
This should be a non-issue. Linux has a subsystem in place to comply with FCC regulations. It works great. But yes, it can be bypassed. You can also connect an antenna to a raspberry pi’s GPIO pin and bit bang out an FM signal that craps over a huge swath of spectrum. Or you can use an SDR to transmit pretty much anything you want. Or get a wifi card for your computer to transmit on any channel, or create a wifi hotspot with a rooted android phone and choose any channels you want.
At some point, though…
There are also going to be silicon bugs that can cause security issues, for example any ROM burned code or poor wifi decoding logic. Or even a badly designed crypto coprocessor. Or a badly designed crypto RNG. People don’t complain about it, probably because very few coders know anything about hardware level design, and almost no one ever releases hardware level design. So it’s just more security through obscurity, without the realization of that possibility…
I don’t know about the wifi decoding logic, I suppose you mean some acceleration logic in hardware, but for crypto rng/coprocessor the “fix” is easy, just don’t use those blocks.
With a closed blob that you can’t touch and which you depend on and can’t go around it’s game over if there are any security or functional bugs.
Yes, all code has bugs, including HDL code. And given the hardware/software split, there is always a portion of code you cannot correct. Binary blobs just shift that line in the “cannot correct direction”.
And yes, people do complain about it, perhaps you just aren’t in with the right people. If you have a faulty crypto RNG, the problem can be “fixed” by simply not using it and running it in software at reduced performance. If you start looking, you’ll start noting all sorts of places where silicon denial of service and security bugs are worked around by software. Being able to talk to the hardware directly makes it much easier to work around silicon bugs…which is yet another reason to not have a potentially non-fixable binary blob being the thing that is talking to your hardware.
It would be interesting if this could prevent bricking too. If one VM handles the management of the firmware images for the other VM.
you still need to update the firmware outside the VM, regulations change, and there will be bugs.
The bugs go without saying, ALL code has bugs.
People tend to forget that the equipment started off being low power simply due to the economics of manufacturing.
The suppliers that allowed software to adjust lower signal strength got better battery life, and others that needed more range were also happy.
The telecommunication companies are still butt hurt because 80% of people prefer Wifi over data plans use. So, they tried changing the software to discourage this feature, but people simply stopped buying the phones they couldn’t toggle over. Thus, the Telecoms decided on increasing FCC bandwidth purchases, and trying to push out the “free” wifi services from the bands they were already were using. Again, the strategy suggests a consumer will have to over-pay for LTE data services, as the limited service coverage of the “free” systems have been blocked in the hardware.
Most hardware is no longer made in America, and the rest of the world doesn’t care about people trying to game the market at the consumers expense.
The spice must flow…
The FCC did not introduce new rules, they proposed new rules that they later backed away from, stating publicly that they did not intend to prevent people from loading a different OS on the router (in spite of the fact that the proposed rules explicitly asked what the vendor was doing to prevent DD-WRT from being loaded on the device)
virtualization and locked down firmeware like this would be great for the vendors because it would let them block features that they didn’t want to have exist on cheap routers and charge more for the same hardware with a different label on it (for example, the number of stations allowed to connect, or the number of stations that it supports MU-MINO connections to)
This is not a good solution for the public.
This is really bad solution. I use openwrt, because I can trust it. In this case – I can not – no one knows what is in the hypervisor.
Also – remember playstation (linux on playstation? sure, but no longer). Locking features, firmware signing and other bad things are made possible too. (Bad when implemented to limit the user).
It does not fix any of the problems FCC created.
I don’t know why they just don’t use hardware selectors like days of old… jumper x for a region, y for b region, z for c region, have those limits built into the damn hardware… not everything has to be done in software.
Modern ISM band regulations are quite complex, certainly in places like Europe. Hardware only compliance is extremely difficult.
More software and virtualization is always the answer.
The hypervisor can run inside a virtual machine, running inside a virtual machine, running inside a virtual machine…
more indirection makes it run faster, and if everything is coded in java, the fastest language ever, it will be lightning fast!
never mind all this hardware crap. Just like the highly popular and successful win-modems, we can have software based radio, but written in java, just like software-defined radio was intended to be run!
I’ll use a PI and few wifi modules to build my own router, with blackjack and hookers….
Will you have a binary blob in the Pi?
Will you have a binary blob in the WiFi modules?
Will you actually have the capabilities, frequencies and power outputs that are actually relevant to the scope of these regulations?
And will you have an FCC-certified product ready for market?
In fact forget the Wifi and the blackjack.
So now we have a guaranteed attack vector via the VM code regardless of what the user installs over the top? I see what you did there NSA.
Huh, I’m glad I’ve been keeping my router and radio hardware seperate for the last few years. You can do whatever you want to my radios….but keep that half baked VM voodoo out of my router. No way I want that thing even close to the outside world in the chain. Does anyone remember “The wizard” on the ATT microcell?
It sounds like it’s not a bad solution. It’s a reasonable first attempt to have the best of both worlds.
We’re seeing more and more application of what are basically software-defined radio technologies in consumer products (such as WiFi routers).
The physical radio itself can generate a very large power output, with great flexibility in its modulation scheme and channel use, with great flexibility in what higher-level protocols are used, across a wide range of different frequencies. The radio is as agile and general-purpose as possible – and we “fix it in software” for all the higher-level stuff for a particular application.
You submit that hardware-plus-software stack to the FCC (or similar international agencies), with given hardware and given software, and that given combination is certified. If you change it, in the hardware or in the software, you’re no longer selling an FCC-certified product.
Software-defined radio means that software is now intrinsically a part of the technology stack that is regulated and approved by FCC. And people cry that this is taking away our SOFTWARE FREEDOM.
But the fact is, where radio is concerned, you don’t have freedom. It’s regulated. Some of that regulation is just moving from hardware systems – where “lack of freedom” has been well established for decades – into the software components.
What’s the alternative? To move away from software-defined radio technologies and the advantages that they bring.
This is unfortunate, especially for ham radio operators that have been using the WiFi routers to legally access the 5 GHz ham frequencies with inexpensive, off the shelf equipment. Much of this development has been focused on emergency response and services such as the Amateur Radio Emergency Data Network(AREDN.org). It appears that this solution will lock out amateur use and all it’s potential benefits.
The FCC facing cutbacks is downsizing its enforcement branch. It plans to prevent interference from routers by locking its radio firmware. This is magical thinking .and wrong in so many ways.
The root problem is a few cases of nuisance interference caused by a couple of WISPs interfering with airport Terminal Doppler Weather Radar. The offenders were using directional antennas in close proximity to the airports. The FAA is currently upgrading its NextGen RADAR signal processors – it really shouldn’t be that difficult to excise stray WiFi packets. The flip side is it’s a potential vulnerability to intentional attack. The world isn’t a safer place and the need for FCC enforcement hasn’t gone away.
” it really shouldn’t be that difficult to excise stray WiFi packets. The flip side is it’s a potential vulnerability to intentional attack. The world isn’t a safer place and the need for FCC enforcement hasn’t gone away.”
Are you saying, that FCC regulations prevent intentional attack?
The FAA has a vulnerability to a DOS attack on their TDWR. The FCC regs would do nothing to stop properly equipped attackers. The FCC still needs an enforcement branch to deal with cases like this. While the FAA is upgrading gear, it might as well address such vulnerabilities to get to the root problem.
Although a few complaint from TWDR operators were received and studied later by the FCC, the observation was that the WISP interference with existing carrier grade WiFi gear was a nuisance not a show stopper. The FCC rules are just another form of security theater. It pushes the cost of a “solution” that doesn’t fix the problem on the consumer.
“…this method of secure virtualization is the best way to give consumers what they deserve: an open source option for all their devices.”
WRONG HaD. If control of all or even a part of the hardware is jailed behind a manufacturer’s inpenetrable wall, you can NEVER be sure what you may be exposed to!
Yup.