Complying with FCC rules on Wifi
This page will compile all relevant information available on the FCC's new regulations on 5Ghz Wifi and the OpenWrt's community recommendations for hardware manufacturers.
The FCC in spring 2014 created a rule, Part 2.1033(b)(13), detailed at https://www.fcc.gov/document/5-ghz-u-nii-ro which reads as follows:
Applications for certification of U-NII devices in the 5.15-5.35 GHz and the 5.47-5.85 GHz bands must include a high level operational description of the security procedures that control the radio frequency operating parameters and ensure that unauthorized modifications cannot be made.
The final definition is at 15.407(i):
Device Security. All U-NII devices must contain security features to protect against modification of software by unauthorized parties.
(1) Manufacturers must implement security features in any digitally modulated devices capable of operating in any of the U-NII bands, so that third parties are not able to reprogram the device to operate outside the parameters for which the device was certified. The software must prevent the user from operating the transmitter with operating frequencies, output power, modulation types or other radio frequency parameters outside those that were approved for the device. Manufacturers may use means including, but not limited to the use of a private network that allows only authenticated users to download software, electronic signatures in software or coding in hardware that is decoded by software to verify that new software can be legally loaded into a device to meet these requirements and must describe the methods in their application for equipment authorization.
(2) Manufacturers must take steps to ensure that DFS functionality cannot be disabled by the operator of the U-NII device.
Additionally, these requirements were further described in publication 594280 at https://apps.fcc.gov/oetcf/kdb/forms/FTSSearchResultPage.cfm?id=39498&switch=P where the requirement for applicants for certification is described as follows:
An applicant must describe the overall security measures and systems that ensure that only:
- Authenticated software is loaded and operating the device.
- The device is not easily modified to operate with RF parameters outside of the authorization.
A set of questions must be answered by the manufacturer related to security as part of certification (II. Software Security Description Guide) The questions are as follows:
|Third Party Access Control||
If a device has a UI, the manufacturer must also answer a few more questions (III. Software Configuration Description Guide). The questions are:
|User Configuration Guide||
The requirement on 5Ghz Wifi is due to the fact that three channels, 120, 124 and 128, in the 5Ghz range are shared between unlicensed devices, such as wifi, and Terminal-area Doppler Weather Radar (TDWR). TWDR is used at 45 airports in the US as an additional safety measure beyond standard weather radar. In order to allow this sharing while still protecting airline passengers, the FCC required that devices operating on these frequencies use a technique called Dynamic Frequency Switching.
In Dynamic Frequency Switching, a device senses whether a weather radar is active on a frequency it wants to use. If the device senses a radar signal, it will change frequencies to prevent a conflict. Additionally, the device will check regularly whether frequencies which were once safe still are and vice-versa.
The FCC's primary concern with 5ghz devices seems to be that in the past some devices could be trivially modified in order to turn off DFS. By doing so, the device was no longer operating within it's legal authorization and even more importantly was behaving in a manner which could endanger aircraft landing.
Linux regulatory system overview
The Linux regulatory system for Wifi consists of three major components: the regulatory module, wireless drivers, and CRDA. Both the regulatory module and wireless drivers are part of the kernel. CRDA exists in userspace and therefore can only communicate with the regulatory module via IPC mechanisms. CRDA is optional and the regulatory system functions without CRDA included.
- Understanding the Linux WiFi regulatory system - a general overview of the regulatory system. Includes description of a regdomain and diagram of common workflows.
- Linux Wifi regulatory functions - a code level analysis of how regulatory information passes through the the regulatory system components.
List of possible methods of complying
The following workarounds have been suggested to allow companies to comply with the FCC rule. They're NOT recommended, just listed for now. Explanations will be added later.
- Secure Boot of the OS
- Authentication of Linux WiFi Driver
- Authentication of WiFi Firmware and Calibration Data
- Authentication of Peripheral Firmware
- Authentication of the Root File System
- Country Code Setting (set in hardware)
- Validation of User-Installed Code
- Isolation of User-Installed Code
- Protection of Execution Environments
- Hiding debug messages during boot
What does U-NII mean?
Unlicensed National Information Infrastructure. U-NII is a radio band in the 5Ghz range designated for unlicensed users with certified devices. A U-NII device is one that operates on the U-NII band.
Almost all intended or unintended radiators in the US must receive an FCC Certificate of Compliance. This certification verifies that the device complies with FCC spectrum allocations and rules. There are few exemptions to this rule, the most common one being that very few copies of the device are made (ten, I think).
Intentional, unintentional radiators, what's that?
A intended radiating device is any device that is deliberately designed to produce radio waves. This would cover any sort of radio transmitting device, such as a router, computer with a Wifi adapter, amateur radio device or TV transmitter. An unintentional radiator is one produces radio waves within itself which may be unintentionally radiated from the device. Examples of unintentional radiators are TVs, PCs without any form of wireless communications and electric motors.
I don't live in the US, why is this relevant to me?
As a large market, manufacturers can't afford to avoid the US market. Combined with the inherent costs of maintaining multiple hardware and software platforms means that manufacturers will have to minimize changes between regulatory regimes. This implies that any requirements necessary for the US market will radiate out into other markets. Additionally, it's possible other regulatory regimes will add similar requirements.
Does this requirement apply to OpenWrt itself?
No, not directly. The FCC regulates devices which produce radio waves. The software, by itself, does not produce radio wave therefore software, open source or not, is not regulated by the FCC. That said, the mechanism for controlling transmission characteristics in order to comply with regulatory requirements could be implemented in software, and in the case of Linux is implemented in software. This mechanism would be considered part of the device for regulatory purposes.
So if it doesn't apply to OpenWrt itself, why is this an issue to OpenWrt?
The growth and quality of OpenWrt, like most open source software, is dependent on the ability of the community to innovate. As part of this, users need to guarantee their modifications work as anticipated. If routers software is locked down completely, there's no way for an individual to install their modified software on their own, personally-purchased router. This lead to a situation where the community can't participate and neutralizes many of the benefits of manufacturers using open source software. This is to say nothing of the fact that users wouldn't be able to use their own devices as they see fit.