Note: This document is for informational purposes only and is not intended as legal advice. If you wish to develop and distribute cryptographic software, particularly for commercial sale or distribution, then you should consult an attorney with expertise in the particular laws and regulations that apply in your jurisdiction.
This document discusses the U.S. export regulations in effect as of December 31, 1999. It does not address changes to those regulations which are promised to liberalize somewhat export of encryption software; I've addressed the potential effect of those promised changes in a separate document, "Analysis of Proposed Changes to U.S. Encryption Export Regulations".
At the highest level the U.S. government regulates particular actions (e.g., "export") by particular people (e.g., U.S. citizens and residents) involving particular items (e.g., software of various types); those regulations are justified by various reasons and based on legislation passed by the U.S. Congress in the context of the U.S. Constitution. Traditionally most of the export regulations have been justified based on the need to protect national security and to support particular U.S. government policies toward other nations; thus, for example, the U.S. restricts export to almost all countries of certain nuclear power-related materials and technologies, in order to prevent proliferation of nuclear weapons, and restricts export of almost all items to certain countries deemed to support international terrorism, as part of U.S. sanctions and related policies directed against those countries. In the case of encryption software and technologies, one justification for regulation has been that encryption software and technology (and cryptography in general) have military applications.
Thus for a long time encryption export was covered by the International Traffic in Arms Regulations [ITAR], which cover "munitions" in general (guns, tanks, warplanes, etc.) and are administered by the Office of Defense Trade Controls [DTC], part of the U.S. Department of State [State]. The ITAR still exist, however they no longer regulate encryption export; in 1996 the Clinton Administration transferred regulation of export of encryption software, hardware, and technology from the ITAR to the Export Administration Regulations [EAR]. The EAR regulate "dual use" items, i.e., items which have both military and non-military uses, and are administered by the Bureau of Export Administration [BXA], part of the U.S. Department of Commerce [Commerce]. The EAR are part of the U.S. Code of Federal Regulations [CFR]; more specifically, they are in Title 15 of the CFR, "Commerce and Foreign Trade", Chapter VII, "Bureau of Export Administration, Department of Commerce (Parts 700-799)", Subchapter C, "Export Administration Regulations"; hence the EAR are also sometimes referred to as 15 CFR chapter VII subchapter C or 15 CFR Parts 730-774.
Like other U.S. government regulations, the EAR ultimately are authorized by laws passed by the U.S. Congress. The legal authority for the EAR rests principally on the Export Administration Act of 1979, as amended, and the International Emergency Economic Powers Act, as amended, as supplemented by various Presidential Executive Orders; for complete details see the document "Principal Statutory Authority for the Export Administration Regulations" [EARAuth].
The U.S. Constitution [Const], as interpreted by the U.S. Supreme Court, restricts which types of laws Congress may pass and what types of regulations the Executive branch may create and enforce. Thus, for example, the First Amendment to the Constitution [1stAm] prohibits Congress from restricting freedom of speech or of the press; based on this prohibition, and the U.S. Supreme Court's interpretations of it, it is difficult for Congress to legally restrict what people may say in public or write on paper and distribute. If encryption software (or software in general, for that matter) were to be designated by the Supreme Court as speech protected under the First Amendment then the question of export regulation of such software would not even come up, because Congress could not constitutionally pass legislation authorizing the Executive branch to make such regulations. However the Clinton Administration does not consider software to be constitutionally-protected speech, and although two lower courts have decided otherwise in the Bernstein case [Bernstein], in the absence of a Supreme Court decision the relevant legislation and regulations remain in general effect.
Also, as noted in 15 CFR 730.5, the EAR do not just regulate "exporting" in the conventional sense, i.e., sending something from the U.S. to a location outside the U.S. The EAR also regulate a number of related activities, including:
As I discuss below, this additional scope of the EAR very much complicates the task of developing open source encryption software in the U.S., since it means that developers can potentially violate the EAR even without actually transmitting any software outside the U.S.
However, being subject or not subject to the EAR does not in and of itself mean that particular items and activities are restricted or unrestricted respectively. Even items that are subject to the EAR may not require actual export licenses, as discussed below. On the other hand, items not subject to the EAR may still be regulated by other U.S. regulations, e.g., the ITAR or others.
As noted in 734.3(b)(3), among the items not subject to the EAR are "publicly available" technology and software, including technology and software that are "available for general distribution either for free or at a price that does not exceed the cost of reproduction and distribution" (from 734.7(a) and (b)). This provision means that most open source software is exempt from regulation under the EAR and, assuming it is not regulated under any other U.S. regulations (which is typically the case), U.S. developers can freely export such software from the U.S. and can participate in development of it with other developers around the world. However this is not the case for open source encryption software; encryption software is specifically excluded from the "publicly available" provisions, as discussed below.
Besides publicly available technology and software, other important items not subject to the EAR are printed materials, e.g., books, magazines, and newspapers, and related items (see 734.3(b)(2)). These of course are items which have traditionally been protected under the First Amendment; in this respect note that printed books containing encryption source code or descriptions of encryption technologies are not subject to the EAR, unlike encryption software and technology in other forms.
As noted in 734.3(c), the major class of items that are subject to the EAR is the list of items in the Commerce Control List (CCL) in 15 CFR Part 774 [EAR774]; this list of items subject to the EAR includes encryption software and technology, as I discuss below. Finally, as noted in 734.5(c) (and also discussed below), activities (as opposed to items) that are subject to the EAR include "technical assistance by U.S. persons relating to encryption commodities or software".
As noted in 736.2(a), such general prohibitions may apply based on a variety of factors: what kind of item you're exporting or reexporting (e.g., how it is classified on the CCL), to what country or countries you're exporting or reexporting an item, for what ultimate end-user or end-use you're exporting or reexporting an item, or what other kind of conduct you're engaged in.
Note that the EAR general prohibitions (and associated licensing requirements) do not apply just to items created in the U.S. For example, while 736.2(b)(1) prohibits unauthorized export or reexport of EAR-controlled items of U.S. origin, 736.2(b)(2) goes on to prohibit unauthorized export or reexport of "foreign-made" items incorporating EAR-controlled items originating in the U.S., and 736.2(b)(3) adds a prohibition against unauthorized export or reexport of "foreign-produced direct products" of EAR-controlled technology or software originating in the U.S. Thus, for example, you might be prohibited from unauthorized export or reexport of a software product that was for the most part created outside the U.S. but which incorporates a software library created in the U.S. As discussed below, these types of prohibitions create major restrictions on what U.S. developers can do with respect to encryption software created outside the U.S.
Each particular type of item placed on the CCL is assigned an Export Control Classification Number or ECCN based on its CCL category, as described in 738.2(d)(1), and given an entry in the CCL that describes (among other things) what type of items are included in that ECCN and for what reason(s) their export is controlled. There are twelve official "Reasons for Control", ranging from prevention of proliferation of nuclear weapons ("NP") to general reasons related to national security ("NS"); there is an "EI" Reason for Control applied just to encryption items. As noted in 738.2(d)(2)(i)(A), a particular item (i.e., listed in the CCL under a particular ECCN) may be controlled for multiple reasons; as discussed below, encryption software and technology are marked as being controlled not only under the special "EI" Reason for Control but also under the more general "NS" (national security) and "AT" (anti-terrorism) Reasons for Control.
The official Reasons for Control determine (among other things) which countries a particular item may be exported to without a license, based on a Country Chart included as Supplement No. 1 to Part 738 [EAR738S1]. Thus, for example, an item controlled for reasons of nuclear proliferation ("NP") might require a license to be exported to Armenia, but not to be exported to Australia or Austria. (The way in which the Country Chart works is slightly more complicated than that, since for a given Reason for Control there might be distinctions made that some items can be exported to more countries than others. Thus the Reason for Control in the CCL listing for a particular item will be supplemented by a reference to a particular column in the Country Chart, e.g., "NP Column 1" or "NP Column 2" as opposed to simply "NP"; in the case of the "NP" Reason for Control, an item controlled based on "NP Column 1" requires a license for export to most countries, but an item controlled based on "NP Column 2" requires an export license only for a few countries, including India, Israel, and Pakistan.) Note that the Country Chart does not include a column or columns for the "EI" (encryption item) Reason for Control; as discussed below, items controlled for "EI" reasons can be exported only to Canada without a license.
For more information on the Reasons for Control used in the Commerce Control List, see 15 CFR Part 742, "Control Policy - CCL Based Controls" [EAR742]; in particular, 742.15 describes the "EI" Reason for Control.
(The license application process is described in 15 CFR Part 748, "Applications (Classification, Advisory, and License) and Documentation" [EAR748]. If you are not sure how a particular item is classified under the EAR - i.e., what its ECCN would be - or whether it is subject to the EAR at all, then you can ask the Bureau of Export Administration to advise you; see 748.3.)
15 CFR 740, "License Exceptions" [EAR740], describes the various license exceptions that are available. One of the most important license exceptions is "TSU" (for "Technology and Software - Unrestricted"); as noted in 740.13(d), the TSU license exception can be used to export most commercial proprietary shrink-wrapped software (e.g., a word processing or accounting package). The TSU exception cannot be used to export encryption software in general, but as discussed below there are ways in which some encryption software products can be exported using the TSU exception or other license exceptions created specifically for encryption software.
However note that the EAR impose some restrictions even for items exported under the TSU license exception; for example, "mass market" software cannot be exported to Cuba, Iran, Iraq, Libya, North Korea, Sudan, and Syria (the "T7" nations accused by the U.S. of sponsoring international terrorism) under the TSU exceptions; see Supplement No. 2 to 15 CFR Part 774, "General Technology and Software Notes" [EAR774S2].
"Encryption software" is then defined by the EAR to be "[computer] programs that provide capability of encryption functions or confidentiality of information or information systems", with "encryption items" (the more general term) defined to be "encryption commodities, software, and technology that contain encryption features and are subject to the EAR". "Commodities" are physical objects ("commodity" is defined as "[any] article, material, or supply except technology and software") ,while "technology" is information ("technology" is defined as "information necessary for the 'development', 'production', or 'use' of a product").
Thus, for example, a C program implementing the DES symmetric encryption algorithm would be considered "encryption software" under the EAR, a smart card implementing DES would be considered an "encryption commodity", and a verbal or written description of how the DES algorithm works would be considered "encryption technology". This is because the DES algorithm by its nature "embodies principles, means and methods for the transformation of data in order to hide its information content" (i.e., it encrypts data), and uses a "key kept from the knowledge of others or shared only within a group" (i.e., the 56-bit DES key).
On the other hand, if a program does only general-purpose transformation of data (and in particular does not manipulate data "in order to hide its information content") and does not use "secret parameters", then presumably it would not be considered "encryption software" in the context of the EAR. Thus, for example, a C program that translates generic binary data to base-64 encoded format or vice versa, for example in the context of processing email message attachments, presumably would not be considered encryption software, because the transformation in question does not use any sort of secret parameters but simply translates information from one public format to another without hiding its content (to anyone familar with the respective formats). Similarly a verbal or written description of base-64 encoding and decoding would not be considered "encryption technology" in the context of the EAR.
There are two special cases with regard to the EAR definitions and whether a particular piece of software is considered encryption software or not. The first is the case of programs which do not implement encryption functions in their own code, but which provide an application programming interface (API) by which others may add encryption capabilities, e.g., by calling an external library. (This is sometimes referred to as "crypto with a hole", although a better term would be "a hole for crypto".) As discussed below, programs using such APIs are considered to be "encryption software" in the context of the EAR (i.e., when deciding whether export licenses are required or not). The justification is presumably that such APIs are specifically intended to enable "the transformation of data in order to hide its information content", especially when they incorporate the use of "secret parameter[s]" of some sort.
The second special case is that of software (or technology, or physical hardware) that implements "cryptography" in the sense of "transformation of data in order to ... prevent its undetected modification or prevent its unauthorized use" but does not perform "transformation of data in order to hide its information content", in other words, software that implements authentication and data integrity protection using cryptographic techniques (e.g., digital signatures), but does not use encryption to provide data confidentiality. As discussed below, it is at least in principle possible for such software not to be classified as an "encryption item" in the context of the EAR.
Similarly, the EAR place no restrictions on the export or reexport of information relating to general-purpose open source software, including design and architecture information, detailed documentation, instructions on building and modifying the software, and so on; such information can be disseminated to anyone in the world in any form. Finally, the EAR place no restrictions on activities that U.S. persons may engage in relating to general open source software: they may travel outside the U.S. to consult on such software, may provide training on such software to non-U.S. persons in the U.S., may support non-U.S. open source developers by contributions of money, and so on.
However the EAR state that "encryption items" do not in general qualify for "publicly available" status, and thus are in general subject to regulation by the EAR. In particular, 734.3(b)(3), the clause exempting publicly available software from EAR regulation, excludes "software controlled for EI [Encryption Item] reasons under ECCN 5D002 on the Commerce Control List"; as we discuss below, open source encryption software falls under this CCL classification. 734.7(c) repeats this more restrictive treatment of encryption software: "note that encryption software controlled under ECCN 5D002 for EI reasons on the Commerce Control List ... remains subject to the EAR even when publicly available."
The only general relaxation of the EAR's special treatment of encryption items is that publication of encryption source code in printed books is specifically called out as not subject to the EAR; however this is only reasonable given that print material enjoys special First Amendment protections. However the note to 734.3(b)(2) and 734.3(b)(3) specifies that "notwithstanding §734.3(b)(2) [which exempts printed material from regulation], encryption source code in electronic form or media (e.g., computer diskette or CD ROM) remains subject to the EAR".
The language of the entry for 5D002 repeats and enlarges upon two key points I've previously discussed: First, the EAR claims that encryption software is regulated for its "functional capacity" and not because of any "information value" it has; this in effect denies that encryption software can be considered in the same category as verbal and written material protected by the First Amendment. The same note goes on to specify that encryption software is considered to have the same status under the EAR as "a commodity included in 5A002", i.e., a hardware encryption module; in other words, encryption functionality is regulated in the same manner whether implemented in hardware or software. Second, the note following specifies that "[encryption] software controlled for EI reasons under this entry remains subject to the EAR even when made publicly available", unlike other publicly available software which is explicitly exempted from regulation under the EAR. This repeats similar language in 743.7(c).
The language of the entries for 5D002 and 5A002 also apply to two of the issues previously discussed, namely the treatment of programs using encryption APIs but not having any actual encryption code, and the treatment of programs implementing cryptographic techniques but not for the purpose of encrypting arbirtrary data. First, according to paragraph 5D002.a, among the items controlled under ECCN 5D002 is "'Software' specially designed or modified for the 'development', 'production' or 'use' of equipment or 'software' controlled by 5A002, 5B002 or 5D002." A software library implementing encryption is an example of "software" controlled by 5D002 (based on paragraphs 5D002.b and 5D002.c), so presumably a program which is "specially designed or modified" for the "use" of such a library, i.e., by having code to call encryption-related APIs, is also controlled under 5D002 by virtue of paragraph 5D002.a, even if the software contains no actual encryption code itself.
For example, the PKCS#11 API [PKCS11] (defined by RSA Security, Inc. [RSASec]) is designed to enable programs to call encryption routines located in a separate library; such an external library implementing encryption functionality would be considered "encryption software" in the context of the EAR. A program incorporating code to call a PKCS#11-compliant external library would be considered "specially designed or modified" for the "use" of "encryption software", and thus itself would be considered "encryption software" in the context of the EAR, even if the program itself did not implement any encryption functionality. On the other hand, if a program called routines through APIs that were general-purpose in nature and not specifically associated with encryption, then presumably the program would not be considered "encryption software" in the context of the EAR, even if some of the external libraries it was capable of calling happened to implement encryption functionality.
Second, paragraph 5A002.a.1 specifies that equipment that is "[d]esigned or modified to use 'cryptography' employing digital techniques to ensure 'information security'" is controlled under 5A002. However earlier language in the entry under "Related Controls" exempts a number of classes of equipment from control, and in particular paragraph (h) under "Related Controls" exempts "[data] authentication equipment that calculates a Message Authentication Code (MAC) or similar result to ensure no alteration of text has taken place, or to authenticate users, but does not allow for encryption of data, text or other media other than that needed for the authentication." In other words, equipment is not controlled under 5A002 if it uses cryptographic techniques like encryption and digital signing solely to provide authentication and data integrity functions. Turning to ECCN 5D0002, under "Related Controls" in that entry the EAR states that "This entry does not control ... 'software' providing any of the functions of equipment excluded from control under 5A002." Thus if equipment providing only data integrity and authentication functions is not controlled under 5A002 as encryption hardware, then presumably software providing only those same functions is not controlled under 5D002 as encryption software.
As stated in the entry for 5D002 under "License Exceptions", there are no applicable license exceptions that may be used for encryption software in general; however the immediately previous note (under "License Requirements") states that "After a technical review, certain encryption software may be released from EI controls and made eligible for the General Software Note treatment as well as other provisions of the EAR applicable to software." The note goes on to give references to Part 742.15(b)(1) and Supplement No. 6 to Part 742, "Guidelines for Submitting a Classification Request for a Mass Market Software Product that Contains Encryption" [EAR742S6]; the "General Software Note treatment" referred to is discussed in Supplement No. 2 to Part 774, ""General Technology and Software Notes" [EAR774S2].
742.15 provides justifications for the EI Reason for Control and specifies licensing requirements for encryption items in general. 742.15(b)(1) in particular specifies a procedure by which one can apply to the Bureau of Export Administration to have an encryption software product released from EI controls, provided that the software implements encryption with a maximum key length of 56 bits. (More precisely, the product is limited to 56 bits for symmetric keys, e.g., DES keys, and 1024 bits for asymmetric keys, e.g., a 1024-bit modulus for RSA public/private key pairs.) If such "56-bit software" is considered to be "mass market" software (which would be the case for typical shrinkwrapped software intended for consumer use), then (after a technical review) BXA will likely approve it to be treated like other "mass market" software and make use of the TSU ("Technology and Software - Unrestricted") license exception discussed above. (Supplement No. 6 to Part 742 contains an exact definition of "mass market software", as well as detailed information on how to qualify for this less restrictive treatment.) This particular provision in the EAR is what allows "56-bit" versions of such software as Netscape Communicator and Microsoft Internet Explorer to be made available for unrestricted download over the Internet. (Mass market treatment and the use of the TSU license exception used to be restricted to "40-bit" versions of software; the maximum allowed key length was then later increased to 56 bits.)
"56-bit" encryption software that is not "mass market" software (for example, a complex product sold to enterprises and requiring extensive installation and integration support) is not eligible for the TSU license exception, but is eligible for a separate ENC license exception; again, this requires BXA to do a technical review of the software and approve releasing it from EI controls. For more information see 742.15(b)(1)(iii) and 740.17(a)(3).
As noted in 740.17 (which describes the ENC license exception), the ENC license exception can also be used to export encryption software in a variety of other circumstances:
There is one more license exception applicable to encryption software:
the KMI ("Key Management Infrastructure") license exception described in
740.8. The KMI license exception is available for encryption products that
implement key recovery as described in Supplement No. 4 to Part 742, "Key
Escrow or Key Recovery Products Criteria" [EAR742]. This license applies
to software implementing Clipper-style mandatory key escrow features; as
noted in paragraph (1) of Supplement No. No. 4 to Part 742, "[the] product's
cryptographic functions shall be inoperable until the key(s) or other material/information
required to decrypt ciphertext is recoverable by government officials under
proper legal authority and without the cooperation or knowledge of the
user."
Products using the KMI license exception can be exported to all countries
except the "T7" nations.
Note that all the license exceptions available for encryption software - TSU, ENC, and KMI - require that the software be distributed in binary form. After all, these license exceptions require that the key length be limited (for TSU or ENC exceptions) or that the key escrow mechanism not be disabled (for KMI exceptions), and this would not be possible at all if the software were distributed in source form.
Thus any encryption software distributed in source form, including open
source encryption software, will be classified in the CCL under ECCN 5D00,
will remain subject to EI control, and will require a license for export
to any country except Canada. Since such a license will not be granted
except under very special circumstances, this essentially means that there
is no legal way to export encryption source code from the U.S. in electronic
form. (As previously discussed, encryption source code in printed form
is not subject to the EAR and can be exported freely.)
However even this does not exhaust the restrictions imposed on encryption
source code and open source encryption software, as discussed below.