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.