July 6, 2007

1 Executive Summary

The Software Freedom Law Center (SFLC) has examined the Federal Communication Commission’s (FCC) rules, which go into effect today, governing Software Defined Radio (SDR) devices and concluded that the rules do not restrict the activities of independent developers and distributors of Free and Open Source Software (FOSS) designed for use with SDR devices. While the FCC’s position on FOSS is more conservative than is necessary, the FCC has given a qualified endorsement to the use of FOSS by SDR manufacturers by recognizing the benefits of using FOSS in wireless products. The FCC’s SDR rules create an opportunity for wireless hardware manufacturers, the FOSS community, and the FCC to communicate openly and productively about the ability of public disclosure and open standards to strengthen the security and robustness of wireless devices.

2 Background

2.1 FCC SDR Rules

On March 11, 2005, the FCC released a set of rules outlining an alternative method for certification of devices whose radio frequency and power characteristics can be modified by software (such devices are designated Software Defined Radio devices).¹ The rules allow manufacturers who have certified under the new process to update the software on the devices without re-certifying the devices with the FCC.

The rules require any manufacturer certifying a device under the new process to take steps to prevent “unauthorized” changes to the software on the device that might alter its radio frequency and power parameters in a way that takes it out of compliance with the regulations known as FCC Part 15 regulations.² The specific technology implemented to accomplish this task is left to the manufacturers seeking certification, although the FCC suggests several possible mechanisms that can serve as such “security measures.”³

In response to a petition from Cisco Systems, Inc., the FCC issued a Memorandum Opinion and Order on April 25, 2007, making two clarifications to the rules.⁴ First, the FCC clarified the scope of the rules to require certification under the new process of any device that uses software to comply with the Part 15 regulations if such software is “designed or expected to be modified by a party other than the manufacturer.”⁵ Second, the FCC stated a position regarding the use of Free and Open Source Software (FOSS) on SDR devices. The FCC acknowledged the use of FOSS by device manufacturers and noted some of the advantages of FOSS for the industry. However, citing concerns regarding publishing information relating to security measures, the FCC stated that a SDR device which uses FOSS to build the “security measures” protecting the software against modification would face a “high burden” during the certification process “to demonstrate that it is sufficiently secure.”⁶

2.2 Linux-based Wireless Devices

The FCC notes in its Memorandum Opinion and Order that the industry now commonly uses both the kernel named Linux and complete FOSS operating systems in wireless radio devices under its regulatory control. For example, many 802.11 wireless network routers use FOSS to provide a fully functional system, including network address translation (NAT), network firewalling, intranet web servers, and other network management features. Such functionality, which if licensed as individual proprietary components can be prohibitively expensive, is readily available with any FOSS operating system. Many manufacturers have therefore chosen to configure their devices with these FOSS systems rather than proprietary alternatives. In such a configuration, almost none of the FOSS on the device interacts directly with the FCC-regulated radio hardware. Typically, only small pieces of code either running as a Linux kernel module and/or as a wholly independent firmware on the chip itself actually constitute an SDR component whose modification would need to be limited by the “security measures” described in the FCC’s rules. This white paper focuses primarily on these small components, but the reader should not lose sight of how much software on the standard FOSS-based FCC-regulated consumer devices remains far from the regulatory control of the FCC.

3 Legal Analysis

3.1 FCC Jurisdiction Does Not Extend to Independent Software Developers

The FCC is a statutory body with a grant of jurisdiction strictly defined by Congress.⁷ First, it has the power to regulate “interstate and foreign communication by wire or radio.”⁸ This primary jurisdictional grant gives it wide latitude to make and enforce rules for broadcasters and telecommunication carriers. Second, it has ancillary jurisdiction to make rules and regulations necessary for carrying out its primary responsibilities.⁹ This ancillary jurisdiction includes the power to make “reasonable regulations ... governing the interference potential of devices which in their operation are capable of emitting radio frequency energy.”¹⁰ It is much more narrowly constrained than the FCC’s primary jurisdiction over broadcasters and carriers, because courts, fearful that the FCC’s powers would become “unbounded” if it were allowed to make rules governing any activity or party that might have an effect on radio or wire transmissions, have precluded such a reading of the FCC’s jurisdictional grant.¹¹ Thus, while the FCC’s ancillary jurisdiction reasonably extends to regulating the marketing and sale of devices that create active radio interference, it does not extend to such activities as the construction of buildings that might interfere with radio signals.¹²

Similarly, the FCC’s ancillary jurisdiction cannot reasonably extend to the development of software by parties uninvolved in the marketing or sale of radio devices. Congress did not contemplate the FCC as a generic technology regulatory agency, and courts have repeatedly limited the FCC’s reach when it attempted to make rules outside of the realm of the distribution or marketing of equipment capable of wire or radio signal transmission.¹³ Attempts by the FCC to regulate the activities of software developers not engaged in the importation or marketing of radio devices and not employed by telecommunication carriers are likely to be met with similar judicial restriction.

3.2 FCC Rules for SDR Device Certification Only Affect Radio Equipment Manufacturers

Even if the FCC did have the power to regulate independent software development, it has promulgated no rules governing such activity. Its new rules related to SDR are addressed to “manufacturers” of radio “equipment,” modifying the rules for certification of such “hardware-based device[s]” prior to their “marketing or importation.”¹⁴ No other parties or activities are affected by the regulations. Thus, unless a given entity engages in the marketing or importation of hardware-based radio equipment, it is unaffected by these regulations.

3.3 FCC Rules Govern Equipment, Not Software

The FCC has promulgated the SDR rules as a modification to its existing regulations governing the certification for marketing and sale of devices that may interfere with radio transmissions.¹⁵ These rules limit the ability to “manufacture, import, sell, offer for sale, or ship devices or home electronic equipment and systems, or use devices, which fail to comply with regulations promulgated pursuant to this section.”¹⁶

Since software is a representation of a mathematical algorithm, it is not a “device”, “home electronic equipment” or a “home electronic ... system.”¹⁷ Further, there is no precedent for applying the device certification rules to software except as installed as a component of a specific hardware device. Indeed, the FCC has explicitly limited the certification requirements to “hardware-based device[s].”¹⁸ Both of these facts make it clear that the FCC rules do not apply to software by itself, but only to hardware-based devices.

3.4 FCC Rules Contemplate FOSS SDR Development without Restricting It

The FCC’s Memorandum Opinion and Order clarifying its SDR certification rules acknowledges the use of “open source software” by SDR device manufacturers and notes the advantages FOSS provides to the industry. It declines to forbid or restrict the use of FOSS on SDR devices. However, it discourages use of FOSS in the “hardware and software security elements” of SDR devices by stating that systems “wholly dependent on open source elements” would have a “high burden” to demonstrate their security during the certification process.¹⁹

Nowhere do the rules restrict any party other than a manufacturer seeking certification for a device. Even in that case, they do not restrict the manufacturer’s activities directly, but simply warn that the certification will be less likely to be granted if the manufacturer relies “wholly” on FOSS in building the device. The rules acknowledge the activities of the FOSS community in developing radio device software and, in keeping with the FCC’s jurisdictional limitations, decline to formulate rules governing any participant in this activity except manufacturers seeking certification for their devices.

This reluctance on the part of the FCC to create regulations for technological development — beyond regulating the actual marketing of devices — is consistent with the FCC’s position on experimental or specialized equipment. Such equipment is exempt from the certification requirements if it is not marketed to the public and is only used under controlled conditions.²⁰ It is allowed to be developed and distributed as long as it is used for such limited purposes. Thus, even entities who install and run software — FOSS or otherwise — on radio hardware devices for the purposes of testing, research or development are exempt from the new SDR certification rules as long as they abide by the other applicable FCC rules.

4 Policy Analysis

The FCC’s rules on SDR device certification present two positive developments for FOSS deployment in the wireless technology space. First, the FCC permits the use of FOSS in all but a very narrowly constrained subsystem on a specific type of device. Second, the FCC has provided much greater regulatory clarity than has existed on this issue since the commencement of the SDR rulemaking process in 2003. This freedom to deploy FOSS and the clarity of the FCC’s position allows hardware manufacturers and FOSS developers to openly collaborate on most parts of SDR device design, and it frees software developers from concerns that they might have to deal with legal issues related to the FCC.

Unfortunately, the FCC has not gone as far as it could in embracing and encouraging the use of FOSS by SDR device manufacturers. Its rules express reservations about the security of FOSS-based systems based on the notion that “making information on security measures publicly available could assist parties in determining ways to defeat them.”²¹ However, there is broad consensus among software security experts that public disclosure of security design actually results in more secure systems, especially when the system is subject to repeated, low-cost attacks by attackers who can share information freely among themselves.²² SDR devices used by consumers fit this description: the software on a cellphone or 802.11 card is exposed to virtually unlimited attack by anyone who purchases the device, and anything learned from such an attack can be communicated at low cost to fellow attackers. Design details disclosed by manufacturers, on the other hand, have tremendous benefits for other manufacturers’ ability to spot security flaws, but they provide little benefit to attackers. These arguments are articulated in greater depth in a Petition for Reconsideration submitted to the FCC in June 2007 by the SDR Forum, a wireless industry consortium with a vested interest in the SDR rulemaking process.²³

On a positive note, the FCC does signal in its Memorandum Opinion and Order that it is open to persuasion on the subject of FOSS-based security systems. It states that “manufacturers should not intentionally make the distinctive elements that implement that manufacturer’s particular security measures in a software defined radio public, if doing so would increase the risk that these security measures could be defeated or otherwise circumvented to allow operation of the radio in a manner that violates the FCC’s rules.”²⁴ This qualification suggests that the FCC is not committed to this proposition, as does the doubly qualified message that only devices “wholly” (not mostly, or partly) based on FOSS would face a “high” (not insurmountable) burden during certification. The FCC’s refusal to categorically prohibit FOSS in any part of an SDR system reads as an invitation to the wireless device industry and the FOSS community to demonstrate the suitability of FOSS for the design of all software subsystems of SDR devices.

5 Conclusion

The SDR rules promulgated by the FCC represent a positive development for FOSS developers working in the wireless space. The rules allow FOSS developers not affiliated with device manufacturers to continue work on their software without restriction. They allow SDR manufacturers to employ FOSS for most of the functionality of their devices, and they leave open the possibility that a device using a purely FOSS-based software platform could also pass FCC certification if it managed to demonstrate the soundness of its security strategy. The rules should spur FOSS developers and hardware manufacturers to collaborate on design strategies that maximize the efficiency, robustness, and freedom inherent in the FOSS development process while ensuring that manufacturers satisfy the FCC’s security mandate.

Copyright ©2007, Software Freedom Law Center, Inc. Verbatim copying of this document is permitted in any medium, provided this notice is preserved.