EFF: U.S. Export Controls and “Published” Encryption Source Code Explained
Throughout our long history of defending encryption, EFF has taken a special interest in ensuring that researchers and programmers who help build and strengthen digital security are not prevented from sharing their knowledge. Because of this history, we periodically get requests about the status of U.S. export controls and how they affect open source software that uses encryption. It can be a daunting topic to research, and our friends at the Internet Systems Consortium (with help from the terrific export regulation attorney Roz Thomsen) just helped us to refresh our understanding. We thought it might be also useful for the community to have a refresher as well.
First, a disclaimer: as part of our Coders’ Rights Project, EFF frequently provides pro bono (free!) assistance to coders, hackers, and security researchers who face legal challenges as a result of their work. But this post isn’t intended as legal advice, so if you find yourself facing a legal threat, we encourage you to consider reaching out so that we can try to help.
Background: EFF Successfully Challenges Limitations on Exporting Encryption
EFF's landmark legal victory in Bernstein v. the United States greatly reduced the burdens and barriers to exporting open source encryption software, including export through publication on the Internet. Beginning in 1995, EFF represented Daniel J. Bernstein, a Berkeley mathematics Ph.D. student, who wished to publish an encryption algorithm he developed in the form of source code and a paper describing and explaining the algorithm, called Snuffle. Under the applicable laws at the time—the United States Munitions List of the International Traffic in Arms Regulations (ITAR), and later the U.S. Export Administration Regulations (EAR)—encryption was considered a military technology whose export was strictly regulated in order to preserve a competitive security advantage for the U.S. As a result, the law prohibited publication without prior approval of the government, and that prior approval was generally refused except for extremely weak encryption. Not only did these regulations chill the speech of individuals like Daniel Bernstein, they hampered American business by limiting the export of encryption technologies and methods. Then, as now, EFF saw clearly the importance of protecting speech online and the necessity of encryption to building a web with privacy and security protections.
In response to EFF’s constitutional challenge to these export restrictions, Judge Marilyn Hall Patel in the Northern District of California ruled that source code is speech protected by the First Amendment. On appeal, the Ninth Circuit Court affirmed Judge Patel's decision and found the government's regulations preventing publication unconstitutional. While the government appealed that ruling further, it also revised its regulations, greatly reducing the burden on publishing open source encryption software, along with lots of other encryption software.
Despite the legal victory in the Bernstein case, open source software with encryption remains subject to U.S. export control laws and regulations. Nevertheless, the lower burdens on export have opened the door for millions of people around the world to benefit from higher security. Although such software no longer is subject to the onerous restrictions under the ITAR or the EAR, however, some small requirements remain.
Email the Government: Export Controls on “Published” Encryption Source Code
Under Sections 734.7 and 742.15 of the EAR, “published” encryption source code is not subject to the EAR’s prior approval requirements. Such encryption source code is considered published, even if it is subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code.
However, to get to this “published” and uncontrolled state, the exporter must notify the U.S. Department of Commerce's Bureau of Industry and Security (BIS) and the ENC Encryption Request Coordinator at the National Security Agency with either:
- the URL or internet address where the encryption source code has been published, or
- a copy of the published encryption source code.
The notification or copy should be sent to crypt@bis.doc.gov and to enc@nsa.gov.
It should also be noted that updates to encryption source code may trigger a requirement to provide additional copies to both BIS and NSA. If you have provided a copy of the published source code, then you must notify the government again when the cryptographic functionality of the source code is updated or modified. If you have posted the source code on the Internet, then you don’t have to provide notice of changes to the encryption functionality, but you do have to notify BIS and the ENC Encryption Request Coordinator each time the Internet location is changed. For all of these notices, exporters should use the same email addresses: crypt@bis.doc.gov and to enc@nsa.gov.
After satisfaction of the notification requirements of the EAR, software falls out of EAR coverage and publishers may export or publish open-source encryption software.
If these requirements seem like empty bureaucratic formalism to you, we agree. There is even a good argument that the regulations are still unconstitutional. But we’re happy that the government has not tried to impose heavy export burdens to re-regulate encryption. We’d also point to a now nearly-two-decade-long track record of open source encryption publishers being free of harassment under the EAR.
The fight to keep encryption available to you is not over, however. The government continues to push for more direct restrictions on companies and we keep on fighting to protect your right to security and privacy through encryption. As the Ninth Circuit noted two decades ago in Bernstein:
Whether we are surveilled by our government, by criminals, or by our neighbors, it is fair to say that never has our ability to shield our affairs from prying eyes been at such a low ebb…. Government efforts to control encryption thus may well implicate not only the First Amendment … but also the constitutional rights of each of us as potential recipients of encryption’s bounty.
Comments
Post a Comment