The Often Overlooked Controls on Software with Encryption Capacity
Daniel Goren Tahlia Townsend The National Law Review
In a world of electronic connectivity, software with encryption capacity surrounds us. It is inside your home, masking the signal between your WiFi and your computer. It is in your car, concealing the data passed through a Bluetooth connection to the car’s audio system. It is in your office, guarding the files stored in its file management system. It is in your web-browser, protecting financial transactions with your bank. And of course, it is in your pocket, in virtually every app on your phone.
Given the common use of encryption in software today, and an increasingly global market for software products, it is important for companies, particularly emerging ones, to recognize that software with cryptographic functionality is controlled by U.S. export law. The consequences of not recognizing the export compliance obligations associated with encryption products could be costly, and not only because regulators might catch a company breaking the law (and have the power to impose penalties even for unintentional violations). Start-ups being acquired by larger companies may have to disclose non-compliance with export law in the due diligence process leading up to purchase, forcing money into holdback escrows to serve as security for the buyer, which will inherit liability for any violations and understandably look to shunt any successor liability and compliance expenses to the seller in the deal. Luckily, avoiding this outcome is relatively easy, if a company making or selling software expends minimal effort to: (1) know if their product is of the type that concerns the U.S. government; and (2) satisfy their export compliance obligations, which may amount to little more than submitting an annual “self-classification” report to the government by email.
I. The U.S. government controls the export of encryption software
Exports from the United States, including software exports, are subject to the regulatory jurisdiction of either the U.S. Department of State (“DoS”) or the Department of Commerce (“DoC”). And while high-end military or intelligence cryptography is controlled by the DoS, most encryption software is regulated by the DoC. So why does the government worry about encryption software? Not because of any informational value inherent in the encryption software itself, since the mathematical underpinnings of encryption and how to execute it in software code are broadly understood. The government cares about encryption software’s functional capacity—the capacity to conceal information. Uncle Sam wants to know the strength of that capacity and who has it.
The DoC controls software that is “designed or modified to use ‘cryptography for data confidentiality'”. This means that even if software does not have its own encryption source code, it still may be controlled under U.S. export law. If a company’s software calls for encryption functionality from an external source, such as an operating system or a web browser, it is subject to control. Similarly, if a company incorporates “publicly available” or “open source” encryption source code into its software, it must assess its software product based on the capacity that code brings with it.
These rules may be familiar to any company that has tried to win Apple App Store approval for an app, since Apple requires its developers to answer encryption-related export questions before it approves an app for sale on its store. As Apple explains to its customers, an app that “uses, accesses, contains, implements, or incorporates” encryption is controlled for export.
Put simply, if a company’s software has any encryption functionality, it must consider U.S. export law.
II. But not all encryption software is controlled.
Luckily, the government limits its control of encryption software to the type it considers most worrisome: “cryptography for data confidentiality.” This is a defined term, and it excludes many common types of encryption functionality from control. In particular, the following types of encryption capability are notsubject to control:
Authentication encryption. This is encryption for verifying the identity of a user, process or device, often as a prerequisite to allowing access to resources in an information system. This includes verifying the origin or content of a message or other information, and all aspects of access control where there is no encryption of files or text except as directly related to the protection of passwords, Personal Identification Numbers, or similar data to prevent unauthorized access.
Encryption for “digital signature,” “data integrity,” and “non-repudiation.” This type of encryption provides the means of proving the integrity and origin of data, but does not encrypt the data itself.
Encryption for “Digital Rights Management.” This kind of encryption protects copyright by verifying that someone has a right to download, view, or use content.
Encryption or decryption in support of entertainment, mass commercial broadcast and medical records management. The regulations do not define these terms, but the DoC does offer examples on its website of what is included, such as encryption of patient scheduling information or confidential medical records.
In short, the government controls encryption capability that permits encryption of data, but does not control encryption used only to verify user identity, confirm the origin or integrity of data, or protect that which is already protected for other legal reasons, like copyrighted material or confidential medical records.
III. Often, even when controls apply, compliance simply means satisfying an annual reporting requirement.
If a company’s software is controlled by U.S. export law, it will require government authorization to export it. For many companies, that is not as bad as it sounds, because a lot of encryption software is authorized for export under an exception — License Exception “ENC,” or qualifies as “mass market” software. Companies that satisfy the conditions for using ENC or as “mass market” software do not need to apply for licenses to export the affected software to most destinations worldwide. In addition to complying with the conditions set out in ENC, companies will need to satisfy certain record keeping obligations required by the law and should screen customers against the lists of people and entities prohibited under U.S. sanctions law. The conditions for use of ENC vary with the nature of the software: for the most highly-controlled products companies must submit an encryption “classification” request, to obtain official DoC agreement about the level of control, and must wait 30 days before performing any exports under the authority of ENC, to give DoC the opportunity to disagree with the assessment and impose more stringent controls. For some products, such as cryptoanalytic software, companies must also submit, via email, a semi-annual sales report. However, for a majority of encryption software products, neither of those two filings are required. Instead, companies need only submit, via email, a simple Annual Self-Classification Report at the end of each year. This report contains basic information about the company and product, the authorization being used (in this scenario, “ENC”), and a description of the item or reason for control, such as “file encryption.” The report is then filed by email, using the file format required by the government.
With just a little effort up front, start-up companies making or selling software with encryption capacity can avoid the potentially disastrous pitfalls of inadvertent failure to comply with U.S. export law. In the end, most encryption exporters just have to file a single, simple report at the end of each year. Doing so could save a company a lot of time and money.
This article is part of a series called, “Legal Issues for High-Growth Technology Companies.”