Complying with FCC rules on Wifi

Jump to: navigation, search

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 Regulation[edit]

The FCC in spring 2014 created a rule, Part 2.1033(b)(13), detailed at 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 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:
  1. Authenticated software is loaded and operating the device.
  2. 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:

Software Security Description
General Description
  1. Describe how any software/firmware update will be obtained, downloaded, and installed.
  2. Describe all the radio frequency parameters that are modified by any software/firmware without any hardware changes. Are these parameters in some way limited, such that, it will not exceed the authorized parameters?
  3. Are there any authentication protocols in place to ensure that the source of the software/firmware is legitimate? If so, describe in details; if not, explain how the software is secured from modification.
  4. Are there any verification protocols in place to ensure that the software/firmware is legitimate? If so, describe in details.
  5. Describe, if any, encryption methods used.
  6. For a device that can be configured as a master and client (with active or passive scanning), explain how the device ensures compliance for each mode? In particular if the device acts as master in some band of operation and client in another; how is compliance ensured in each band of operation?
Third Party Access Control
  1. How are unauthorized software/firmware changes prevented?
  2. Is it possible for third parties to load device drivers that could modify the RF parameters, country of operation or other parameters which impact device compliance? If so, describe procedures to ensure that only approved drivers are loaded.
  3. Explain if any third parties have the capability to operate a US sold device on any other regulatory domain, frequencies, or in any manner that is in violation of the certification.
  4. What prevents third parties from loading non-US versions of the software/firmware on the device?
  5. For modular devices, describe how authentication is achieved when used with different hosts.

If a device has a UI, the manufacturer must also answer a few more questions (III. Software Configuration Description Guide). The questions are:

Software Configuration Description
User Configuration Guide
  1. To whom is the UI accessible? (Professional installer, end user, other.)
    1. What parameters are viewable to the professional installer/end-user?
    2. What parameters are accessible or modifiable to the professional installer?
      1. Are the parameters in some way limited, so that the installers will not enter parameters that exceed those authorized?
      2. What controls exist that the user cannot operate the device outside its authorization in the U.S.?
    3. What configuration options are available to the end-user?
      1. Are the parameters in some way limited, so that the installers will not enter parameters that exceed those authorized?
      2. What controls exist that the user cannot operate the device outside its authorization in the U.S.?
    4. Is the country code factory set? Can it be changed in the UI?
      1. If so, what controls exist to ensure that the device can only operate within its authorization in the U.S.?
    5. What are the default parameters when the device is restarted?
  2. Can the radio be configured in bridge or mesh mode? If yes, an attestation may be required. Further information is available in KDB Publication 905462 D02.
  3. For a device that can be configured as a master and client (with active or passive scanning),if this is user configurable, describe what controls exist, within the UI, to ensure compliance for each mode. If the device acts as a master in some bands and client in others, how is this configured to ensure compliance?
  4. For a device that can be configured as different types of access points, such as point-to-point or point-to-multipoint, and use different types of antennas, describe what controls exist to ensure compliance with applicable limits and the proper antenna is used for each mode of operation. (See Section 15.407(a))


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[edit]

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.

List of possible methods of complying[edit]

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.

What's certification?

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.

Related Links[edit]