Slashdot Mirror


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.'"

20 of 365 comments (clear)

  1. Ain't the gov't great? by canUbeleiveIT · · Score: 5, Insightful

    Just goes to show how much a bunch of gov't bureaucrats know. Or maybe there just being ass-kissy with business again.

    1. Re:Ain't the gov't great? by eln · · Score: 5, Insightful

      They believe what the people who give them the most money want them to believe. Welcome to government.

    2. Re:Ain't the gov't great? by Harmonious+Botch · · Score: 5, Insightful

      They are more familar with the idea of secrecy and control than ideas like cooperation and standards.

  2. Amusing by ebbomega · · Score: 5, Insightful

    Because Security Through Obscurity totally worked for:

    MPAA (DeCSS)
    Nazis (Enigma)
    Xerox (Robin Hood & Friar Tuck)
    Microsoft (just about any form of security they've ever had)

    and about a billion other examples

    --
    Karma: Non-Heinous
    1. Re:Amusing by Penguinisto · · Score: 5, Interesting

      Yea, the MPAA and Microsoft are really hurting with their billions in the bank...

      ...meanwhile, their products are well-known for being about as secure as a fresh pot roast tossed on the floor of a wolf pit.

      Just because one can make a profit off of it doesn't make it any more secure.

      And you really cant compare enigma to current technology.

      I beg to differ - it was:

      1. a hardware-encoded algorithm set, eventually broken by other algorithms (courtesy of a few hardy Polish expatriate mathematicians), and
      2. actively decoded by one of the very first electronic computers in existence (see also "Colossus" and "Bletchley Park")

      Cripes, man... if Enigma/Colossus wasn't relevant in concept, then what is!?

      /P

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    2. Re:Amusing by Martin+Blank · · Score: 5, Insightful

      When the Germans kept Enigma a secret, they did nothing more or less common than anyone else was doing, or still does for the most part. National governments by and large do not leave their communications to AES, but instead use (what they at least perceive to be) more secure methods. NSA still keeps our codes secret, Russia's FSB keeps its codes secret, and the UK's GCHQ keeps its codes secret.

      One of the advantages to this is that the limited distribution of a given code can (but does not always) limit the number of attacks against it. Whereas a commercial cipher may result in millions or even billions of ciphertexts to analyze, a government cipher may result in only thousands to work with, and it may be more difficult to determine plaintext aspects of a given document for comparative analysis. It's also generally difficult to get the actual cryptographic hardware without paying someone (either from inside or outside) to steal one.

      This doesn't work well at all for the kinds of things that the FCC covers, however. I can generate billions of ciphertexts with known plaintexts for some new wireless system, and I can also do analysis against the electronics involved to look for side-channel attacks. Hiding things for commercial items intended for the general public is fairly pointless.

      Side note: I'd not heard of the Robin Hood & Friar Tuck trick. That was some very fun reading. Thanks for brightening my morning a bit. :)

      --
      You can never go home again... but I guess you can shop there.
  3. Well, they're technically correct, of course... by Space+cowboy · · Score: 5, Insightful


    If I'm trying to break into some code, and I can read the source code to determine how the author protected it, I'll have an easier job (note: "easier", not "easy") because I can home in on the algorithm the author used. I know whether it's Blowfish, DES, AES, IDEA, or a simple XOR or substitution cipher. I know what pre-encrpytion steps were taken, and what post-encryption algorithms were used.

    Let's say that in a moment of insanity, I decided to use a basic XOR encryption routine (create each byte in the encrypted stream by XOR-ing the corresponding source byte with every byte in the password save one, rotating that one as I iterate over the source). This is completely and utterly trivial to crack if you have the source code and *know* the routine I used. It's a repetitive cypher, so it's reasonably obvious unless the password is of significant (a sizeable fraction of the source's length) as well. Note the difference - it's easier with the source code.

    Now that's a contrived example - no-one in their right minds would use an XOR cypher, but the same principle applies to harder encryption techniques. If you *know* what system was used to protect the source, you have an advantage over not knowing... Did they gzip the source before encrypting it ? Did they use ZIP, RAR, or 'compress' instead ? Did they XOR to hide the obvious compression header ? Is it inverted (last byte first) or was any other transformation done *before* the encryption stage to try and make it non-obvious that a successful crack had taken place ? These are all "knowns" if you have the source code...

    So, yes, it is easier when you have the source code. Security through obscurity is rightly derided, but not because it has no value. It is derided because it leads to the use of insecure encryption methods (small keys, using XOR/whatever instead of proper hard encyption, etc) and the fact that once the obscurity is cleared up, there's no more security. The idea is that if you are sufficiently confident that your encryption is unbreakable, you *can* document how you did it in public. That doesn't mean you *should*.

    The point though, and why I disagree with the regulators, is that if you're using hard encryption, it really doesn't matter whether it's *easier*, it's not *easy*. It is in fact still so damn hard, that we're talking "impossible in our lifetime(*)" - the relative comparison makes no sense. It's akin to measuring the height of Mount Everest at 6-month intervals - it's always pretty darn high, though you might find some variance due to snowfall.

    So, yes, they're right. But by not considering the (tiny) impact of their conclusion, they have made the wrong ruling.

    (*) Modulo the discovery of an easy way to crack the encryption technology, of course.

    Simon.

    --
    Physicists get Hadrons!
    1. Re:Well, they're technically correct, of course... by kebes · · Score: 5, Insightful

      You're quite right. Obscurity does provide some level of security, though relying on it alone is a surefire way to have your security cracked eventually. (Whereas things that are cryptographically secure will not be cracked in my lifetime.)

      Another way to look at it (especially in the context of open source radio) is that whoever is implementing the security has finite resources (money, man-hours, whatever) at their disposal. For every hour they spend trying to obfuscate the inner workings, that is one less hour spent validating that it is *truly* secure (in the "cryptographically secure" sense). If you instead leverage open-source, then you have code that has been tested and vetted by experts the world over. Suddenly the hours spent on adding obfuscation would be a waste of resources: the code is already so secure that adding the slight additional security of obscurity is a waste of time.

      So, while obscurity does provide some kind of security... it is actually the most resource-wasteful form of security (alot of effort for something that eventually gets cracked), whereas the more efficient security model is to focus on things that are fundamentally secure (in which case you may as well use open-source solutions, since you get to take advantage of work already done, and the marginal loss of obscurity doesn't end up mattering).

    2. Re:Well, they're technically correct, of course... by Trillan · · Score: 5, Funny

      no-one in their right minds would use an XOR cypher

      /me shifts uncomfortably

      C'mon, it was the early 90s, I was new at this programming thing, and my boss told me to do it...

      At least I changed the constant away from 0x7F.

  4. SFLC has white paper on the subject by bkuhn · · Score: 5, Informative

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

  5. How can you vet ignorance? by gillbates · · Score: 5, Interesting

    How can you prove something is secure if you can't see the source code?

    You can't.

    The FCC's position is that it is better to hide one's head in the sand and hope the vendor implemented a secure solution than to actually *prove* the solution is secure.

    The FCC has always worried that the technology's flexible nature could allow hackers to gain access to inappropriate parts of the spectrum, such as that used for public safety. So the regulators required manufacturers to submit confidential descriptions showing that their products are safe from outside modifications that would run afoul of the government's rules. Cisco's petition asked the regulators to clarify how use of open-source security software, whose code is by definition public, fit into that confidentiality mandate.

    The problem is that, as any ham operator knows, access to any part of the spectrum is as simple as building your own homebrew equipment. Hackers, by their very nature, already know how to access the radio spectrum; it is the weak, or non-existent encryption which represents the real threat. Keeping your code closed allows security vulnerabilities to exist for much longer than they would if they could be scrutinized by the public at large.

    Furthermore, any software defined radio, open source or not, can be made "open source" by simply replacing the binary in flash. Which means that any software defined radio, open source or not, can be hacked. Which might be a bigger issue worth more discussion.

    --
    The society for a thought-free internet welcomes you.
  6. Why is the FCC regulating security? by pavon · · Score: 5, Insightful

    I am somewhat perplexed as to why the FCC would need to be regulating the security of consumer devices. For organization that need secure communications, there are already many government and private certifications, that insure this. But why on earth would they restrict consumers from purchasing non-secure software radios if they don't need them?

    Is this because they feel that software radios could be hacked to broadcast outside of their certified frequency and power limits? Or because they think they need to protect the public from buying 802.11 routers with crappy WAP implementations?

  7. Wavelength restrictions by romiz · · Score: 5, Informative

    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.

  8. FCC overstepping their bounds yet again by Anonymous Coward · · Score: 5, Insightful

    The FCC has absolutely no power to regulate nor any say at all in how software radio or television are implemented.

    The FCC commisioners are deluding themselves, again, if they think Congress gave them the power to appoint monopolies.

    They have already been slapped down once with regards to the DTV Redistribution Control flag and they're about to be slapped down again.

    What's next, washing machines and clock radios?

    http://pacer.cadc.uscourts.gov/docs/common/opinion s/200505/04-1037b.pdf

    If the Foolish Child Commission can't remember the limits of their power, We the People will be more than happy to remind them, spank them and send them to their 'time-out' corner once again.

  9. Re:Unless, of course, I'm an evil corporation by Space+cowboy · · Score: 5, Insightful

    Oh for [insert deity]'s sake, please don't tell them that... If they actually start thinking through every possible way someone could do harm on a plane, they'll shut down the airlines "for your safety and convenience"...

    At the end of the day, the most dangerous thing is an intelligent mind with the goal of doing harm. There is little-to-no way to protect against that, but it's not a politically acceptable truth, so they just make life difficult for everyone and hope for the best [sigh]. The *only* reason for all this is to protect *themselves* from a "you didn't do anything" accusation after the fact.

    If people would just accept that life == risk, we'd be a lot better off.

    Simon.

    --
    Physicists get Hadrons!
  10. Ceteris paribus by hey! · · Score: 5, Insightful

    "Ceteris paribus" -- assuming "allthings being equal", which they never are.

    True, if you have two equally boneheaded pieces of software, then exploits in a the closed one are harder to divine -- not by much, but harder. On the other hand, if you have a piece of software that has survived years of public scrutiny by experts, that is presumptively harder to exploit than something some random engineer ginned up in secret.

    Something cannot be widely reviewed (which is the gold standard in security) and secret at the same time. So generally, I think open source represents the best by far and the worst by a little of security possibilities.

    The ultimate problem is that broad statements like X is more secure than Y are meaningless. You have to specify the context and threat you are concerned with. Is an open source interpreter burned into a ROM inside of microwave oven more vulnerable than a proprietary interpreter? Well, against what? Same goes for the software radio thing.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  11. Go with the big guns... by tom_evil · · Score: 5, Informative

    ...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

    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, and a professional telecom corporate lobbyist.

    --
    i am the opposite of tom_good, i am the XOR of ]=9fÆ"ÝÕ and ÖÆ\KF, i am 746F6D5F6576696C00.
  12. Re:Where's the NTFS writer then? by gsking1 · · Score: 5, Informative

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

  13. Favorite Scary Kevin J. Martin Quote by mrcparker · · Score: 5, Interesting

    "You can always turn the television off and, of course, block the channels you don't want.... But why should you have to?"

    Kevin J. Martin
    FCC Chairman

  14. We are talking about REGULATORY security by m6ack · · Score: 5, Informative
    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."