Dismissal of reconsideration request comes with qualified endorsement of open-source systems.

Someone – let’s call him Bob – wants to secure a room. But in Bob’s universe, there are no locks. So Bob invents one, and installs it. And realizes he has a huge advantage over would-be intruders. Only Bob knows how the lock works. So no one else knows how to pick it. Bob sets about keeping his lock design a secret.

Alice also needs to secure a room, and she also invents a lock.  Unlike Bob, though, Alice publishes her design – not the set-up for a particular key, of course, but the details of the overall mechanism.

Bob thinks Alice is nuts. Why tell people how your lock works? They’ll just pick it more easily.

Fine, says Alice, good luck keeping your design a secret. It’s going to get out, no matter what you do. And frankly, Bob, your lock probably isn’t all that great. Okay, neither is mine. Not yet. But now that it’s published, people will suggest improvements. Students will do Ph.D. dissertations on making it better. Companies will compete to develop stronger versions. And long after your design has leaked, and instructions for picking it are all over the Internet, my vastly improved lock will be far more secure. Even though everybody will know how it works.

Alice, in short, supports open-source systems. Bob favors what open-source fans deride as “security through obscurity”.

Software-Defined Radio

For the last few years, the FCC has been playing a Bob-like role. Not about mechanical locks, of course, but over security precautions for software defined radios (SDRs). Those are radios that can change their FCC-regulated properties – frequency band, power, bandwidth, modulation, etc. – under software control.

All modern transmitters control these properties via software. But SDRs are deliberately built so their software – and the radio’s operating characteristics – can be changed as needed. A single SDR public safety radio could mimic at will any of the half-dozen different radios that clutter a typical ambulance. An SDR cell phone could be altered to transmit in a new frequency band, if the provider acquired one. The modification would not even require connecting the phone to a computer. The new software could simply be downloaded over the air. The subscriber need not even be aware of the change.

This capability raises important questions about security. Without adequate safeguards, a cyber-terrorist – or, just as bad, a bored teenager – could potentially distribute software that puts the cell phone on the GPS band, or aircraft landing control frequencies, Space Shuttle communications . . . the opportunities for havoc are endless.

The rules governing SDRs have always required that developers incorporate appropriate security features. “Manufacturers must take steps to ensure that only software that has been approved with a software defined radio can be loaded into such a radio.” Details were left to the manufacturer, subject to FCC approval.

But in a 2007 order, responding to a request from Cisco Systems, the FCC swung hard to Bob’s position:

[M]anufacturers should not intentionally make . . . security measures in a software defined radio public, if doing so would increase the risk that these security measures could be defeated . . . .

The FCC added: “A system that is wholly dependent on open source elements will have a high burden to demonstrate that it is sufficiently secure . . . .”

FCC Changes Course

That critique of open source elements is a slap in the face to the Alices of the world. One such group, the SDR Forum, asked the FCC to drop the last sentence quoted above, and to allow free publication of security mechanisms, so long as there is no intent to defeat the FCC rules.

Surprisingly, at least to us, the FCC dismissed the request on a technicality. The FCC, to its credit, much more often overlooks procedural irregularities, especially when (as here) a party in good faith raises an important question. Usually it reserves the technicality treatment for those few who make a hobby of pointless and repetitive filings. (Yes, people do that.) In this case, the SDR Forum asked the FCC to reconsider an earlier decision, but without having come forward while that earlier decision was pending. The rules allow the FCC to toss a reconsideration request that could have been raised sooner, and the FCC did so here.

But in its dismissal order, the FCC also provided a commentary to “clarify” its position. And there, the FCC largely backed away from its former, pro-Bob views.

We have nothing against open source software, the FCC said. Really. Publish all the software you want – just so long as you don’t disclose whatever the terrorist (or teenager) needs to modify SDRs. Yes, we did say that developers using open source have a “high burden” to demonstrate security. But so does everybody else. We hold all SDR manufacturers to that same high standard. Every application for FCC approval must demonstrate adequate security. But you open-source users can do that through keys or passwords, or any other mechanism you can persuade us is adequate.

Is that enough to satisfy the open-source fans? We don’t know. Go ask Alice.

Read the FCC dismissal – and commentary – here.