Comments on proposed FCC rules regarding wireless devices

The Federal Communications Commission, or FCC is the government agency that regulates radio, television, satellite, and other forms of communication in the United States. Within its scope are regulating radio frequency (RF)-emitting devices to ensure one person's devices do not interfere with another's.

It is in this capacity that the FCC proposed new rules in August, rules that could have significant unintended consequences for end users and security researchers. In particular, the rules could put an end to highly popular aftermarket firmware such as OpenWRT and Tomato for wireless routers, and CyanogenMod for Android phones.

The comment period during which the FCC will accept public comment ends on September 8 has been extended to October 9. Please take a moment to submit your comments to the FCC here.

According to the proposal, the FCC last reviewed its equipment review and authorization process over 15 years ago, during which time the RF environment has grown dramatically (to wit, the explosion of the Internet of Things). It is sensible to review regulations periodically and to ensure the rules still make sense. For the most part, the proposed rules do make sense - but with a few significant caveats. 

Those caveats could lead to significant restrictions on what you as a citizen can do with your devices. While we are a minority of consumers, there are a great many individuals like myself that enjoy tinkering with technology, configuring devices to work together in novel ways, and customizing products to suit our tastes.

If you've ever seen a Christmas display where the lights are set to music, you've seen our tinkering at work.

Equally important, there are a smaller number of people that, like me, investigate products for security flaws. In many cases, we experiment with products that we have purchased and use personally. When we find something that could be abused by a malicious actor, we often come up with solutions and report our findings to the manufacturer. Our "hacking" leads to security fixes that benefit millions of consumers using the same devices.

A few examples from my own work follow. These are security issues fixed, and highly useful configuration tweaks, that could be impossible if the device software were locked down in accordance with the proposed rules.

• A configuration error on ASUS servers prevented all ASUS wireless routers worldwide from recognizing that a critical security update was available.
   
• CVE-2014-2719: Certain wireless routers disclosed the administrator password in such a way that the password could be stolen and used to access the device without authorization.
   
• CVE=2014-2718: Certain wireless routers did not properly verify that an automatically-downloaded update was genuine. An attacker could supply a malicious update, which the router would install, potentially granting the attacker complete control over the network.
   
• A networked device provided a way to share a storage drive with users of the network, but with very limited functionality. I wrote a script that greatly enhanced the functionality.
   
• CVE-2014-9584: Discovered by another researcher, this flaw allowed an attacker with access to the local network, to take full control of the network router.
   
• I demonstrated a project using a wireless router, and a Raspberry Pi running snort, to monitor network traffic and alert the owner to potential malicious or undesirable network behavior.

These are just a few examples of my own work; there are many others like myself, that have similar examples.

Below are what I consider to be the most important parts of the proposed rules.

13. Updating Certification Procedures
...manufacturers are increasingly designing transmitters that use software to set the operating parameters. Such RF-controlling software can allow adjustment of individual parameters or enable a device to operate in different modes, and the manufacturer may provide software upgrades in the field to enable new capabilities. We need to be assured that such devices only operate consistent with their certification. Also, software may be designed to only be modified by the grantee of certification or may be designed to permit third parties to enable new functions or frequency bands. Such trends are testing the limits of the Commission's existing certification rules, and formed the basis for the NPRM's proposals.

This is the foundation for the following sections. On the surface it sounds reasonable. The FCC is charged with regulating radio bands; to do so, they need assurance that a device will not behave differently in operation than when tested. A few paragraphs later though is the central problem (emphasis is mine).

18. Devices with Software-Based Capabilities
The SDR rules were intended to allow manufacturers to obtain approval for changes to the RF operating parameters of a radio resulting from software changes without the need to physically re-label a device with a new FCC ID number in the field. For a device to be certified as an SDR, in addition to demonstrating that the device complies with the applicable technical requirements, the applicant must also demonstrate that the device contains security features to prevent the loading of software that would allow the radio to operate in violation of the Commission's rules. The applicant generally has the option of whether to declare a device an SDR. Once the grantee of a device that is classified as an SDR makes any hardware modifications that require approval, the rules do not permit any subsequent software changes absent the filing of an application to obtain a new FCC ID.

In theory a manufacturer can "prevent the loading of software that would allow the radio to operate in violation of the Commission's rules" while still permitting an end user to install custom firmware. It is entirely possible to separate radio control firmware from device operating software. Using a WiFi router as an example, the software to route network packets, or to encrypt wireless transmissions, or to impose firewall protections, can be separated from the firmware that operates the actual radio transmissions.

In practice, few manufacturers have proven willing to separate the functions. It is far more likely that manufacturers will chose the easier route of locking down firmware to only the manufacturer's own programs, thus putting an end to the sort of novel inventions and security improvements I described earlier.

38-39. Modification of Certified Equipment by Third Parties
The Commission proposed to eliminate exceptions to the principle that certified devices could not be modified by third parties unless the third party receives its own certification. It proposed to revise § 2.909(d), which allows a new party that performs device modifications without the consent of the original grantee to become responsible for the compliance by labeling the device with a statement indicating it was modified, with the requirement that the party obtain a new grant of certification. It would have to specify a new FCC ID unless the consent of the original is obtained. The Commission asked whether the new procedure should also apply to parties that currently market devices with modified certification labels.

The Commission proposed, for certified device operating under all rule parts, to require that any party making changes without the authorization of the original grantee of certification must obtain a new grant of certification and a new FCC ID. This would codify a uniform application process for instances where parties other than the original grantee wish to make changes to certified devices, and would remove the current distinctions in § 2.1043(d) and (f) of the rules.

Does this mean an end user making software changes is obligated to seek certification himself or herself? What constitutes "modified" in the context of this rule?

74. Devices Imported for Personal UseThe Commission proposed to expand its exception on devices imported for personal use by modifying its existing personal use exception for up to three devices to encompass devices that use both licensed and unlicensed frequencies. It asked if there are targeted exceptions within the Commission's existing rules that should also be updated or removed. It asked whether the three-device limit is still appropriate, and if a different limit would provide adequate protection against harmful interference without unduly restricting individuals' personal use importation.

An exemption for personal use could potentially alleviate the earlier concerns, if broadened considerably. A technology-savvy household could easily include two or three wireless routers; four or more cell phones; multiple mobile computers and laptops; a wireless television; a wireless video player; one or more game consoles; and a wireless thermostat. It is not unreasonable that a household might include a wireless refrigerator, laundry appliances, door locks, and alarm system.

To be meaningful, an exemption for personal use would have to allow for dozens of devices.

Updated September 5: The FCC has extended the comment period to now close on October 9. Also, on September 5 the sometimes-irreverent UK website The Register published a quite detailed analysis of the pros, cons, and wtf's of the proposed rules.

Updated November 17: The FCC issued a statement to address the concerns of tinkerers and hackers. In the statement, the FCC makes it clear their intent is to not to lock down all device modification, but rather to specifically prevent only software modifications that would take a device out of radio frequency (RF) compliance. To wit, the FCC has released updated and narrower guidance.

This is a great example of regulators listening to the thoughtful commentary of stakeholders. With that said, it is in my mind a partial win, because manufacturers may still find it more cost effective and supportable to block all modifications than to separate functionality from radio emissions.

The Naked Security Blog explains in more detail; put simply, many SoHo routers are designed cheaply with a "system on a chip," in which it may not be practically possible to allow tinkering while also preventing modifications that affect radio emissions.

Update March 11, 2016: Network router maker TP-Link is the first example of the concerns I raised above coming true. While the FCC says it is not their intent to ban open source firmware such as OpenWRT, DD-WRT and Tomato, nonetheless the easiest way for a hardware maker to comply with the new rules it to block installation of any third-party firmware. ARS Technica reports that TP-Link has chosen to take that approach with any routers produced after June 2, 2016.