Last week the Bureau of Industry and Security published a final rule implementing the changes adopted by the December 2016 Wassenaar Arrangements Plenary meeting.  Most of these changes are the usual nits and quibbles cooked up to justify a nice government-paid international trip by the delegates.  Like this:

The Heading of 1C608 is amended by adding double quotes around the defined term “energetic materials” …

The most interesting change, however, at least in my view, was the re-working of Note 4, which provides a broad exception to export controls on encryption.   Allegedly, the change wasn’t supposed to change anything, and BIS’s notes to the amendments say just that.   This, of course, would lead ordinary people to wonder why change something you don’t want to change, but, of course, I guess they felt guilty charging their governments for simply re-arranging semicolons, adding quotation marks and correcting spelling errors in the Wassenaar lists.

Part of the problem in the new, improved version is that it’s going to be harder to explain to clients.  Anyone who has spent much time dealing with software engineers on encryption export matters will immediately see the difficulties ahead.   (That means anyone who has had to argue with a software engineer that his program is still covered even though the encryption routines are called from the operating system.)  This post is intended to help you in that process (as well as to make fun of a note added to 5A002 by the amendment).

So, let’s take a quick trip down memory lane and now look at the text of the old Note 4.

Note 4: Category 5—Part 2 does not apply to items incorporating or using ‘‘cryptography’’ and meeting all of the following:
a. The primary function or set of functions is not any of the following:
1. “Information security”;
2. A computer, including operating systems, parts and components therefor;
3. Sending, receiving or storing information (except in support of entertainment, mass commercial broadcasts, digital rights management or medical records management); or
4. Networking (includes operation, administration, management and provisioning);
b. The cryptographic functionality is limited to supporting their primary function or set of functions. …

Under the new amendments, the idea is “the creation of positive text in 5A002.a to specify the items subject to control.” I bet the entire encryption world was anxiously awaiting that, don’t you? So, to create this, er, “positive text” subsections 1, 2 and 4 have been moved to the text of ECCN 5A002. Subsection 1 becomes 5A002.a.1, subsection 2 becomes a.3 and subsection 4 becomes a.2 as follows:

a. Designed or modified to use ‘cryptography for data confidentiality’ having ‘in excess of 56 bits of symmetric key length, or equivalent’, where that cryptographic capability is usable without ‘‘cryptographic activation’’ or has been activated, as follows:
a.1. Items having ‘‘information security’’ as a primary function;
a.2. Digital communication or networking systems, equipment or components, not specified in paragraph 5A002.a.1;
a.3. Computers, other items having information storage or processing as a primary function, and components therefor, not specified in paragraphs 5A002.a.1 or .a.2

And, if you look closely, you can see that part of 3 was slipped into a.3 when it references items having “information storage” as a primary function. (Operating systems now get caught in 5D002.a.1 which controls software for the use of computers described in 5A002.a.3).

But what about items with the primary purpose of sending and receiving information? In the software context, this meant, for example, email and FTP programs, which were not considered eligible for the Note 4 exemption. You have to assume that is now captured by a.2, which talks not just about networking but also about “digital communication.”

That leaves subsection b on Note 4, which, frankly, never seemed to apply to much of anything. That now becomes a.4:

Items, not specified in paragraphs 5A002.a.1 to a.3, where the ‘cryptography for data confidentiality’ having ‘in excess of 56
bits of symmetric key length, or equivalent’ meets all of the following:
a.4.a. It supports a non-primary function of the item; and
a.4.b. It is performed by incorporated equipment or ‘‘software’’ that would, as a standalone item, be specified by ECCNs 5A002, 5A003, 5A004, 5B002 or 5D002.

Because it’s not clear what exactly such an item would be, the amendment adds a not very helpful note, in the theme of creating “positive text,” to the new 5A002 to give examples of some items that are not 5A002.a.4. Here’s one:

An automobile where the only ‘cryptography for data confidentiality’ ‘in excess of 56 bits of symmetric key length, or equivalent’ is performed by a Category 5—Part 2 Note 3 eligible mobile telephone that is built into the car. In this case, secure phone communications support a non-primary function of the automobile but the mobile telephone (equipment), as a standalone item, is not controlled by ECCN 5A002 because it is excluded by the Cryptography Note (Note 3)

Okay, I’m going to say it: what century do the plenary delegates live in? Did they all travel in a time machine from 1980 to Wassenaar? Mobile phones built into cars?

So while we’re engaged in time travel, here’s an example of something that would be caught by 5A002.a.4: Maxwell Smart’s shoe phone. Of course, I’m assuming that like any good phone it incorporates non-standard cryptography. The principal purpose of the shoe is, of course, walking and the cryptography supports its non-primary function of talking. So there.

According to this Reuters report, the Russians are demanding from U.S. companies the right to view source code of software that these companies wish to sell in Russia. The software at issue includes software with encryption capabilities, anti-virus software and firewalls. You don’t have to be a rocket (or computer) scientist to figure out why Vladimir and his spy master buddies want to look at such software. They are looking for vulnerabilities that would allow the Russians to continue to hack into U.S. networks and infrastructure. Surprisingly, Reuters suggests that some big names in U.S. software are actually complying.

That’s surprising because, as many readers probably know, handing over the source code of programs with encryption functionality to the Russian government requires a license from the Bureau of Industry and Security (“BIS”). Normally, I would expect BIS, at least for the moment, to grant such a license when hell freezes over or, as Vladimir himself might say, когда рак на горе свистнет (“when crawfish whistle in the mountains.”)

Here’s why a license is necessary. First, keep in mind that BIS controls the export of software with encryption functionality. This includes software that does not contain any encryption algorithms but calls those algorithms from an external source to perform the actual encryption. Although the language of the EAR is far from making it clear, BIS makes it quite clear here on its website:

Almost all items controlled under Category 5, Part 2 of the EAR are controlled because they include encryption functionality. Items may be controlled as encryption items even if the encryption is actually performed by the operating system, an external library, a third-party product or a cryptographic processor. If an item uses encryption functionality, whether or not the code that performs the encryption is included with the item, then BIS evaluates the item based on the encryption functionality it uses.

Most programs, in fact, call encryption from the operating system. Some browsers, such as Firefox, incorporate their own encryption, and programs may utilize browser encryption when sending and retrieving date from the Internet. In any event, the vast majority of software has some encryption functionality either by using the operating system or native encryption in certain browsers.

Second, source code does not fall under EAR section 740.17(b)(1) and is not eligible for self-classification and export under License Exception ENC. Rather source code that is not publicly available falls under 740.17(b)(2)(i)(B). Items that fall within (b)(2), such as source code, can be exported thirty days after the filing of a classification report to “non-‘government end users’ located or headquartered in a country not listed in supplement no. 3.” See Section 740.17(b)(2)(i). As a result, license exception ENC does not authorize exports to government end-users outside Supplement 3 countries. As Russia is not a Supplement 3 country, a license is required to provide source code with encryption functionality to the government of Russia.

I have no way of knowing whether the U.S. companies that have let Vlad peek at their source code bothered with, or even knew of the requirement for, licenses.   And although not so long ago, BIS would probably have said “nyet” to any such license request, it is altogether possible that BIS is now saying “da” instead.   In any event, companies should think long and hard before spilling their source code for software with encryption functionality to the Russkis without getting a license from BIS first.

My dog Maisie shamelessly plugging the historic Cubs victory in the 2016 World Series

This blog previously reported on the recent changes to the encryption rules.   One less-than-carefully drafted provision in those amendments has been causing some confusion relating to the annual self-classification reports

The issue is whether an item once listed on a self-classification report needs to be relisted on subsequent reports.  Before the recent amendments, products needed to be relisted on subsequent reports for each year in which they were exported during the time frame covered by the classification report.

The new rules say this:

Your encryption self-classification report must include the information described in paragraph (a) of Supplement No. 8 to part 742 for each applicable encryption commodity, software and component made eligible for export or reexport under § 740.17(b)(1) of the EAR. Each product must be included in a report only one time. However, if no new products are made eligible for export or reexport during a calendar year, you must send an email to the addresses listed in paragraph (e)(3)(ii)(A) of this section stating that nothing has changed since the previous report.

At least one law firm has, with some justification, read the language saying that a product must be “included in a report only one time” to mean that items need not be included in subsequent annual reports unless, presumably, the encryption functionality of the item has changed.

At the BIS Update 2016, BIS officials made clear that they do not think that the language means what it appears to say. Instead, they asserted, items needed to be included on subsequent annual self-classification report even if encryption funtionality of the item has not changed since the last report. Apparently the language is thought by the agency to mean that you only have to list an item once on the same report, although why anyone ever thought that they would have to list any product more than once on the same report is puzzling.

No one from the agency, however, at least that I heard, could explain what “becomes eligible for export” means. The reporting requirement in the previous version was for items “exported or reexported pursuant to an encryption registration.” Unfortunately this new language requiring the listing in the report of every encryption item “eligible for export” during the reporting period would appear to apply to every encryption item that the company filing the report might have been able to export during the reporting period.  This would be the case whether or not it was actually exported. The safest course, then, for upcoming self-classification reports is to include every item with encryption functionality that was available for sale during the reporting period.

Note: My apologies for the picture of my dog wearing a Cubs hat.  However, there’s this:  (a) the Cubs victory justifies all actions by longtime Cubs fans that are not otherwise illegal, immoral or rude and (b) a dog picture is the only possible way to make a post about BIS’s encryption rules even vaguely interesting.

Photo Credit: Go Cubs Go! by Clif Burns, via www.clifburns.net. Copyright 2016 Clif Burns

Yesterday, the Bureau of Industry and Security (“BIS”) announced various amendments to the encryption rules. I realize that the encryption rules are a sprawling mess, scattered through various sections of the EAR and written in an incomprehensible jargon that sounds like they were translated into English from a Vulcan paraphrase of the original Sanskrit. I also realize that your eyes understandably glazed over when you saw the word “encryption.” So I’ll try to make this as painless and entertaining as possible.

Let’s start with the really big news. Croatia has been added to the list of Supplement 3 Countries! Woohoo! For those of you aren’t really excited about this, that is probably because you forgot that if you are not a Supp. 3 country, there is a 30 day waiting period after a review request has been filed before encryption items described in 740.17(b)(2) and (b)(3) such as source code and high-performance network equipment can be exported to that country. And if those items were going to government end users in  country not on the Supp. 3 list, a license was required. So, today was declared a national holiday in Croatia and papier-mâché effigies of key BIS officials were draped with garlands and paraded through town squares across the country.

While we’re on the subject of government end users, the amendments create a new kind of government end user — “less sensitive government end users.” These are government agencies that are the toughest of their kind and at which you can hurl the most frightening insults — say, “you cabal of pointy-headed bureaucrats!” — without hurting their feelings. No, I’m just kidding with you. “Less sensitive government end users” are government agencies that are less likely to use encryption for evil purposes, like museums, water treatment plants and census bureaus.

The reason for identifying “less sensitive government end users” is that high performance network infrastructure equipment used to require a license to go to any government on the Naughty List (i.e., not on the Supp. 3 Nice list). Now these items can be exported 30-days after a review request is filed provided that it’s a less sensitive government end user.

The best news I’ve saved for last.  No more encryption registration numbers!  For the 50 or so companies out there who still don’t have an ERN, you’re off the hook.  Annual self-classification reports will still have to be filed; and the new format for the report, which is detailed in an amended Supplement 8 to Part 742, incorporates some of the information that used to be required by the ERN application.

For a summary of the remaining changes, including a long-needed update of the performance parameters for high performance network infrastructure equipment subject to higher encryption controls, you can read this excellent summary, which is mostly clear and more or less written in English, helpfully provided by the nice people at BIS.

Photo Credit: Sea view. Rovinj, Croatia by Andrey [CC-BY-SA-2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Flickr https://flic.kr/p/5oVXCk [cropped and processed]. Copyright 2008 Andrey