Archive for the ‘Encryption’ Category

Statement Before House Committees Concerning Proposed Export Licensing for Cyber-Security Items


(Source: Homeland Security Committee) Author: Kevin J. Wolf, Assistant Secretary of Commerce for Export Administration.

Transcript of statement:

“Thank you, Chairmen Hurd and Ratcliffe, and Ranking Members Kelly and Richmond.

The Wassenaar Arrangement is a 41-member export control group in which the United States participates. It was established to contribute to regional and international security and stability by promoting greater responsibility in the transfer of conventional arms and dual-use goods and technologies, thus preventing destabilizing accumulations of such items. Participating States maintain a common control list of items warranting control for these reasons and seek, through their national policies, to ensure that transfers of these items do not contribute to the development or enhancement of military capabilities that undermine these goals, and are not diverted to support such capabilities. The list of such items is developed and updated by the Participating States through consensus determinations, generally made at the end of each year. …

In December 2013, Wassenaar approved new export controls on “command and delivery platforms” for “intrusion software” and related technology. Specifically, the entries in Category 4 (Computers) of the Wassenaar dual-use control list would control non-publicly available software (4.D.4.) that generates, operates, delivers, or communicates with “intrusion software.” “Intrusion software” is defined as software designed to covertly gain access to a computer or other networked device and, once inside, to extract or modify data or modify the execution path of the device to allow the execution of externally provided instructions. Related hardware and technology entries (4.A.5. and 4.E.1.c.) control systems and equipment for generating, operating, delivering, or communication with “intrusion software,” and technology for developing “intrusion software.” The original proposal for these controls came from another Wassenaar member nation in 2012. Examples of the types of commercial hacking software intended to be captured by this control include those offered by Hacking Team (Italy), Gamma/Fin-Fisher (Germany), and Vupen (France).

The controls were novel in that they were the first foray by a multilateral export control community into the area of offensive cyber tools. The agreed-upon entries covering software intentionally excluded “intrusion software” itself — that is, certain kinds of malware — from control because of a general understanding that everyone with a computer or mobile device infected by such malware or “exploits” could become an unwitting “exporter” of it (e.g., by forwarding an infected e-mail to someone in another country). The technology entry, however, imposes controls on non-publicly available technology for the development of such software as well as on technology for the development of the controlled delivery systems. …

In order to not take an action that would inadvertently harm our nation’s ability to engage in critical cyber defense and related research work, we decided in May 2015 to take the unprecedented step of publishing these Wassenaar control list entries as a proposed rule, with a request for private sector comments, rather than as a final rule. Our hope was that the private sector comments would give us a better sense for whether the rule would have unintended impacts on our cyber defense and cyber research ecosystems. All dual-use controls have consequences and impose costs on the private sector. That is the nature of controls. This one, however, was different because the impact would be not just on the economic bottom-line of U.S. companies, but on our government’s and our nation’s ability to share efficiently and quickly the types of technology necessary to conduct cyber defense and related research.

Immediately following publication of the proposed rule, Commerce received questions from U.S. private sector and others in the U.S. Government about the intended scope of the controls. In order to ensure that comments were informed and responsive to the proposed controls set forth in the rule, Commerce published answers to a list of “frequently asked questions” on its website to address what we determined were regular queries in order to encourage more focused and more useful public comments. It was clear from these initial questions that the terminology used in the control list entries and the proposed rule were understood differently by the cybersecurity community than by the export control agencies and the Wassenaar Participating States. By the end of the 60-day comment period, Commerce had received more than 260 comments, virtually all of them negative. Some commenters took the view that the underlying control at Wassenaar could not be implemented without causing significant harms to cybersecurity. Others made specific recommendations on ways to mitigate many of the concerns. Some praised the underlying objectives of the rule, while nonetheless proposing modifications to the scope of the proposed regulation, such as through license exceptions and definitions, to reduce the impact of unintended consequences. …

Neither the Commerce Department nor the Administration has reached a conclusion about how to respond to the public comments. We are still reviewing and considering them. Importantly, all U.S. Government agencies with expertise and equities in cyber defense research and related work are reviewing the comments and will provide input as a next step, before we make a decision on what to do about the proposed rule.   As requested by your committees, I can, however, summarize the essence of the comments – reiterating that the Administration has not come to any final conclusions regarding how to respond to the comments or to the extent to which they are correct technically. The public comments, including presentations at technical advisory committee meetings during the past three months, focus on three main issues.

First, some commenters asserted that the proposed regulation’s definition of “intrusion software” is too broad and, as a technical matter, fails. They assert that malware recovery tools would be caught by the entries because they interact with malware to regain control of an infected system, and some defense research tools would be caught because they analyze malware to develop new defensive products. They also assert that products that patch systems or add capabilities to programs would themselves be controlled under these entries because of the way they interact with or manipulate programs. These products are integrated with the hardware (systems, equipment, and components) and are designed to legitimately bypass or defeat protections, modify the standard execution path of software, and access data. According to the commenters, they would often thus be software for the generation, operation, delivery of or communication with “intrusion software” and caught by the new controls.

Second, other commenters contend that the proposed rule to implement the control list entries as written, based on the definition of “intrusion software,” would impose a heavy and unnecessary licensing burden on legitimate transactions that contribute to cyber security. Government agencies and private sector cyber security companies routinely test their systems and networks to identify vulnerabilities and, if possible, discover existing malicious attack agents. These companies then provide their clients with threat mitigation tools and strategies. To accomplish this, they use the same tools the controls on intrusion items identify, though their use is authorized by their target. To accomplish their mission, they need to employ tools for computers or networks that have the functional specifications of the control parameters, e.g., avoid detection, defeat protective countermeasures, extract data or information, modify system or user data, and modify the standard execution part of a program or process to execute externally provided instructions. These are exactly the characteristics a successful malicious attacker’s software would have and what the assessment team’s tools need to be able to replicate. During these defensive engagements, members of the assessment team frequently need to create custom scripts (i.e., software programs) to effectively assess the extent of the vulnerabilities by creating exploits, and to determine if a successful attack has taken place or is in progress.

Third, other commenters state that the proposed rule’s controls on technology for the development of “intrusion software” could cripple legitimate cybersecurity research. To address cyber threats, technical information must be shared with experts across the globe. In order to identify and quickly counter threats, the cybersecurity industry relies heavily on collaboration with other companies within and outside of the United States, as well as independent experts around the world. Many of these experts are self-taught, have no prior formal relationship with cybersecurity firms, and, in many cases, may be unknown until they discover a new vulnerability. To address vulnerability, a company must be able to engage in a back-and-forth dialogue with these researchers and experts. Often, the dialogue must include detailed discussion of exactly how a particular vulnerability could be exploited to gain control of a computer; without such discussion it is not possible to evaluate the risk posed by a vulnerability or to fashion an effective and comprehensive defense. Some commenters were concerned that, by subjecting vulnerability research, assessments, and testing to export licensing requirements including classification, screening, and other control elements, the control would limit the ability to fix and patch such vulnerabilities, leading to an overall decrease in the quality of cybersecurity. When vulnerabilities are discovered, they must be reported as soon as possible so that a fix can be developed. This process involves sharing not only the vulnerability and exploit, but also the technical information on how the exploits work, including the technology to develop them.

The commenters had many suggestions regarding how to address their concerns. The Administration will be reviewing all of them and many other ideas for how to address the policy objectives of the control but without unintended collateral harms. As I have said many times in response to questions about the rule, the only thing that is certain about the next step is that we will not be implementing as final the rule that was proposed. In working through this process, we will continue to seek input from those with expertise and equities in cyber security in both the U.S. government and the private sector before deciding in conjunction with its interagency partners what the next step should be. I thus welcome the Subcommittees’ inputs and am prepared to answer any questions you may have.”

BIS Imposes $750,000 Fine on Intel Sub Wind River Inc. for Violations of Encryption Export Rules—Really?


By: Felice Laird

I must admit to a shudder of excitement and disbelief when I visited the BIS homepage recently and noticed a banner ad announcing a fine against an “Intel subsidiary for violations of encryption export regulations.”  I am one of the original crypto export geeks, having followed the tortured evolution of the controls from the late 1990’s through the creation and mutations of License Exception ENC, to today’s largely self-policing paradigm.  And I had never heard of a company being investigated or fined for violations in connection with an encryption export–until now.  And so, I wonder, why this, why now?

First, let me give the standard disclaimer;  I have no knowledge of this case other than what I have read in the documents released by BIS, namely, the Press Release, the Proposed Charging Letter, the Settlement Agreement and the Order.  These documents were prepared and issued by BIS, and they reflect only Commerce’s side of the story.  In fact, BIS has ordered the companies involved not to say anything publicly about the case, especially not to deny any of the charges, so we will never get the other side of the story.  The documents give clues as to what the violations were, when they occurred, how the Department found out about them and what the specific punishment is.  What is not clear is why, for the first time in 15 years, BIS came out with a public and painful punishment of a large U.S. company for encryption software exports.

For the export compliance professional, there are several really important things to note when reading the documents.  Here are some of them:

  • Wind River Systems is a subsidiary of Intel that was formed after Intel bought Wind River’s assets (and liabilities!) in 2009.  So, the important take away is that there is “successor liability,” and the government will go after a company for an acquisition’s export violations.  So, ask to be at the table in M&A talks.
  • The statute of limitations for the early violations had run out, but BIS made the company waive the statute somewhere along the line, so that the violations count.
  • The company submitted a Voluntary Self Disclosure that up until now (when done in connection with an encryption violation) usually leads to a nasty gram from BIS but no fines.
  • BIS issued a gag order in the Settlement Agreement prohibiting Wind River from saying anything about the case.
  • The Settlement agreement states that Wind River has to pay up in 30 days, or else they won’t be allowed to use any licenses or exceptions.

From my perspective, enforcement actions are useful training tools.  It is always a “better sell” when I am talking to companies about the risks involved in non-compliance when I have a good enforcement case to present as an example.  And indeed, I have had more than one awkward moment when talking with tech executives and developers who ask me to come up with evidence that the encryption controls are worth compliance measures.  Sometimes, I have to appeal to their patriotism as a last resort.  It is good to know that BIS cares enough about encryption export controls to go after non-compliant companies.

Lately though, I have been seriously questioning the rationale for maintaining export controls on commercial products that use encryption, since the disclosures made regarding NSA surveillance by Edward Snowden last year.  If NSA can intercept and decipher 99 percent of data transmissions, how can the USG continue to maintain that the encryption regs are necessary to support the intelligence community?

The better answer is that Category 5 Part II is synced in most respects to the Wassenaar list and the U.S. is obligated to maintain controls to honor commitments made to the Wassenaar member states.  And it is clear that efforts have been made by at least three of the most powerful delegations (U.S., France and the UK) to shore up controls on “cyber security” products, as they actively considered this at the December 2013 Plenary. (BIS deferred publication of CCL changes, affecting “cyber security” products, agreed to at the December 2013 plenary – indicating that these would be published in September, which has come and gone with no reg in sight.)

So, Wassenaar member states have had controls on encryption too.  But no country has a byzantine regulatory scheme comparable to that maintained by the U.S.  Over the years, License Exception ENC has morphed into a virtually inexplicable licensing loophole.  And so we wonder–should companies really have to continue funneling information to BIS and NSA by way of Classification Requests and Classification reports?  Does NSA really use any of the information?  Does anyone actually read the self-classification reports? ENC shipping reports?

In the few cases over the years that someone from NSA has shown up in daylight to an industry meeting, I always ask the question and get the answer that, yes, the information it gleans from the classification requests and reporting process is still necessary.  I must admit, I have never really bought that story, but that remains part of the answer to the why question.

That brings us back to the timing issue.  The press has widely reported the steps that the information technology industry has been taking to harden products and networks using cryptography and other security technologies to protect customer information from access by government agents.  Perhaps the Wind River case was meant to be a reminder to the industry that the U.S. Government still has the power to regulate which technologies are deployed internationally.

Wassenaar Arrangement Modifies Controls on Electronic Surveillance Tools


By: Brooke Driver

At its annual plenary meeting in Austria December 3-4, 2013, the Wassenaar Arrangement, a group of 41 countries including the U.S., Russia, the U.K. and most E.U. states, focused on export controls for conventional arms and dual-use goods and technology, agreed on new harsher export controls on cybersecurity technologies, recognizing their great potential for terrorism. Each participating country must now implement these changed policies, one major area of which is surveillance and intelligence gathering tools, including malware and rootkits, which governments can use to bypass security features on electronic devices in order to attain supposedly protected data. Internet protocol network surveillance systems or equipment are also now subject to revised export controls, which include technologies used to screen for malware, viruses and surveillance programs. These technologies are subject to new controls, because representatives of the 41 countries believed that they could be used to both block cyber attacks and grant foreign persons dangerous insight into Western screening systems, increasing the potential for hacks. The agreement also places stricter controls on intelligence gathering technologies that analyze individuals’ or groups’ relational networks and activities, although there will be exceptions for companies using such software for marketing or consumer-monitoring purposes.

Click here for details of these changes and others decided upon at this year’s Wassenaar plenary meeting:

What the New Encryption Rules Mean For U.S. Exporters


This article originally appeared in a slightly different form in International Trade Law360, July 1, 2010.  Reprinted with permission of Pillsbury Winthrop Shaw Pittman LLP.

by Sanjay Jose Mullick

The Obama administration has taken the first step in export control reform by easing the pathway for U.S. companies to export certain encryption items.

The First Export Control Reform

On June 25, the U.S. Department of Commerce’s Bureau of Industry and Security issued new regulations governing export controls on encryption. This rulemaking represents the first formal example of the president’s initiative to reform U.S. export controls by concentrating regulation on the most sensitive items.

The new regulations reflect a recognition that encryption is ubiquitous in today’s high-tech world and cannot be completely regulated. These rules also attempt to address the need for U.S. companies to be able to get to market quickly, to foster the competitiveness of U.S. industry. However, they do not accomplish a complete de-control of encryption, and the prior system will remain in place for many products.

Although the regulations have been published as an interim final rule with a request for comments, they likely reflect the prevailing framework for regulating encryption exports going forward. Let’s take a look at some of the key elements of the new rules and how they will impact exporters.

Company-Based Framework

The new rules move away from a regulatory approach based on disclosure of the technical characteristics of the product to be exported to one focused on the profile of the company that will be making the exports.

Encryption Registration

When President Obama first announced the export control reform initiative, he stated that he wanted to change the export authorization process for encryption items “from 30 days to 30 minutes” and the new rules accomplish that. Specifically, for “less sensitive” encryption items, and for mass market items, the prior requirement to submit a technical questionnaire to BIS for it to conduct a product review has been replaced with one whereby the exporting company submits an online “encryption registration.” The encryption registration consists of contact information, an overview of the company and an identification of what categories apply to the company’s products.

Once the registration is submitted to BIS, the agency immediately issues a registration number, and the company becomes authorized to export encryption products such as local area network products, small routers and mass market items. For these products, companies no longer have to submit a technical questionnaire response with information about the product’s encryption algorithms and no longer have to wait 30 days to obtain authorization to export to key markets such as China and India.

Under the prior rules, it was often a good business practice for companies to make available to their customers, distributors and other business partners the classifications BIS issued pursuant to ENC review requests. This was because when BIS classified a product, other companies could rely on that classification as authority to make their own exports of the product, even if that company had not submitted the classification. Under the new rules, BIS has indicated that an exporter may rely on a producer’s encryption registration (to export that producer’s encryption product) without itself having to file a distinct encryption registration.

Classification Report

The company registration requirement is coupled with a requirement for the company to file an annual self-classification report. The report consists of a listing of the encryption items the company has self-classified and exported. Specifically, the report consists of the following six elements: (i) product name; (ii) model/series/part number; (iii) primary manufacturer; (iv) export control classification number; (v) encryption authorization type, e.g., ENC; and (vi) item type selector, e.g., gateway, modem or virtual private network. The report can be filed by e-mail.

One aspect of License Exception ENC many companies have disliked has been the requirement to file semi-annual reports. Although not a requirement that impinged export authorization, that reporting requirement could pose an administrative burden because it required capturing several information fields for all the applicable transactions, and doing so in a way that they could be retrieved and converted into a spreadsheet. For certain encryption items, that reporting requirement no longer applies and has been replaced with the more streamlined annual self-classification report.

Two Key Developments

Although the general easing of export controls on encryption items is important, there are two developments that are particularly key because they extend the useful scope of License Exception ENC and entirely de-control a class of items, respectively.

Encryption Technology Included

One of the limitations of License Exception ENC had been that, as to several countries, it did not authorize exports of certain “technology” necessary for manufacturing, development or testing of encryption items. This would be relevant, for example, if a company were co-developing a product with a business partner overseas and needed to exchange certain technical specifications on encryption or engage in related technical discussions. Under the prior rule, the commodity and software could be exported under License Exception ENC, but the related technology had to wait for the longer approval of an export license, delaying product development.

The new rules now grant export authorization to items classified as ECCN 5E002 after submission of a classification request, either immediately or after 30 days, depending on the country. In now extending License Exception ENC to encryption technology, this one form of export authorization is enough to proceed with all tracks of product development, i.e., the commodity itself and now also both the related software and technology. Depending on the country, the authorization may not extend to encryption technology for more sensitive items, such as for cryptanalytic items, those with an open cryptographic interface and for “non-standard cryptography” (discussed further below). Notably, the authorization also does not extend at all to certain countries typically involved in offshore manufacture and software development. For example, although India is included, China and Russia are excluded.

Ancillary Encryption De-Controlled

The new rules also entirely release from the encryption controls items where “the primary function or set of functions” is neither (i) information security, (ii) computing, (iii) information storage or transmission, nor (iv) networking, and where the cryptographic functionality is limited to supporting the primary function or set of functions. Such items now include gaming, household appliances, fire alarm systems, inventory management software and business process automation. Exporters should review the entire list carefully to see if it applies to their business.

BIS took a sizable step in this direction in October 2008 when it created the exception for items that perform only “ancillary cryptography.” Although that allowed those products to escape the review requirement, it was somewhat confusing because the products still were classified, e.g., under ECCN 5A002 and required License Exception ENC for export. The new rule allows such products to be classified as EAR99, so long as any other aspect of their functionality does not trigger a specific ECCN.

Limitations of the Changes

Alas, the new rules do not ease the regulatory burden on all encryption products. Upon a closer review, chip manufacturers and software developers may conclude the amended regulations do not provide the benefits they may seem to offer at first glance.

Encryption Components

Still subject to the traditional requirement to submit a one-time product review (now termed a classification request) and to file semi-annual product export reports are certain “encryption components” and “equivalent or related software,” including (i) chips, chipsets, electronic assemblies and field programmable logic devices; (ii) cryptographic libraries, modules, development kits and toolkits; and (iii) application-specific hardware or software development kits.

Depending on the encryption algorithm and key length, this means those involved in supplying OEMs with the encryption elements of even consumer-type items, as well as companies engaged in cross-border development of their own products, generally will still likely have to follow the prior procedure. As before, whether exports are authorized to commence upon registration of the classification request or are subject to the 30-day waiting period will depend on the countries involved.

BIS has also been reluctant to grant mass market treatment to components of mass market end-items, e.g., the chip going into a consumer smartphone as opposed to the smartphone itself. This is because such components may not necessarily be sold in the same way as the final product and, until incorporated into it, they theoretically could be used in other applications.

In the future, perhaps BIS might consider extending mass market treatment to such components and software upon a clear demonstration that they are specially designed to be used exclusively with mass market end-items. For now, however, the new regulations re-affirm that generally encryption components will themselves have to satisfy the tests of large sales volume and general retail availability to be able to qualify for mass market treatment.

Non-Standard Cryptography

Also still subject to the prior review and reporting requirement are encryption commodities, software and components that provide or perform “non-standard cryptography.” That term is defined as “any implementation of ‘cryptography’ involving the incorporation or use of proprietary or unpublished cryptographic functionality, including encryption algorithms or protocols that have not been adopted or approved by a recognized interna­tional standards body… and have not otherwise been published.”

Carving out use of encryption that is published is a fairly significant policy development, but it does not go as far as it may seem.

Previously, a fairly common stumbling block for industry was using publicly available algorithms like Advanced Encryption Standard without recognizing that their incorporation or implementation into proprietary products was deemed to create a new and distinct encryption product requiring ENC review. Focusing controls on “non-standard cryptography” may go a long way toward exempting those end-products from classification and waiting period requirements.

However, use of such algorithms and protocols can still be considered nonstandard cryptography if—though standard themselves—they are being modified or customized in a particular way. Companies will likely have to conduct careful internal review of how they are using encryption before concluding they are not using “nonstandard cryptography.”

These are concepts that are new even to the regulators, so at this stage the full range of their scope and applicability is not entirely clear. Instead, sorting out exactly what fits this criteria can be expected to be a focus of discussion over the coming months.

Restricted Items

License Exception ENC continues to contain a subsection previously called “ENC Restricted,” which covers items such as network infrastructure software, commodities and components. BIS has revised and updated that list and it should be reviewed carefully. It also imposes classification, waiting period and reporting requirements. This subcategory of encryption items is significant because, for certain countries, an export license is required in order to export to governmental customers.

New Regulatory Architecture

In issuing the new encryption regulations, BIS indicated it would continue to review the rules, and certainly the real process of export control reform has only just begun. What these regulations do accomplish is the creation of a new architecture for regulating encryption that recognizes the reality that today encryption is a pervasive technology.

U.S. companies have to be able to develop products, consult with partners and service customers abroad swiftly to be able to compete effectively in a globalized world. At the same time, the speed at which technology can be deployed across borders places a greater strain on the systems that help safeguard national security.

As BIS consults with industry, this new framework should enable it to respond more quickly to market trends by more readily shifting items from a category of greater control to one of lesser control, calibrating the focus of export control resources on higher priority areas.

Sanjay Jose Mullick

International Trade


Sanjay Mullick is a Washington-based member of Pillsbury’s International Trade practice, where he advises clients on export issues concerning encryption software and technology and on designing and implement­ing export control compliance programs.

BIS Ruling on Encryption Software


By: Danielle McClellan

BIS recently published an advisory opinion on downloads of encrypted “mass market” software. An undisclosed recipient asked BIS “whether a company would be in violation of the EAR if it allowed certain encrypted software, reviewed and classified by BIS as “mass market,” to be downloaded free of charge to anyone from the company’s website without restriction.” BIS responded by explaining that simply “publishing “mass market” encryption software to the internet where it may be downloaded by anyone NEITHER established “knowledge” of a prohibited export or reexport nor triggers any “red flags” necessitating the affirmative duty to inquire under “Know Your Customer” guidance provided in the EAR.”

So let’s break this down, if a person or company posts “mass market” encryption software on their website for free download and the download is anonymous then there is no EAR violation, even if a person from Iran, Cuba, Syria, Sudan or North Korea downloaded the software. There is a catch though, if the company/individual asks for a name and email before the download can occur, all bets are off and you or your company are now responsible for screening individuals. BIS stated that if the download is not anonymous (you obtain a name or email) the company becomes responsible for ensuring that no one from Iran, Cuba, Syria, Sudan or North Korea downloads the software. A license would be required for individuals from these countries. It should be noted that BIS did say that, “a violation would not occur if the IP address of the person downloading the software is collected by the software provider at the time of the download and stored as a “footprint” in the machine code of the software provider’s database, but is not tracked or used for any purpose by the software provider.

So in the end you’re not violating any regulations if you post “mass market” encryption software on the web as long as the download is free and anonymous. Remember, this is a don’t ask, don’t tell relationship. If you ask for the information from the user you have to tell BIS and possibly get a license, if you don’t ask; you don’t have to talk to BIS at all.

Advisory Opinion:

Commerce Relaxes EAR to Be More Like the ITAR



By: Danielle McClellan

It used to be that the International Traffic in Arms Regulations allowed a US citizen employee of a US exporter to carry export-license-required-technical data (technology) out of the country on his/her laptop while the EAR did not allow the same thing to happened. That has now changed.In the December 12, 2007 Federal Register, the Bureau of Industry and Security, Commerce has revised the Export Administration Regulations (EAR) to expand the export license exceptions Temporary Imports, Exports, and Reexports (TMP) and Baggage (BAG) to allow for certain exports and reexports of technology between two U.S. persons or their employees traveling or those that are temporarily assigned abroad.

The rule expands the availability of License Exceptions TMP and BAG but does not authorize any new release of technology. Any technology exported under the new rule may only be released to persons who may receive that same technology pursuant to other provisions of the EAR which means it will still be subject to restrictions applicable to technology exports and reexports. (more…)

Minute by Minute Report from Commerce Update Conference 2006



By: Scott Gearity

Editor’s Note:

If you didn’t make it to Update 2006, it turns out that the only thing you missed was the posh reception including sushi, crab cakes, and free drinks. You get all of the substance of the presentations here because Scott Gearity wrote a live report from the Commerce Department’s annual Update conference on October 16-17, 2006. Note the time stamp at the beginning of each point below.
–John Black


BIS Spring Cleaning



By: Scott Gearity

April 29 saw the publication of a sort of spring cleaning regulation from BIS in the form of updated contacts and minor administrative corrections.  Think of it as the bureaucratic equivalent of a good scrubbing and a new coat of paint.

Among the office number changes and snappy turns of a phrase like “this rule corrects a citation error in Sec. 762.1(a)(4) by revising the reference to Sec. 734.2(b)(7) to read Sec.  736.2(b)(7),” there is a mention of the office Commerce continues to insist on calling the “ENC Encryption Request Coordinator.” Elsewhere in the rule BIS refers to this mysterious place as “that organization.”

Now, you know, I know, and the American people know that the National Security Agency exists.  It’s not a secret any more.  They have a website.  Nor is it classified that NSA plays a vital role in formulating US export controls on encryption.  Former BIS undersecretary Bill Reinsch noted it all the way back in 1998.  Brian Nilsson mentioned discussions with NSA at a Regulations and Procedures Technical Advisory Committee (RPTAC) meeting in 2001.  Peter Lichtenbaum thanked Norm Lacroix for working with them just last year.  In December, BIS even spilled the beans by pointing out in the last encryption reg that the ENC Encryption Request Coordinator has a email address.  So what’s with the pseudonym?

Not mentioned by BIS is that NSA is no longer accepting documents via fax.  Their old number (301) 688-8183 is no longer in service and no one seems to be distributing the new one.

Guide to New US Encryption Export Regulations



(Editor’s Note:  Even companies who do not manufacture encryption products may find themselves exporting software or hardware that employs encryption.  Special thanks to Felice, a leading expert on crypto controls, for her clear overview of the new crypto rules. )


US rules on the export of encryption technology have been changing on the average of every 8 months, beginning in December of 1996. The only constant has been that the rules have been overwhelmingly confusing and ambiguous. The latest go-round of changes happed on June 6, 2002.  (Please note that the export regulations governing the export of encryption technology consist of general rules and myriad exceptions to these rules. Therefore, the following should be viewed as an overview and your particular situation should be analyzed with reference to the actual regulation. Such exotica as source code, beta-test software, open cryptographic application programming interfaces, etc, are beyond the scope of this article.


The US has the legal authority to control the export of encryption technology under the Export Administration Act . The regulations that implement this law are called the Export Administration Regulations (“EAR”). You can view the regs on-line at If you are primarily interested in crypto exports you will want to look at section 740.17. This section will reference other sections, but the bulk of the specific rules regarding encryption will be here.


The Bureau of Export Administration (BIS) is the primary agency you need to deal with if you want to get export approval for your encryption products. However, the National Security Agency is heavily involved in the process, so you will often need to deal with them.


ECCNs 5A992, 5D992 and 5E992

Certain products that use encryption technology for limited functions fall under 5A992 (hardware) or 5D992 (software). These products are generally of the following nature:


–Access Control Systems

–Digital Signature

–Some Smart Cards

–Some cell phones and components

Other products also fall within these two ECCNs namely:

–Products that use 56-bit DES or comparable algorithm and key exchange under 512

–Products that use 64-bit symmetric algorithms for data confidentiality and are “mass market”

–Products that use symmetric algorithms of any key length for data confidentiality and are “mass-market.”

ECCNs 5A002, 5B002, 5D002

If your product uses encryption and is not covered by the above-mentioned categories, then it is likely caught by 5A002 (hardware), 5B002 (test and production equipment) and 5D002 (software). Technology to make items covered by 5A002, 5B002 or 5D002 is covered by 5E002. Products covered by these ECCNs may be exported in many cases using License Exception ENC. Exports not allowed under ENC need an individual license or Encryption Licensing Arrangement.


If you make a product that uses encryption (regardless of key length) for limited functions like user authentication, access control, digital signature, or banking you can “self-classify” and ship under No License Required (NLR.)

For products using symmetric algorithms with 64-bit key lengths or less or asymmetric algorithms of 512 bits or less, a simple notification to BIS and NSA is all that is needed to be able to ship under NLR.

If you think you qualify for the exemption for strong crypto “mass market” products, you must file a “review request” to see if BIS agrees with you. The definition of mass market is taken from the Cryptography Note of the regulations:

a. Generally available to the public by being sold, without restriction, from stock at retail selling points by means of any of the following:

1. Over-the-counter transactions;

2. Mail order transactions;

3. Electronic transactions; or

4. Telephone call transactions;

b. The cryptographic functionality cannot be easily changed by the user; and

c. Designed for installation by the user without further substantial support by the supplier.

BIS and NSA have stated that they are going to be “strict” when considering requests to classify strong encryption products as “mass market.” Specifically, they want proof that the product is sold in a computer store like CompUSA.

For all software, hardware and technology controlled by 5A992, 5D992 and 5E992 you can export to all countries except the terrorist countries, to all end-users except the bad guys under NLR and no reporting is required.


License Exception ENC is the authority that allows you to export most encryption products covered by ECCNs 5A002, 5B002, 5D002 and 5E002. However, before you can use this license exception, you usually need to submit a Commodity Classification request to the BIS/NSA. (If your shipments are confined to subsidiaries of US companies you don’t have to go through this step.) You also have to keep records of who you ship to because you need to report to BIS and NSA who you ship to every six months.  You can export products to any end-user under ENC in the following countries immediately upon filing a Commodity Classification Request.

Austria, Australia, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Spain, Sweden, Switzerland, United Kingdom

If your product uses strong encryption but you want to sell outside these countries, you need to wait 30 days before shipping and you cannot ship to “government end-users” unless your product qualifies as a “retail” product. If it qualifies as a “retail product” it can go to any end-user in any country other than the bad countries under ENC. If it is not a “retail product” it can only go to non-government end-users under ENC. You will be informed when your Commodity Classification is complete if your product qualifies as retail.

Retail vs. Non-Retail

The concept of “retail” is similar to the concept of “mass-market” discussed previously. “Retail” products generally available to the public by being

(1) sold through retail outlets,

(2) specially designed for individual consumer use, OR

(3) which are or will be sold in large volume without restrictions through mail order, electronic or telephone sales.

However, these “retail” products CANNOT:

(a) allow the cryptographic functionality to be easily changed by the user,

(b) require substantial support to install and use

(c) be modified or customized for the customer and

(d) be designed to be used as network infrastructure products.

Examples of “retail” products are general purpose operating systems that don’t qualify as “mass-market”, chips designed for retail products, low end routers, firewalls and VPNs designed for the SOHO market, desktop applications that do not qualify as “mass-market”, low end servers and application specific servers, network and security management products designed for low end computers and products which contain short range wireless encryption software/components.


You need to keep records of whom you provide encryption products (i.e., controlled under ECCNs 5A002, 5B002, 5D002 or 5E002) to under license exception ENC. The reason why you need to do this is because you will need to send a report to the Bureau Industry and Security and the National Security Agency twice a year. (See Reporting section below.)


You are required to send in reports to the BIS and the NSA that contains information on who you ship to, and what kind of technical review the product has undergone. This is only necessary for products that are shipped under license exception ENC. Reports are required for shipments under ENC, EXCEPT in the following instances:

1. You are shipping to a subsidiary of a U.S. company

2. You are shipping to a US bank or financial institution or anyone that does business with them.

3. You are shipping weak crypto products (e.g., under 64-bits).

4. You are shipping a “retail” product to an individual consumer.

5. You are making the software available via free or anonymous download.

6. You are shipping single processor computers, laptops and hand-held devices that are pre-loaded or bundled with encryption software.

The reports are due according to the following schedule:

–For shipments made between January 1st and June 30th, the report is due on August 1st.

–For shipments made between July 1st and December 31st, the report is due on February 1st.

You need to prepare the report in an electronic format and send via e-mail or load onto disk and send to the mailing addresses below:

e-mail addresses:


mailing addresses:

Bureau of Industry and Security

US Department of Commerce

Office of Strategic Trade and Foreign Policy Controls

14th Street and Pennsylvania Avenues

Room 2705

Washington, D.C. 20230

Attn: Encryption Reports

ENC Encryption Request Coordinator

9800 Savage Road

Suite 6131

Ft. Meade, MD 20755-6000

The report should identify:

–Company name and address,

–Contact person and contact information,

–Reporting period

–And for each product the report should include:

–Product name and license or CCATS number for the product

–Ship-to-parties name and addresses, and the quantities and dates of shipment for each

by Felice Laird, Export Strategies