|
|
| Encryption Export Control Restrictions |
| by D.C. Toedt III, Intellectual-Property Law Facts, abridged from The Law and Business of Computer Software (07/1997) |
|
|
| When are licenses
required for encryption-technology exports? A: Almost always -- unless a License Exception applies. The Clinton Administration recently took a carrot-and-stick approach to encouraging industry cooperation with its objective of maintaining electronic surveillance capabilities for intelligence and law-enforcement agencies. The stick is that under the interim final rule, export licenses for encryption technology are now required for all destinations, except Canada. See 61 Fed. Reg. 68572-68587 (1996). This applies even to technology that is designed to use third-party encryption (e.g., the Microsoft Windows NT CryptoAPI). The technology categories affected by the interim final rule are those whose Export Control Classification Numbers (ECCNs) have an "EI" (for "encryption items") under the "Reason for Control(s)" paragraph. They include: encryption commodities controlled under ECCN
5A002 In other words, mass-market software that might otherwise be exported under License Exception TSU is not eligible for such treatment if it includes encryption capability as described in these ECCNs. Encryption software is eligible for a "tools of the trade" License Exception for temporary exports, e.g., taking it along on a business trip in a notebook computer, as long as the required conditions for that License Exception are met. The Clinton Administration recently announced a proposal
for License Exceptions for the financial industry, for certain health
and medical companies, for to on-line merchants, and for U.S. subsidiaries
for the protection of internal business operations. The BXA has indicated
that favorable treatment will be given to license requests for similar
exports to "strategic partners." What isn't encryption software? The Commerce Department's Export Administration Regulations -- in particular, the Export Control Classification Numbers or ECCNs relating to encryption technology -- specifically exclude from control certain types of technology that have encryption-like features but do not permit users to encrypt their own messages. (Caution: Such technology may still be subject to control if if fits within other ECCNs.) Examples of technology excluded from the encryption-related ECCNs include: personalized smart cards; Will strong encryption
capability exports be given licenses? The carrot in the Administration's plan is to dangle the prospect of exporting comparatively strong encryption capability before the industry. The export and reexport of 56-bit key length DES or equivalent strength encryption items is now permitted under the authority of a special License Exception - if the exporter makes satisfactory commitments to build and/or market recoverable encryption items (i.e., "back door" capability for law enforcement) and to help build the supporting international infrastructure. The purpose of the policy is to provide for a transition period for the development of this key management infrastructure. In addition, certain encryption software can be made eligible for mass-market treatment, and thus for release from the "EI" licensing requirement, after a one-time BXA review. Detailed information is set out in the Federal Register announcement of the interim final rule, cited above. The Clinton Aministration appears to be starting to grant licenses for strong encryption capability. In late June, 1997, both Microsoft and Netscape reported that they had received approval to export Web browsers with 128-bit encryption capability. [Wall Street Journal, June 25, 1997, B6, col. 5] In addition, in the summer of 1998 the Administration announced that it would relax the encryption export controls somewhat for: the financial industry, Can encryption source code
legally be distributed electronically? A sticky issue arises when source code to encryption software is proposed to be published in both printed and electronic form, e.g., on the Web or on disk. Illustration: The Zimmerman ("Pretty Good Privacy") Case In June 1991, Philip R. Zimmerman published a free public-key encryption software package known as PGP (Pretty Good Privacy). After being disseminated rapidly over bulletin board services (BBS) and the Internet, PGP became a de facto standard for encryption of E-mail. Because PGP crossed the U.S. border via the Internet, Zimmerman was made the target of a federal criminal investigation to determine whether he had violated the export control laws. The investigation was closed without indictment in January 1996. Zimmerman has since turned PGP into a commercial product. See http://www.pgp.com/. Illustration: The Bernstein Case In Bernstein, a graduate student wanted to preclude the government from prosecuting him if he taught a course to a class including foreign nationals, using as materials the source code of an encryption program he had written and some textual explanations of the code. The result was that a district court held that the licensing scheme of the International Traffic in Arms Regulations (ITAR) affecting cryptographic software was "a paradigm of standardless discretion" and therefore an unconstitutional prior restraint because it did not include sufficient procedural safeguards. The Bernstein plaintiff also wanted a preliminary injunction, however, preventing the government from prosecuting him if he posted the source code on the Web for his students to access. The court was less comfortable with this request; it denied the requested injunction without prejudice and all but expressly suggested that the parties enter into a stipulation that the plaintiff would make the Web materials inaccessible internationally. Illustration: The Karn Case In Karn another district court flatly rejected a similar challenge to the ITAR. The plaintiff had asked the State Department for a "commodity jurisdiction" determination confirming that his book on encryption technology was not subject to the department's jurisdiction under the ITAR. The State Department agreed in the case of the book, but stated that its determination did not apply to the computer disk, containing an electronic copy of source code printed in the book, that was referenced in the book and available from the author. The plaintiff then submitted a separate commodity-jurisdiction request for the source-code disk. The State Department responded that the disk was a "defense article" and therefore was subject to the department's ITAR jurisdiction, even though the book containing a printed copy of the same source code was not. The Karn plaintiff filed suit challenging the State Department's action under the Administrative Procedure Act (APA) as well as on constitutional grounds. The court granted the defendants' motion to dismiss, characterizing the dispute as relating to a "political question" that must be resolved by the legislative and executive branches. The Karn decision reportedly was the subject of "general dismay" among the academic community; the Bernstein court later quoted a quip repeated in a report on national cryptography policy prepared by the National Research Council ("NRC") at the request of the Defense Department: "'They think terrorists can't type?'" The "printed versus electronic copies" issue survives even though much encryption software has been transferred to the Commerce Control List and thus is no longer subject to State Department jurisdiction under the ITAR. The Administration has taken the position that while a printed book or other printed material setting forth encryption source code is not itself subject to the Export Regulations, nevertheless encryption source code in electronic form or media (e.g., computer diskette or CD ROM) remains subject to the Regulations. At this writing, the Clinton Administration continues
to review whether and to what extent scannable encryption source or object
code in printed form should be subject to the Export Regulations. It has
stated that it "reserves the option to impose export controls on
such software for national security and foreign policy reasons." Has Congress taken a position
on encryption export policy? The subject of export controls on encryption technology has been highly controversial. In recent months considerable jockeying has been going on between Congress and the Clinton Administration about the scope of restrictions on encryption exports. At least equally controversial has been a debate whether companies distributing encryption capability should be required to provide government agencies with the ability to "wiretap" encrypted communications through "back doors." The Clinton Administration Goal: Surveillance Capability In recent months, over vociferous opposition from some industry segment, the Clinton Administration has been moving toward implementing a system in which encryption-technology vendors would build in "backdoor" capabilities to permit government interception and monitoring of encrypted materials. On October 1, 1996, the Clinton Administration announced a plan envisioning a worldwide key management infrastructure, with the use of key escrow and key recovery encryption software. On November 15, the President directed that all encryption items controlled on the U.S. Munitions List (except those specifically designed, developed, configured, adapted, or modified for military applications) be transferred to the Commerce Control List. On December 30, 1996, the BXA published the interim final rule as an amendment to the Export Regulations. By and large, the U.S. software industry was quite unhappy with this turn of events. It was said that U.S. software and hardware companies would be at a decided competitive disadvantage with foreign companies, who are free to sell much more powerful encryption technology in foreign markets than are American firms. It was also noted that foreign customers might be reluctant to buy American encryption technology that could be "cracked" by the U.S. Government, and that the lack of secure, encrypted communications capability could be a threat to dissenters in countries with repressive governments. The SAFE Act Bill On February 12, 1997, Rep. Bob Goodlatte (R-Va.) and 54 co-sponsors introduced the Security And Freedom through Encryption [SAFE] Act of 1997, H.R. 695. The SAFE Act would allow the unencumbered export of generally available software and hardware if a product with comparable security features is commercially available from foreign suppliers. Despite opposition from the Clinton Administration and some members of Congress, the SAFE Act bill was approved (as amended) by the House Judiciary Committee on May 14, 1997. The current status of the bill can be found at http://thomas.loc.gov/. The ECPA and PRO-CODE Bills Two encryption-related Senate bills were introduced on February 27, 1997: The Encrypted Communications Privacy Act [ECPA, S. 376] and the Promotion of Commerce On-Line in the Digital Era [PRO-CODE, S. 377]. These Senate bills would bar government-mandated key recovery, or key escrow encryption, and permit computer users to choose any encryption method to protect the privacy of their online communications and computer files. The bills would also roll back existing restrictions on the export of strong cryptography. The current status of both bills can be found at http://thomas.loc.gov/. What about domestic restrictions
on encryption technology? Editorial comment: Anyone who wanted to use unmonitorable encryption could easily get suitable software, albeit illegally, from overseas Web sites. In other words, law enforcement officials could be confident only of their ability to monitor law-abiding citizens' encrypted communications. On the other hand, a suspected terrorist's use of unmonitorable encryption would itself be a basis for prosecution. That might be the real motivation for the FBI bill. |
|
|