FCC Rules Open Source Code Is Less Secure

An anonymous reader writes "A new federal rule set to take effect Friday could mean that software radios built on 'open-source elements' may have trouble getting to market. Some US regulators have apparently come to the conclusion that, by nature, open source software is less secure than closed source. 'By effectively siding with what is known in cryptography circles as "security through obscurity," the controversial idea that keeping security methods secret makes them more impenetrable, the FCC has drawn an outcry from the software radio set and raised eyebrows among some security experts. "There is no reason why regulators should discourage open-source approaches that may in the end be more secure, cheaper, more interoperable, easier to standardize, and easier to certify," Bernard Eydt, chairman of the security committee for a global industry association called the SDR (software-defined radio) Forum, said in an e-mail interview this week.'"

SFLC has white paper on the subject

[bkuhn]

Over at the Software Freedom Law Center [softwarefreedom.org], we've published a white paper regarding the new rules [softwarefreedom.org]. That might be of interest to some.

Wavelength restrictions

[romiz]

The problem the FCC (and every other emission regulation body) has with open source and software radio is that it will be trivial to modify a device using these methods to emit at an arbitrarily high power level over a restricted wavelength, or using a band without using the proper medium access control. If this happened, the wavelength would be pretty much unusable for all other users until the FCC tracks down the emitter, and shuts him down.

That's why today, most radio-enabled devices, and especially mobile phones, have to pass type conformance to be commercialized in a geographic area. In the current state of things, if the radio software can be changed by the user, the type conformance cannot be awarded. Software radio makes things worse, because it is harder to justify that a component cannot emit at a given frequency, if changing the software in this component would allow switching emission frequencies at will.

Re:Wow... Governmental doublespeak

[gEvil (beta)]

It's not the same group making these statements. The FCC is the one who has said that "security through obscurity" works, while the SDR Forum (an industry group) cited SSL as a counterexample.

Re:Wow... Governmental doublespeak

[eln]

The SDR Forum is not affiliated with the FCC or the federal government, and in fact is opposed to this new FCC rule. The SDR Forum brought up those two methods as a counterpoint to the FCC's rationalization for this rule. I don't see any doublespeak there.

Re:Amusing

[Lockejaw]

Had the radio operators been a little more careful, it would've been a lot harder to break Enigma.

Yes, a lot of their communications were so formulaic that you could start the day with a known-plaintext attack, recover the key, and then use it to decrypt the rest of the day's communication.

The enemy knows the system

[vivaoporto]

Lookup Kerckhoffs' principle [wikipedia.org]. Security through obscurity is a widely debated subject going all back to the 19 century, when it concerns to cryptography, and sooner than that, in the locksmith circles, and it is more or less a consensus that it is not only ineffective but terribly dangerous, because "every secret create a potential failure point".

Read the wikipedia article, it is enlightening and very insightful.

Re:The FEDS

[HangingChad]

I'm sure he appointed people to the FCC who are every bit as competent as:

Brown

Chertoff

Wolfowitz

Rumsfeld

Harriot Myers

Alberto Gonzales

Scotter Libby

...it's a very long list. Should I keep going or did I make my point?

It's just another one of the Bush-buddy coat tails

[RingDev]

Standard Neo-con practice, appoint like-minded, highly loyal individuals into key points of power to make decisions that benefit big companies and personal investments in ways that congress can not easily effect.

Kevin J. Martin is the current head of the FCC, appointed by Bush in 2005. Prior to that, he was general council for Bush's first election campaign, then he took over the 'technical transition' when Bush/Chenny were moving into the white house. After they got settled he picked up a nice position as a white house assistant. The guy is nothing more than yet another Neo-con chronie who shows his loyalty to big business and the party line over the interests of the people and gets promoted for it.

On the bright side though, he is at least somewhat qualified for the job. He has a real degree from a real school, he worked at the FCC prior to being appointed to Chairman, and has focused much of his career in the tech/telecomm industries.

-Rick

Go with the big guns...

[tom_evil]

...like Bruce Schneier:

"If an algorithm is only secure if it remains secret, then it will only be secure until someone reverse-engineers and publishes the algorithms. A variety of secret digital cellular telephone algorithms have been "outed" and promptly broken, illustrating the futility of that argument."

from Crypto-Gram: September 15, 1999 [schneier.com]

But what could we expect from an FCC headed by a lawyer, a businessman, a professional Senate staffer, a DRM-supporter who received coaching from Clear Channel to oppose a satellite radio merger, [wikipedia.org] and a professional telecom corporate lobbyist.

Enigma was publicly documented to a degree ...

[AHumbleOpinion]

Enigma was publicly documented to a degree. It was based upon commercial devices from the 1920s, this greatly facilitated those who attacked it. The extensions / revisions made to the basic design were kept secret, however the weaknesses that led to its defeat were not these extensions or revisions but operator error. For example operators would send the same test message each morning, a violation of their training and procedures, and this greatly aided in the discovery of the day's configuration of the machine.

This example aside, your suggestion that "security through obscurity" is bad is wrong. See http://slashdot.org/comments.pl?sid=246437&cid=197 70229 [slashdot.org].

Re:How can you vet ignorance?

[dgatwood]

You're right that it will not be able to functionally replace the existing program, but if your plan is to replace the entire software in a device with your own software that tells it to plaster noise across a police band, for example, there's no longer any need to maintain functional compatibility with the upper levels of software in the device, and the lack of FCC certification for a device containing the open source software isn't of any real consequence.

The FCC's premise is fundamentally flawed. They see that the software can be changed in ways that would not pass certification and therefore won't certify the software. That's silly because the FCC doesn't certify the software to begin with. They certify the device which contains a particular version of the software. Thus, from their perspective, it doesn't make any difference whether that software is open source. If someone wants to muck with the software radio and make it do something malicious, the mere existence of the open source software is sufficient even if the open source software is not being used on the device as shipped.

The only reason the FCC could take issue with open source is that someone could then make changes to it and push it out of compliance and update their device with the software. However, someone could do the same thing by random poking in a closed source binary. The programming specs for the device are open, so snoop the values sent for power output, etc. as they are sent to the device, then scan the code for those values and change them. It's not significantly harder as long as the specs for the chipset are available, and don't get me started on how idiotic it would be to make those closed.... Further, the same could be done even with a hardware radio. Look at the schematics, figure out which resistor controls the gain, and thirty seconds later, you're transmitting at a higher wattage. One could actually argue that it is easier to modify such parameters in hardware devices because everything is very visually laid out in front of you. Heck, people have been sticking 30W linears on CB radios for years. There's no difference.

Re:Why is the FCC regulating security?

[db32]

It is exactly as you said. They don't want the populace spewing things into the RF spectrum that they can't manage. So one or two pirate radio stations spring up and are easily hunted down by the FCC. Now, with easy to "hack" software radios everyone could start broadcasting any information they want, in any format, on any frequency, at any power, etc...and there would be no way for the FCC to even begin to track that kind of rampant violation down.

If one guy is in the street protesting it is easy to control and quell. If its 10,000 guys in the street protesting it gets a little harder, if its 10,000,000 guys its basically imposisble.

Re:Amusing

[TheRaven64]

I don't believe they actually captured an Enigma device itself.

The Poles captured an Enigma machine and sent it to England when Poland fell, and GCHQ had a simpler version (same principle, fewer wheels) long before the war. One of the biggest factors in cracking the Enigma code was the fact that the German high command insisted that the settings for every wheel had to change every day. This dramatically reduced the search space. Once you'd cracked the code for one day, the number of possibilities for the next day were much smaller than if they had been completely random. I always remember this whenever I get a password rejected by a system because it must contain at least one uppercase letter and one number...

Uh...This is So Wrong...So Wrong...

[PatSand]

Interesting that they apparently didn't consult folks at NSA. Their operating hypotheses for any US cryptosystem are:

1. The equipment is known and available for disassembly and testing

2. The algorithm is known or discernable from the equipment and related manuals

3. You have lots of output data from the device (the underlying plain text is properly)

4. You don't have the key...that's what you need

While I will grant that most folks never see any of this (most equipment, algorithm details, and key parts of repair/use manuals are classified), they assume the worst case and still make it secure. In other words, like having open source code and figuring out the key from that and clean output.

While "Security through Restricted Access" is a very good practice, the argument is STUPID at best, and downright biased towards closed, proprietary software vendors. Frankly, these people couldn't encrypt their way out of a wet paper bag with a pen, ruler, and other sharp things like their pointy little heads.

If they think it is "less secure" we can lock them up somewhere with whatever they want to crack an open source cryptosystem used as the jail lock and see how soon they get out. I hope they include a lifetime supply of food, water, toiletries, medicines, etc. I think a simple 1024 bit Elliptical Curve Cryptographic system will keep them safely behind bars for several decades, if not their lives.

Where do they find these bozos to fill these positions? I'd like to know so we can close that source of universal stupidity off and make the world a better place...

I guess these folks will never qualify for one of my D.O. letter...they're either just too stupid or have such low IQs that they need to be institutionalized immediately.

Re:Where's the NTFS writer then?

[gsking1]

I get your point.. BUT. There is a very good NTFS writer for Linux http://www.ntfs-3g.org/ [ntfs-3g.org]

We are talking about REGULATORY security

[m6ack]

The FCC is not talking about security in a way that most of the people in this thread are talking about. They are talking about REGULATORY security. For instance, they want to make sure that a radio cannot produce so many dBm spectral emission outside of it's band when it is operating in it's intended band. They want to make sure that your Linksys doesn't output more than so many dBm so that it doesn't blast out the neighbor's network. That is what they are talking about -- and they see these as the real hurdles in qualifying SW defined radios. They would rather have regulatory control at the developer's level than having to resort to investigation and bringing individuals to court.

The issue is that this ruling benefits Cisco that wants to defeat the likes of Linksys, Netgear and others that are beginning to deliver "decent" solutions with cheap radios and the help of hobbyists leveraging open source software. If you require that some of the SW is closed, you cannot leverage the benefits of the open source module on that bit you have closed. You also have to end up spending more time organizationally to support the effort, because you have to maintain two sets of documents -- one for the closed section, and another for the open section. You have to support binary compatibility, or some mechanism for the open source to integrate with the closed source firmware... it just becomes that much more of a burden for Cisco's competitors to develop and maintain their solutions.

So, please, don't flood the FCC with emails telling them that "Open source /is/ secure" -- from the standpoint of regulation, it's not! Flood them instead with messages that say, "This ruling is entirely prejudicial against many companies leveraging Open Source software for their solutions."

Nice edit

[Comboman]

The "why should you have to?" is in reference to paying for channels that you have blocked or don't watch. I have to agree with him on that.

You learned exactly the wrong lesson from crypto

[GeekAlpha]

"I hate to say it, but, some evidence suggests that obfuscation works if there is enough of it. Cryoptography is ultimately about adding cost and time to an enemies retrieval of message to deter them from attempting to read it, or at least render it less valuable by the time they do, and obfuscation can do that."

Cryptography proves exactly the opposite of what you are saying. The algorithms used in crypto are open source so that the algorithm can be tested. The only thing that is obfuscated is the key, and even though everyone can look up the algorithm for AES or Blowfish or whatever, an attacker will have to waste cost and time to get the message protected by that one obfuscated key. If he wants the next message with a different key, he will have to start at square one. Open source software is open to code audit, the theory being that the obvious holes will be found and corrected because the code is there for all to see. Obfuscating the code makes writing inter operable code very difficult, but it does very little to prevent exploits. Much less comprehensive information is required to produce a software exploit than to produce a complex tool that is thoroughly compatible. Furthermore, unlike attacking a key, once a software exploit it created, it can be used again and again on many different victims until the software is fixed. For closed source software, there is no way for victims to protect themselves, nor can they force the vendor to update their software to protect them from exploit. The evidence you cite does not mean what you think it means. Obfuscate only what you must. A good security system requires only as few secrets as possible.

Re:Where's the NTFS writer then?

[ChrisMounce]

No one knows how to produce an authentic Word document to the last detail.

To the last detail, no, but 99% percent of the time, I can save something in Word and open it in OpenOffice.org, and vice versa. And as someone else here replied, lack of interoperability isn't security.

Re:Well, they're technically correct, of course...

[WNight]

If the 'key' isn't very random (RSS feed of Slashdot - guaranteed to contain the word "Micro$oft" twice a day...) then this isn't good security. Also problematic is the plaintext downloading (RSS) of the key material, and how anyone examining your weblogs could determine the source and simple read it themselves.

But, overall, the idea of XORing a random key as long as the source text works. You need a random key and to keep it secret and *never* reuse it. This is important, any reuse and simple known plaintext methods can often crack it in seconds.

Essentially a stream cypher can be thought of as a one-time-pad where a psuedo-random number generator (PRNG) which you seed with your key generates the pad material to the same length as the file.