The following text is copyright 2007 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.

The FCC ignores more than 100 years of clue

By: Scott Bradner

In 1883 French cryptographer Auguste Kerckhoffs published a set of 6 design principles for military encryption systems. (http://www.petitcolas.net/fabien/kerckhoffs/) The second of these principles is generally known today under the observation that security through obscurity is not security. The U.S. Federal Communications Commission (FCC) seems not to have read the history books or to be aware of how its sister federal agencies develop security standards.

In a common English translation, Kerckhoffs' second principle says that a secure crypto system "must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience." There are many reasons for this, ranging from the catastrophic results in the case of a breach that exposes a weakness to the reduced chance of a weakness if many eyes look at the system before it gets deployed. The latter reason is primarily why the U.S. Federal National Institute of Standards and Technology (NIST) conducts public open contests for new encryption standards. Security expert Bruce Schneier published a very good essay on this topic a few years back. (http://www.schneier.com/crypto-gram-0205.html)

The FCC has just decided that obscurity is better than security when it comes to software radios. (http://edocket.access.gpo.gov/2007/07-2684.htm) Specifically it said "manufacturers should not intentionally make the distinctive elements that implement that manufacturer's particular security measures in a software defined radio public" if that would help circumvent FCC rules. Since no manufacturer will want to prove that public disclosure will not cause such a risk they are being told to keep the code secret.

On one hand this is like saying that manufacturers should keep circuit diagrams of old radios secret so that someone would not know where to solder in a resistor to change the output strength. And on the other, it's pretending that hidden code will be somehow hack proof.

In the same decision the FCC made it clear that open source software is in the FCC doghouse: "A system that is wholly dependent on open source elements will have a high burden to demonstrate that it is sufficiently secure to warrant authorization as a software defined radio." This is a message that I am sure was well received in Redmond WA, but a message that demonstrated bias rather than analysis on the part of the FCC.

The Software Defined Radio (SDR) Forum politely responded that the FCC did not know what it was doing and asked it to get a clue. (http://www.sdrforum.org/uploads/pub_439156SDRF-07-A-0012-V0_0_0_Response_to_MOO.pdf)

With this decision the FCC reinforces my decade old suspicion that clues just do not like to hanging around Washington DC. (Postman - Read that Letter! http://www.sobco.com/nww/1995/04-postman.html)

It is not at all sure that the SDR Forum or anyone else can find clues that are willing to undertake the mission of breaking down the mental barriers protecting the FCC from the knowledge of the past or from the technologies and business models of the future but stranger things have happened. For example, the last time that the FCC tried to make rules about software the courts force fed them the clue that this was not the FCC's job. (Broadcast flag: Protecting the past http://www.networkworld.com/columnists/2005/051605bradner.html) It just might be a court will tell the FCC the obvious -- that the design of secure systems is not one of the FCC's missions (or competences).

disclaimer: "Harvard" and "clue" have been associated more often than "Harvard and clueless" but this exploration of clue locale is my own not one from the university.