Might have missed this being discussed, apologies if so! Has anyone been following the Radio Equipment Directive (AKA the Radio Lockdown Directive)? It is worrying:
we expect it to become impossible or very hard for users and companies to use alternative software on devices they bought – routers, mobile phones, WiFi-cards and the laptops they are built in, or almost all Internet-of-Things devices in the future.
In the past, users were expected to ensure that their modifications were compliant. The FSFE fears that the shift to making manufacturers responsible is likely to cause companies to lock down their devices, since it is not feasible for them to test every piece of software that could be run on their kit. Only code specifically authorised by the manufacturers will be permitted.
It seems to have been rumbling along since 2014 but just finished a feedback period in March and is going to public consultation Q4 2019, with commission adoption planned for 2020.
It’s sensible at one level, but only one. If people were making uncontrolled modifications to the baseband chip or baseband module then it could easily cease to conform to the over-the-air WiFi or Bluetooth protocol, causing chaos for other users. Those protocols are like the rules of the road. It would cause chaos if a reflashed car forgot which side of the road to drive on or abused the conventions or right of way to get you to your destination quicker.
But the firmware in baseband modules is invariably proprietary and not amenable to reflashing with open source variants in the manner of Cyanogen (for Androids) or OpenWRT (for routers). (The baseband module was the one component in the Fairphone that remained proprietary.) Nor is it generally useful to do so as the over-the-air protocol is a given and doesn’t generally allow for extra functionality that might be useful to a user. But on the other hand, being closed source and not easily examined by security researchers, baseband modules undoubtedly contain numerous vulnerabilities which are ripe for exploitation by any sufficiently sophisticated attacker. Such vulnerabilities are potentially extremely damaging. At worst, a worm that spread from device to device over the air is far from fanciful, and released in a busy transport hub it could spread nationwide in hours and worldwide in very few days.
However, restrictions on modifying the management code that drives the baseband module (such as Cyanogen or OpenWRT) would be a disaster on at least two counts. Users would be unable to extend the life of devices no longer supported by the manufacturer or to reflash with firmware more suited to their needs or with greater functionality. And it would only be the bad guys who don’t care about the law who would do so in order to reverse-engineer or reflash devices for nefarious purposes.
Thanks @philip , very useful explanation. I’m not 100% sure what a baseband processor does - is it mainly for calls? (e.g. the wikipedia page suggests it isnt generally used as a term in reference to WiFi or Bluetooth.)
Is it currently possible to alter a baseband module? As you mention it seems to be something outside of the control of even some device manufacturers such as Fairphone.
If it’s not currently possible, does it follow then that the only way the Radio Equipment Directive could be changing anything is by restricting the management code?
A baseband processor is basically the processor dealing with the signal before the aerial module.
The situation is different for each protocol. For mobile telephony, the network operators are very concerned that a rogue baseband module in a device (especially in popular one) could negatively affect their network. For WiFi, there are strict rules about interferences (not just the transmit power, but also in some of the 5 GHz bands to listen for any traffic before using these frequencies). For Bluetooth the risks are fewer but of course one needs to comply with the restrictions on the use of the 2.4 GHz band and implement the protocol correctly to be able to communicate with other devices.
So there are already many restrictions in place.
Now the code could be open but not modifiable, i.e., the two are not the same. Also the code could be not modifiable but still reflashable as a binary blob linked to by other software. So there are many variations. I haven’t had the time to read the documents you refer to, but get the impression that what is being regulated further are the other air interfaces than mobile telephony going the way mobile telephony is currently handled. That would make it harder or impossible to have completely new software such as openWRT and would also make it difficult or impossible for independent developers to write software interfacing with these baseband processor unless they provide a well documented and complete API. The current restrictions IMHO are a better balance.