Export Controls and the Implications for Security Research Tools

The Open Technology Institute is currently engaged in a joint project on export controls with Privacy International and Digitale Gesellschaft. The blog post below was published in response to the recent changes announced to the Wassenaar Arrangement. The original blog post is available here.

Export Controls and the Implications for Security Research Tools

One of the major dangers of imposing export controls on surveillance systems is the risk of overreach. While you want the scope of the systems being controlled and the language to be wide enough to catch the targeted product and its variants, you also need the language to be specific and detailed enough to ensure that no items get inadvertently caught at the same time. Getting this right is acutely important for security researchers. Export controls can represent a problem for security researchers because it is often difficult to differentiate between legitimate research, products used to test defences, and activities and products that are used to actually penetrate them without consent.

Security researchers need to be able collaborate with one another, across territorial boundaries, and they also need to be able to share their work and problems. The outcome of such research should not be penalized; responsibly disclosing vulnerabilities in hardware and software for example or the tools used to discover them, should never become subject to export controls.

Implications

Discussions between Privacy International and export control officials involved in drafting the new controls suggest that it was never the intention of these new controls to catch legitimate security research tools and that efforts have been made to prevent them from being subject to controls. On the face of it however, there are still areas to be worried about in the new agreement.

As is standard throughout the Wassenaar control list, it is not only finished items themselves that are subject to control, but also any software and technology that is used to produce or operate them. The new controls on intrusion software therefore also includes controls on: "Technology"1 for the "development"2 of "intrusion software" "Software" specially designed or modified for the "development" or "production" of equipment or "software" specified by 4.A. or 4.D. * "Technology" according to the General Technology Note, for the "development", "production" or "use" of equipment or "software" specified by 4.A. or 4.D. Although unintended, these controls could also catch some legitimate security products. There are of course exceptions; software and technology in the public domain is exempt (more on that later), as is technology for "Basic scientific research" – defined as ”Experimental or theoretical work undertaken principally to acquire new knowledge of the fundamental principles of phenomena or observable facts, not primarily directed towards a specific practical aim or objective.”

There are specific technologies that are exempted from controls as well; DRM software is unsurprisingly included in this category, as are “Hypervisors, debuggers or Software Reverse Engineering (SRE) tools”, in addition to software to “be installed by manufacturers, administrators or users, for the purposes of asset tracking or recovery.” It is unclear at this stage what conversations were had that led to expert group deciding to exclude debuggers and not explicitly security research products.

The important issue now is how this category is interpreted and implemented. It is our understanding that export control authorities did not want to catch security research tools and may well explicitly or implicitly exempt security products at a national level. In the UK, for example, exporters can apply for a Control List Classification enquiry to determine whether or not a product is subject to control, a process that takes into consideration the original design purpose of a product. Export licensing authorities, and particularly enforcement officers within customs, do not want to create unnecessary work for themselves if it serves no legitimate purpose. It is also important to remember that while some products may be caught under this category, it is still up to prosecutors to decide whether or not to pursue a case if there has been any infringement.

It’s still early days following the publication of the agreement, and the scope of the consideration given to security research tools remains untested. What’s important now is to establish the extent of the safeguards put in to prevent overreach; Privacy International and others will be doing a number of things before these controls are implemented: We will pursue outreach with governments and the expert groups involved in the discussions to ascertain what thought was given to security research products throughout the process We will consult licensing authorities to find out if they intend to control security research products within the new categories We will campaign vigorously against the control of any such products and ensure that category 4 is implemented across member states in such a way as to not catch security products We will initiate conversations with the security industry to ascertain their understanding of the new controls and how it affects them We’ll keep you posted.

Footnotes

1."Technology" Specific information necessary for the "development", "production" or "use" of a product. The information takes the form of technical data or technical assistance. Controlled "technology" for the Dual-Use List is defined in the General Technology Note and in the Dual-Use List. Controlled “technology” for the Munitions List is specified in ML22.

Technical Notes 1. 'Technical data' may take forms such as blueprints, plans, diagrams, models, formulae, tables, engineering designs and specifications, manuals and instructions written or recorded on other media or devices such as disk, tape, read-only memories. 2. 'Technical assistance' may take forms such as instruction, skills, training, working knowledge, consulting services. 'Technical assistance' may involve transfer of 'technical data'. 3."Development" Is related to all stages prior to serial production, such as: design, design research, design analyses, design concepts, assembly and testing of prototypes, pilot production schemes, design data, process of transforming design data into a product, configuration design, integration design, layouts.

In addition to the links below, further recommended reading includes the Privacy International Surveillance Industry Index and Against Hypocrisy: Updating Export Controls for the Digital Age by OTI's Danielle Kehl and Tim Maurer.