Blog post by James Vasile. Please email any comments on this entry to <vasile@softwarefreedom.org>.

Earlier this week, the Office of Foreign Assets Control announced the relaxation of rules prohibiting export of software to Iran and Sudan. The new exemptions build on a recent easing of some rules governing exporting telecommunications technology to Cuba. These moves are surely an attempt to capitalize on the Iranian election demonstrations last summer that some called the "Twitter Revolution". They are also a sign that the Obama Administration is carrying out its plans to make internet freedom a pillar of US diplomacy.

I hope the revised OFAC rules are the beginning of a broad and nuanced re-examination of US technology export policy. They are certainly good news for Free Software developers who are currently prohibited from distributing their software in embargoed countries.

Generally speaking, US companies have been prohibited from trading with Iran and Sudan, despite some exemptions for humanitarian and medical reasons. To my knowledge, those exemptions have never been applied to Free Software. Against that backdrop of general prohibition, OFAC promulgated new exceptions allowing the exportation of "certain services and software incident to the exchange of personal communications over the Internet." As examples, OFAC lists "instant messaging, chat and e-mail, social networking, sharing of photos and movies, web browsing and blogging."

That list, however, is not exhaustive. The exemption is broad and applies to a wide range of technology. I asked an OFAC representative how broadly to interpret "incident to," and he confirmed that the exemption includes such software as web servers, content management systems or operating systems on which one could run an IM client. If those are incident to personal communication, presumably much other Free Software is too.

Though the decision to loosen export regulations is a step in the right direction, it falls far short of what the Free Software world really needs: permission to publicly distribute Free Software everywhere on the planet without jumping through invisible and innumerable hoops. First, the new rules are limited to Iran and Sudan. Other embargoed countries are still off limits. Second, while "incident to personal communication" applies to a lot of software, it does not describe everything, and its limits are unclear. Third, the exception is limited to software that is publicly available at no cost to the user.

This last point deserves some extra attention. If you charge for Free Software, the exemption does not apply. Also, other export controls are still in effect. This is true no matter how you structure it. A download fee to recoup the cost of distribution would be a problem. A paid service agreement to support the software would be a problem. Accepting donations from embargoed countries could be problematic. In other words, if your project gives away software but raises money by accepting money for ancillary goods or services, those ancillary charges can run afoul of the embargo rules.

Other caveats exist (especially regarding software that does encryption), and this post isn't meant to be legal advice on how to comply. My objective is to shed light on a decision that could signal the beginning of a gradual shift in US technology policy and a shift in the Free Software development landscape. If your project is trying to comply with export regulation, you should seek legal advice.

Export regulation is a patchwork quilt of mystifying rules. Most projects are wholly unaware that putting their code on the web might put them at risk of violating export laws they've never heard of. Those that try to comply face many difficulties. It's heartening to see inter-agency cooperation aimed at simplifying the legal environment for Free Software developers. By broadening exemptions to include certain communication technologies, the government acknowledges that internet access is a fundamental human right. These are welcome signs for the SFLC and the free software community overall. I hope the Commerce Department joins in and extends the personal communication technology exemption to include trade with Cuba and Syria as well.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to <bkuhn@softwarefreedom.org>.

[Crossposted from Bradley M. Kuhn's personal blog].

Boy, do I hate it when a FLOSS project is given a hard time unfairly. I was this morning greeted with news from many places that OpenSSL, one of the most common FLOSS software libraries used for cryptography, was somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded a copy of the academic paper that was cited as the sole source for the story and read it. As I feared, OpenSSL was getting some bad press unfairly. One must really read this academic computer science article in the context it was written; most commenting about the paper probably did not.

First of all, I don't claim to be an expert on cryptography, and I think my knowledge level to opine on this subject remains limited to a little blog post like this and nothing more. Between college and graduate school, I worked as a system administrator focusing on network security. While a computer science graduate student, I did take two cryptography courses, two theory of computation courses, and one class on complexity theory⁰. So, when compared to the general population I probably am an expert, but compared to people who actually work in cryptography regularly, I'm clearly a novice. However, I suspect many who have hitherto opined about this academic article to declare this severe vulnerability have even less knowledge than I do on the subject.

This article, of course, wasn't written for novices like me, and certainly not for the general public nor the technology press. It was written by and for professional researchers who spend much time each week reading dozens of these academic papers, a task I haven't done since graduate school. Indeed, the paper is written in a style I know well; my “welcome to CS graduate school” seminar in 1997 covered the format well.

The first thing you have to note about such papers is that informed readers generally ignore the parts that a newbie is most likely focus on: the Abstract, Introduction and Conclusion sections. These sections are promotional materials; they are equivalent to a sales brochure selling you on how important and groundbreaking the research is. Some research is groundbreaking, of course, but most is an incremental step forward toward understanding some theoretical concept, or some report about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections that focus on the negative implications for OpenSSL. In the rest of the paper, OpenSSL is merely the software component of the experiment equipment. They likely could have used GNU TLS or any other implementation of RSA taken from a book on cryptography¹. But this fact is not even the primary reason that this article isn't really that big of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce. You have to cause very subtle faults in computation at specific times. As I understand it, they had to assemble a specialized hardware copy of a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the specially-constructed faulty hardware must be collected and operated upon by a parallel processing computing environment over the course of many hours. If it turns out all the needed data was gathered, the output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention. Very specific faults have to occur, and they can't occur such that any other parts of the computation (such as, say, the normal running of the operating system) are interrupted or corrupted. This is somewhat straightforward to get done in a lab environment, but accomplishing it in a production situation would be impractical and improbable. It would also usually require physical access to the hardware holding the private key. Such physical access would, of course, probably give you the private key anyway by simply copying it off the hard drive or out of RAM!

This is interesting research, and it does suggest some changes that might be useful. For example, if it doesn't slow a system down too much, the integrity of RSA signatures should be verified, on a closely controlled proxy unit with a separate CPU, before sending out to a wider audience. But even that would be a process only for the most paranoid. If faults are occurring on production hardware enough to generate the bad computations this cracking process relies on, likely something else will go wrong on the hardware too and it will be declared generally unusable for production before an interloper could gather enough data to crack the key. Thus, another useful change to make based on this finding is to disable and discard RSA keys that were in use on production hardware that went faulty.

Finally, I think this article does completely convince me that I would never want to run any RSA computations on a system where the CPU was emulated. Causing faults in an emulated CPU would only require changes to the emulation software, and could be done with careful precision to detect when an RSA-related computation was happening, and only give the faulty result on those occasions. I've never heard of anyone running production cryptography on an emulated CPU, since it would be too slow, and virtualization technologies like Xen, KVM, and QEMU all pass-through CPU instructions directly to hardware (for speed reasons) when the virtualized guest matches the hardware architecture of the host.

The point, however, is that proper description of the dangers of a “security vulnerability” requires more than a single bit field. Some security vulnerabilities are much worse than others. This one is substantially closer to the “oh, that's cute” end of the spectrum, not the “ZOMG, everyone's going to experience identity theft tomorrow” side.

⁰Many casual users don't realize that cryptography — the stuff that secures your networked data from unwanted viewers — isn't about math problems that are unsolvable. In fact, it's often based on math problems that are trivially solvable, but take a very long time to solve. This is why algorithmic complexity questions are central to the question of cryptographic security.

¹ I'm oversimplifying a bit here. A key factor in the paper appears to be the linear time algorithm used to compute cryptographic digital signatures, and the fact that the signatures aren't verified for integrity before being deployed. I suspect, though, that just about any RSA system is going to do this. (Although I do usually test the integrity of my GnuPG signatures before sending them out, I do this as a user by hand).

Blog post by Michael A. Spiegel. Please email any comments on this entry to <mspiegel@softwarefreedom.org>.

Public Safety is not a matter of Private Concern

In a recent article, Slate's Farhad Manjoo attempts to play down fears of faulty software in car braking systems as a potential cause of traffic accidents. Citing numerous studies which conclude that “the overwhelming reason we get in crashes is driver error,” Manjoo reasons that “the less driving people do, the fewer people will die on the roads.”

While it may certainly be true that most crashes occur because of intoxication, distraction, or driver fatigue, and that computer controlled cars may decrease driver error, Manjoo doesn't seem to see the obvious implication of his own assumptions -- “opaque” and “inherently buggy” software which could endanger public safety should be subject to review.

If Toyota truly wanted to repair its public image and reputation for quality, it would make its source code available to anyone interested, not just a single government regulator. The public is far more likely to discover bugs and suggest improvements than a relatively small number of overworked and potentially inexperienced government employees. As a former patent examiner at the US Patent and Trademark Office, I have seen the problems that arise when the amount of information and technical expertise available to the government is far outstripped by that of the private firms seeking government approval. Currently, the USPTO is attempting to deal with this imbalance of information by publishing patent applications before they are granted and by considering various proposals to incorporate public feedback as a means to improve patent quality. The National Highway Traffic Safety Administration should consider similar measures to allow the public to assist in its work.

Toyota should take their cue from another industry recently wracked by a loss of confidence in the integrity of their product -- the voting machine industry. Looking back on the controversies that surrounded voting irregularities in the past few elections, it seems like the public cares a great deal about the integrity of the voting process. A seemingly endless amount of ink was spilled by the press and blogosphere expressing outrage over the various security flaws found in Diebold voting machines, especially after the CEO of Diebold Inc. wrote that he is “committed to helping Ohio deliver its electoral votes to the president next year.” The media attention surrounding this issue culminated in the HBO documentary “Hacking Democracy”, in which filmmakers Simon Ardizzone & Russell Michaels chronicled the efforts of activists who exposed and attempted to fight the proliferation of insecure voting machines.

Finally, in response to the controversy, Sequoia Voting Systems announced last October that their new voting machines would be based on publicly available source code and open architectures, noting that “[s]ecurity through obfuscation and secrecy is not security” and that “[f]ully disclosed source code is the path to true transparency and confidence in the voting process for all involved.”

I find it curious how proprietary software became a major concern to the media as well as various state legislatures when our democratic process was threatened, but when at least 37 lives have been lost due to malfunctioning Toyota vehicles, there is no similar outcry for greater transparency in the proprietary braking and accelerating software that is crucial to keeping people safe on the road.

Given the cost of its 8.5 million car recall and the potentially irrecoverable damage to its brand, Toyota should seriously reconsider the value of maintaining a business based on trade secrets and realize that ensuring public safety should not be purely a matter of private concern.

Blog post by Lysandra Ohrstrom. Please email any comments on this entry to <Lohrstrom@softwarefreedom.org>.

New York Times reporters John Markoff and Ashlee Vance correctly pointed out that nations, private corporations, and even bands of rogue programmers are capable of covertly tunneling into information systems, by exploiting bugs in a program's source code in their January 20th story, "Fearing Hackers Who Leave no Trace."

Unfortunately, this paragraph appears more than half way through the story. Rather than address the real reasons that proprietary systems are so vulnerable to security breaches or the comparative protections afforded by free software, Vance and Markoff stuck to the usual formula of the Times' technology stories: the "intellectual property" parable. The good guys ("innovative," commercial technology companies like Google and Cisco) struggle to protect the integrity of their source code--their "crown jewels"--from the nefarious designs of the bad guys (hackers).

"If hackers could steal those key instructions and copy them, they could easily dull the company's competitive edge in the marketplace," Vance and Markoff write. "More insidiously, if attackers were able to make subtle, undetected changes to that code, they could essentially give themselves secret access to everything the company and its customers did with that software.”

The ability to make "subtle, undetected changes" to a system's source code is indeed the cause of frequent security breaches, but it is much harder for ill-intentioned hackers to "leave no trace" in free software. The solution is not to block access to source code, as the authors imply, but keep it open so that anyone can detect modifications, see who made them, and why. The reason closed, proprietary systems have proven to be less secure than free software alternatives over the years is more to do with the absence of a third-party audit function and accountability trail, than threats from "hackers."

I can only assume the confusing tangle of inaccuracies, contradictory conclusions, and false assumptions Markoff and Vance reported were fed to them by a PR agent or cobbled together after a day-long conference hosted by the Homeland Security Council. Vance quotes a member of the Council's advisory board, Jeff Moss, in the article he co-wrote with Markoff and in a separate story published under his own byline on January 21, "If your Password is 123456, Just Make It HackMe." Vance describes him as a security expert in the first story and the founder of a popular hackers conference in the second.

As a non-profit law firm for Free and Open Source Software programmers, the SFLC admittedly has a stake in promoting the projects developed by its clients. So rather than take my word for it, listen to the comments of readers like Wai Yip Tung from San Francisco. "This article have a very confused idea around source code and security," Tung writes in a comment. "Have you ever heard of Open Source software? (e.g. Firefox) Everyone has access to its source code but it does not make it any less secure. In fact security expert have an opposite opinion. It is critical that source code is available for audit by a wide range of people before we can have confidence of its security. This is a worthless article in my opinion. It stroke fear in the wrong places and shed little light on where the vulnerability really is.

I have to disagree that their effort was entirely worthless. Markoff and Vance inadvertently ended up writing an unqualified endorsement of free software in The New York Times.

Clarification: The "hackers" who break into computers with the intent to cause harm are distinct from from the community of programmers who create clever solutions to bugs in source code. A more accurate label for the activity in this story is malicious hacking or cracking.

Blog post by Lysandra Ohrstrom. Please email any comments on this entry to <Lohrstrom@softwarefreedom.org>.

The 2010 Consumer Electronics Show (CES) was the best of times and the worst of times for the free software movement.

It proved that the first stage of the revolution that the SFLC, and many others, have long predicted, is complete: free software has been embraced by commercial developers and is now powering a much wider range of embedded devices than any single proprietary program. Behind any one of the smartphones, eBook Readers, netbooks and LCD-televisions that debuted last week at CES is almost certainly a Free and Open Source Software (FOSS) application or platform.

But it also highlighted the extent to which proprietary software developers have taken advantage of the ability to adapt, improve, and customize free software in embedded devices that deny customers these very same freedoms. This is the paradox of free software's growing popularity: anyone can view, modify, and distribute source code, whatever their intentions.

Now that free software is inside almost everything, it is time for users to learn about their rights under free software licenses to protect their freedom to share, tinker, and adapt the devices they buy.

These values, ingrained into our consciousness in kindergarten, are the ones that drive free software innovation and that many of the commercial developers at CES have benefited from, yet hope their customers will forget.

Most of the eBook Readers at CES use free software in locked-down devices that restrict customers' access to certain publications, prevent them from sharing, and violate their privacy. Telecommunications companies have harnessed Android in the battle for a larger share of the smartphone market and collaborated on applications with FOSS programmers while preventing customers the right to chose between carriers. These companies have a vested interest in limiting the functionality of the devices they sell so consumers buy the next model in a couple of years, rather than improve the one they already own.

Individuals can reclaim the rights they take for granted in other commodities by educating themselves and choosing to buy the most free devices whenever possible.

While none of the smartphones or e-readers on the market is perfect, there are options that allow users to retain more choice and control of how a device functions and what content they can access. Choosing a Nokia N900 or a free Android phone over a carrier-subsidized, locked-down model gives customers the option of running any application and making modifications so it is more useful. Readers can chose an open-format e-reader over an alternative that only allows them to download books in proprietary format.

Owners of open-format e-readers can download public-domain content, such as "A Tale of Two Cities," for free from a variety of sources and be able to read and re-read it whenever they want, on multiple devices, forever. Amazon, on the other hand, charges Kindle-owners a license fee for the privilege of reading the free Dickens' classic on their e-readers. Amazon also reserves the right to revoke this license at any time and yank the free book from Kindle-customers who already paid to download it.

At CES 2011, the SFLC predicts that commercial software developers will continue to distract users from these basic rights with sleeker, smaller, and smarter devices that run on free software. The SFLC will continue to fight against people who violate the terms of the GPL by using FOSS in locked-down devices that restrict, rather than empower users. But the second stage of the revolution will be won by individuals who educate themselves about their rights in order to realize the full benefit of free software.