June 20, 2019

June 20, 2019

Subscribe to Latest Legal News and Analysis

June 19, 2019

Subscribe to Latest Legal News and Analysis

June 18, 2019

Subscribe to Latest Legal News and Analysis

June 17, 2019

Subscribe to Latest Legal News and Analysis

Are You an Exporter? You Might Be: The Often Overlooked Controls on Software with Encryption Capacity

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

© 1998-2019 Wiggin and Dana LLP

TRENDING LEGAL ANALYSIS


About this Author

Daniel Goren Corporate litigation lawyer Wiggin Dana
Counsel

Dan Goren is Counsel in the International Trade Compliance Practice Group, where he works with a broad range of clients such as cutting-edge emerging technology companies, billion-dollar electronics manufacturers, and Fortune 50 aerospace and defense contractors. He advises them on compliance with U.S. export controls – the International Traffic in Arms Regulations (ITAR) and the Export Administration Regulations (EAR) – and U.S. trade sanctions regulations administered by the Office of Foreign Assets Control (OFAC).

Dan has conducted hundreds of internal...

203-498-4318
Tahlia Townsend International trade lawyer Wiggin Dana
Partner

Co-chair of the International Trade Compliance Practice Group, Tahlia is trusted by Fortune 50 multinationals, leading universities, international law firms, emerging companies, and small businesses to provide prompt, practical, effective guidance and thought leadership on trade sanctions administered by the Office of Foreign Assets Controls (OFAC) and on U.S. export controls under the International Traffic in Arms Regulations (ITAR) and the Export Administration Regulations (EAR), and to develop tailored, risk-based programs for compliance with, obtain licenses for international activities regulated under, and conduct directed and voluntary investigations into potential violations of these trade control regulations.

Lauded by her clients for responsiveness, practicality, and a level of care and service that is "terrifyingly good," and valued for the additional skills she brings to bear from her training in physics, chemistry, computer science, and litigation, Tahlia has assisted clients in sectors such as aerospace, banking, defense, insurance, logistics, venture capital, legal services, electronics, optics, communications, and education with a wide variety of trade compliance issues, large and small. A sample of those matters includes

  • Developed and drove implementation of a global program for OFAC compliance for a Fortune 200 company with operations all over the world.
  • Conducted hundreds of investigations into potential violations of U.S. trade sanctions and export controls and prepared scores of thorough and clearly written disclosures to the Office of Defense Trade Controls Compliance (DTCC), the Office of Export Enforcement (OEE), and OFAC, almost all of which were resolved without penalties.
  • Advised on the use of OFAC general licenses or prepared applications for specific licenses to authorize a wide range of exports and re-exports, including of oil-industry-related engineering services, medical devices, food additives, contact lenses, legal services, and activities conducted by U.S.-owned foreign companies under General License H.
  • Advised on and developed procedures for complying with General License H, OFAC's "facilitation" prohibition as applied to U.S. ex-patriot board members; legal representation of Specially Designated Nationals (SDNs); reinsurance of projects involving Cuba Restricted List entities; and payment of fees by foreign students from, hiring of foreign academics from, and attending conferences or collaborating on research with universities and academics in embargoed regions.
  • Prepared self-classification memoranda, Commodity Jurisdiction (CJ) requests, and Commodity Classification Automated Tracking System (CCATS) requests for a wide range of products, including infrared lenses, laser-driven light sources, data cables, unmanned aerial vehicles, aircraft components, metal alloys used in aerospace applications, and fabric used in the manufacture of aerostats, and prepared applications for ITAR Technical Assistance Agreements (TAA), Manufacturing License Agreements (MLA), ITAR temporary and permanent export licenses, and BIS export licenses for a wide range of products and programs.
+1 202 800 2473