Archive for the ‘Encryption’ Category

Statement Before House Committees Concerning Proposed Export Licensing for Cyber-Security Items

Wednesday, February 3rd, 2016 by Danielle McClellan

(Source: Homeland Security Committee) Author: Kevin J. Wolf, Assistant Secretary of Commerce for Export Administration.

Transcript of statement:

“Thank you, Chairmen Hurd and Ratcliffe, and Ranking Members Kelly and Richmond.

The Wassenaar Arrangement is a 41-member export control group in which the United States participates. It was established to contribute to regional and international security and stability by promoting greater responsibility in the transfer of conventional arms and dual-use goods and technologies, thus preventing destabilizing accumulations of such items. Participating States maintain a common control list of items warranting control for these reasons and seek, through their national policies, to ensure that transfers of these items do not contribute to the development or enhancement of military capabilities that undermine these goals, and are not diverted to support such capabilities. The list of such items is developed and updated by the Participating States through consensus determinations, generally made at the end of each year. …

In December 2013, Wassenaar approved new export controls on “command and delivery platforms” for “intrusion software” and related technology. Specifically, the entries in Category 4 (Computers) of the Wassenaar dual-use control list would control non-publicly available software (4.D.4.) that generates, operates, delivers, or communicates with “intrusion software.” “Intrusion software” is defined as software designed to covertly gain access to a computer or other networked device and, once inside, to extract or modify data or modify the execution path of the device to allow the execution of externally provided instructions. Related hardware and technology entries (4.A.5. and 4.E.1.c.) control systems and equipment for generating, operating, delivering, or communication with “intrusion software,” and technology for developing “intrusion software.” The original proposal for these controls came from another Wassenaar member nation in 2012. Examples of the types of commercial hacking software intended to be captured by this control include those offered by Hacking Team (Italy), Gamma/Fin-Fisher (Germany), and Vupen (France).

The controls were novel in that they were the first foray by a multilateral export control community into the area of offensive cyber tools. The agreed-upon entries covering software intentionally excluded “intrusion software” itself — that is, certain kinds of malware — from control because of a general understanding that everyone with a computer or mobile device infected by such malware or “exploits” could become an unwitting “exporter” of it (e.g., by forwarding an infected e-mail to someone in another country). The technology entry, however, imposes controls on non-publicly available technology for the development of such software as well as on technology for the development of the controlled delivery systems. …

In order to not take an action that would inadvertently harm our nation’s ability to engage in critical cyber defense and related research work, we decided in May 2015 to take the unprecedented step of publishing these Wassenaar control list entries as a proposed rule, with a request for private sector comments, rather than as a final rule. Our hope was that the private sector comments would give us a better sense for whether the rule would have unintended impacts on our cyber defense and cyber research ecosystems. All dual-use controls have consequences and impose costs on the private sector. That is the nature of controls. This one, however, was different because the impact would be not just on the economic bottom-line of U.S. companies, but on our government’s and our nation’s ability to share efficiently and quickly the types of technology necessary to conduct cyber defense and related research.

Immediately following publication of the proposed rule, Commerce received questions from U.S. private sector and others in the U.S. Government about the intended scope of the controls. In order to ensure that comments were informed and responsive to the proposed controls set forth in the rule, Commerce published answers to a list of “frequently asked questions” on its website to address what we determined were regular queries in order to encourage more focused and more useful public comments. It was clear from these initial questions that the terminology used in the control list entries and the proposed rule were understood differently by the cybersecurity community than by the export control agencies and the Wassenaar Participating States. By the end of the 60-day comment period, Commerce had received more than 260 comments, virtually all of them negative. Some commenters took the view that the underlying control at Wassenaar could not be implemented without causing significant harms to cybersecurity. Others made specific recommendations on ways to mitigate many of the concerns. Some praised the underlying objectives of the rule, while nonetheless proposing modifications to the scope of the proposed regulation, such as through license exceptions and definitions, to reduce the impact of unintended consequences. …

Neither the Commerce Department nor the Administration has reached a conclusion about how to respond to the public comments. We are still reviewing and considering them. Importantly, all U.S. Government agencies with expertise and equities in cyber defense research and related work are reviewing the comments and will provide input as a next step, before we make a decision on what to do about the proposed rule.   As requested by your committees, I can, however, summarize the essence of the comments – reiterating that the Administration has not come to any final conclusions regarding how to respond to the comments or to the extent to which they are correct technically. The public comments, including presentations at technical advisory committee meetings during the past three months, focus on three main issues.

First, some commenters asserted that the proposed regulation’s definition of “intrusion software” is too broad and, as a technical matter, fails. They assert that malware recovery tools would be caught by the entries because they interact with malware to regain control of an infected system, and some defense research tools would be caught because they analyze malware to develop new defensive products. They also assert that products that patch systems or add capabilities to programs would themselves be controlled under these entries because of the way they interact with or manipulate programs. These products are integrated with the hardware (systems, equipment, and components) and are designed to legitimately bypass or defeat protections, modify the standard execution path of software, and access data. According to the commenters, they would often thus be software for the generation, operation, delivery of or communication with “intrusion software” and caught by the new controls.

Second, other commenters contend that the proposed rule to implement the control list entries as written, based on the definition of “intrusion software,” would impose a heavy and unnecessary licensing burden on legitimate transactions that contribute to cyber security. Government agencies and private sector cyber security companies routinely test their systems and networks to identify vulnerabilities and, if possible, discover existing malicious attack agents. These companies then provide their clients with threat mitigation tools and strategies. To accomplish this, they use the same tools the controls on intrusion items identify, though their use is authorized by their target. To accomplish their mission, they need to employ tools for computers or networks that have the functional specifications of the control parameters, e.g., avoid detection, defeat protective countermeasures, extract data or information, modify system or user data, and modify the standard execution part of a program or process to execute externally provided instructions. These are exactly the characteristics a successful malicious attacker’s software would have and what the assessment team’s tools need to be able to replicate. During these defensive engagements, members of the assessment team frequently need to create custom scripts (i.e., software programs) to effectively assess the extent of the vulnerabilities by creating exploits, and to determine if a successful attack has taken place or is in progress.

Third, other commenters state that the proposed rule’s controls on technology for the development of “intrusion software” could cripple legitimate cybersecurity research. To address cyber threats, technical information must be shared with experts across the globe. In order to identify and quickly counter threats, the cybersecurity industry relies heavily on collaboration with other companies within and outside of the United States, as well as independent experts around the world. Many of these experts are self-taught, have no prior formal relationship with cybersecurity firms, and, in many cases, may be unknown until they discover a new vulnerability. To address vulnerability, a company must be able to engage in a back-and-forth dialogue with these researchers and experts. Often, the dialogue must include detailed discussion of exactly how a particular vulnerability could be exploited to gain control of a computer; without such discussion it is not possible to evaluate the risk posed by a vulnerability or to fashion an effective and comprehensive defense. Some commenters were concerned that, by subjecting vulnerability research, assessments, and testing to export licensing requirements including classification, screening, and other control elements, the control would limit the ability to fix and patch such vulnerabilities, leading to an overall decrease in the quality of cybersecurity. When vulnerabilities are discovered, they must be reported as soon as possible so that a fix can be developed. This process involves sharing not only the vulnerability and exploit, but also the technical information on how the exploits work, including the technology to develop them.

The commenters had many suggestions regarding how to address their concerns. The Administration will be reviewing all of them and many other ideas for how to address the policy objectives of the control but without unintended collateral harms. As I have said many times in response to questions about the rule, the only thing that is certain about the next step is that we will not be implementing as final the rule that was proposed. In working through this process, we will continue to seek input from those with expertise and equities in cyber security in both the U.S. government and the private sector before deciding in conjunction with its interagency partners what the next step should be. I thus welcome the Subcommittees’ inputs and am prepared to answer any questions you may have.”

BIS Imposes $750,000 Fine on Intel Sub Wind River Inc. for Violations of Encryption Export Rules—Really?

Monday, November 24th, 2014 by Brooke Driver

By: Felice Laird

I must admit to a shudder of excitement and disbelief when I visited the BIS homepage recently and noticed a banner ad announcing a fine against an “Intel subsidiary for violations of encryption export regulations.”  I am one of the original crypto export geeks, having followed the tortured evolution of the controls from the late 1990’s through the creation and mutations of License Exception ENC, to today’s largely self-policing paradigm.  And I had never heard of a company being investigated or fined for violations in connection with an encryption export–until now.  And so, I wonder, why this, why now?

First, let me give the standard disclaimer;  I have no knowledge of this case other than what I have read in the documents released by BIS, namely, the Press Release, the Proposed Charging Letter, the Settlement Agreement and the Order.  These documents were prepared and issued by BIS, and they reflect only Commerce’s side of the story.  In fact, BIS has ordered the companies involved not to say anything publicly about the case, especially not to deny any of the charges, so we will never get the other side of the story.  The documents give clues as to what the violations were, when they occurred, how the Department found out about them and what the specific punishment is.  What is not clear is why, for the first time in 15 years, BIS came out with a public and painful punishment of a large U.S. company for encryption software exports.

For the export compliance professional, there are several really important things to note when reading the documents.  Here are some of them:

  • Wind River Systems is a subsidiary of Intel that was formed after Intel bought Wind River’s assets (and liabilities!) in 2009.  So, the important take away is that there is “successor liability,” and the government will go after a company for an acquisition’s export violations.  So, ask to be at the table in M&A talks.
  • The statute of limitations for the early violations had run out, but BIS made the company waive the statute somewhere along the line, so that the violations count.
  • The company submitted a Voluntary Self Disclosure that up until now (when done in connection with an encryption violation) usually leads to a nasty gram from BIS but no fines.
  • BIS issued a gag order in the Settlement Agreement prohibiting Wind River from saying anything about the case.
  • The Settlement agreement states that Wind River has to pay up in 30 days, or else they won’t be allowed to use any licenses or exceptions.

From my perspective, enforcement actions are useful training tools.  It is always a “better sell” when I am talking to companies about the risks involved in non-compliance when I have a good enforcement case to present as an example.  And indeed, I have had more than one awkward moment when talking with tech executives and developers who ask me to come up with evidence that the encryption controls are worth compliance measures.  Sometimes, I have to appeal to their patriotism as a last resort.  It is good to know that BIS cares enough about encryption export controls to go after non-compliant companies.

Lately though, I have been seriously questioning the rationale for maintaining export controls on commercial products that use encryption, since the disclosures made regarding NSA surveillance by Edward Snowden last year.  If NSA can intercept and decipher 99 percent of data transmissions, how can the USG continue to maintain that the encryption regs are necessary to support the intelligence community?

The better answer is that Category 5 Part II is synced in most respects to the Wassenaar list and the U.S. is obligated to maintain controls to honor commitments made to the Wassenaar member states.  And it is clear that efforts have been made by at least three of the most powerful delegations (U.S., France and the UK) to shore up controls on “cyber security” products, as they actively considered this at the December 2013 Plenary. (BIS deferred publication of CCL changes, affecting “cyber security” products, agreed to at the December 2013 plenary – indicating that these would be published in September, which has come and gone with no reg in sight.)

So, Wassenaar member states have had controls on encryption too.  But no country has a byzantine regulatory scheme comparable to that maintained by the U.S.  Over the years, License Exception ENC has morphed into a virtually inexplicable licensing loophole.  And so we wonder–should companies really have to continue funneling information to BIS and NSA by way of Classification Requests and Classification reports?  Does NSA really use any of the information?  Does anyone actually read the self-classification reports? ENC shipping reports?

In the few cases over the years that someone from NSA has shown up in daylight to an industry meeting, I always ask the question and get the answer that, yes, the information it gleans from the classification requests and reporting process is still necessary.  I must admit, I have never really bought that story, but that remains part of the answer to the why question.

That brings us back to the timing issue.  The press has widely reported the steps that the information technology industry has been taking to harden products and networks using cryptography and other security technologies to protect customer information from access by government agents.  Perhaps the Wind River case was meant to be a reminder to the industry that the U.S. Government still has the power to regulate which technologies are deployed internationally.

Wassenaar Arrangement Modifies Controls on Electronic Surveillance Tools

Thursday, January 30th, 2014 by Brooke Driver

By: Brooke Driver

At its annual plenary meeting in Austria December 3-4, 2013, the Wassenaar Arrangement, a group of 41 countries including the U.S., Russia, the U.K. and most E.U. states, focused on export controls for conventional arms and dual-use goods and technology, agreed on new harsher export controls on cybersecurity technologies, recognizing their great potential for terrorism. Each participating country must now implement these changed policies, one major area of which is surveillance and intelligence gathering tools, including malware and rootkits, which governments can use to bypass security features on electronic devices in order to attain supposedly protected data. Internet protocol network surveillance systems or equipment are also now subject to revised export controls, which include technologies used to screen for malware, viruses and surveillance programs. These technologies are subject to new controls, because representatives of the 41 countries believed that they could be used to both block cyber attacks and grant foreign persons dangerous insight into Western screening systems, increasing the potential for hacks. The agreement also places stricter controls on intelligence gathering technologies that analyze individuals’ or groups’ relational networks and activities, although there will be exceptions for companies using such software for marketing or consumer-monitoring purposes.

Click here for details of these changes and others decided upon at this year’s Wassenaar plenary meeting: http://www.wassenaar.org/controllists/2013/Summary%20of%20Changes%20to%20Control%20Lists%202013.pdf

What the New Encryption Rules Mean For U.S. Exporters

Tuesday, July 20th, 2010 by admin

This article originally appeared in a slightly different form in International Trade Law360, July 1, 2010.  Reprinted with permission of Pillsbury Winthrop Shaw Pittman LLP.

by Sanjay Jose Mullick

The Obama administration has taken the first step in export control reform by easing the pathway for U.S. companies to export certain encryption items.

The First Export Control Reform

On June 25, the U.S. Department of Commerce’s Bureau of Industry and Security issued new regulations governing export controls on encryption. This rulemaking represents the first formal example of the president’s initiative to reform U.S. export controls by concentrating regulation on the most sensitive items.

The new regulations reflect a recognition that encryption is ubiquitous in today’s high-tech world and cannot be completely regulated. These rules also attempt to address the need for U.S. companies to be able to get to market quickly, to foster the competitiveness of U.S. industry. However, they do not accomplish a complete de-control of encryption, and the prior system will remain in place for many products.

Although the regulations have been published as an interim final rule with a request for comments, they likely reflect the prevailing framework for regulating encryption exports going forward. Let’s take a look at some of the key elements of the new rules and how they will impact exporters. (more…)

BIS Ruling on Encryption Software

Friday, September 11th, 2009 by Danielle McClellan

BIS recently published an advisory opinion on downloads of encrypted “mass market” software. An undisclosed recipient asked BIS “whether a company would be in violation of the EAR if it allowed certain encrypted software, reviewed and classified by BIS as “mass market,” to be downloaded free of charge to anyone from the company’s website without restriction.” BIS responded by explaining that simply “publishing “mass market” encryption software to the internet where it may be downloaded by anyone NEITHER established “knowledge” of a prohibited export or reexport nor triggers any “red flags” necessitating the affirmative duty to inquire under “Know Your Customer” guidance provided in the EAR.” (more…)

Commerce Relaxes EAR to Be More Like the ITAR

Wednesday, December 12th, 2007 by Danielle McClellan

It used to be that the International Traffic in Arms Regulations allowed a US citizen employee of a US exporter to carry export-license-required-technical data (technology) out of the country on his/her laptop while the EAR did not allow the same thing to happened. That has now changed.In the December 12, 2007 Federal Register, the Bureau of Industry and Security, Commerce has revised the Export Administration Regulations (EAR) to expand the export license exceptions Temporary Imports, Exports, and Reexports (TMP) and Baggage (BAG) to allow for certain exports and reexports of technology between two U.S. persons or their employees traveling or those that are temporarily assigned abroad.

The rule expands the availability of License Exceptions TMP and BAG but does not authorize any new release of technology. Any technology exported under the new rule may only be released to persons who may receive that same technology pursuant to other provisions of the EAR which means it will still be subject to restrictions applicable to technology exports and reexports. (more…)

Minute by Minute Report from Commerce Update Conference 2006

Tuesday, October 17th, 2006 by Scott Gearity

Editor’s Note:

If you didn’t make it to Update 2006, it turns out that the only thing you missed was the posh reception including sushi, crab cakes, and free drinks. You get all of the substance of the presentations here because Scott Gearity wrote a live report from the Commerce Department’s annual Update conference on October 16-17, 2006. Note the time stamp at the beginning of each point below.
–John Black

(more…)

BIS Spring Cleaning

Friday, April 29th, 2005 by Scott Gearity

April 29 saw the publication of a sort of spring cleaning regulation from BIS in the form of updated contacts and minor administrative corrections.  Think of it as the bureaucratic equivalent of a good scrubbing and a new coat of paint.

Among the office number changes and snappy turns of a phrase like “this rule corrects a citation error in Sec. 762.1(a)(4) by revising the reference to Sec. 734.2(b)(7) to read Sec.  736.2(b)(7),” there is a mention of the office Commerce continues to insist on calling the “ENC Encryption Request Coordinator.” Elsewhere in the rule BIS refers to this mysterious place as “that organization.”

Now, you know, I know, and the American people know that the National Security Agency exists.  It’s not a secret any more.  They have a website.  Nor is it classified that NSA plays a vital role in formulating US export controls on encryption.  Former BIS undersecretary Bill Reinsch noted it all the way back in 1998.  Brian Nilsson mentioned discussions with NSA at a Regulations and Procedures Technical Advisory Committee (RPTAC) meeting in 2001.  Peter Lichtenbaum thanked Norm Lacroix for working with them just last year.  In December, BIS even spilled the beans by pointing out in the last encryption reg that the ENC Encryption Request Coordinator has a @nsa.gov email address.  So what’s with the pseudonym?

Not mentioned by BIS is that NSA is no longer accepting documents via fax.  Their old number (301) 688-8183 is no longer in service and no one seems to be distributing the new one.

Guide to New US Encryption Export Regulations

Thursday, June 27th, 2002 by Guest Author

(Editor’s Note:  Even companies who do not manufacture encryption products may find themselves exporting software or hardware that employs encryption.  Special thanks to Felice, a leading expert on crypto controls, for her clear overview of the new crypto rules. )

INTRODUCTION

US rules on the export of encryption technology have been changing on the average of every 8 months, beginning in December of 1996. The only constant has been that the rules have been overwhelmingly confusing and ambiguous. The latest go-round of changes happed on June 6, 2002.  (Please note that the export regulations governing the export of encryption technology consist of general rules and myriad exceptions to these rules. Therefore, the following should be viewed as an overview and your particular situation should be analyzed with reference to the actual regulation. Such exotica as source code, beta-test software, open cryptographic application programming interfaces, etc, are beyond the scope of this article.

LEGAL AUTHORITY

The US has the legal authority to control the export of encryption technology under the Export Administration Act . The regulations that implement this law are called the Export Administration Regulations (“EAR”). You can view the regs on-line at http://www.bis.doc.gov. If you are primarily interested in crypto exports you will want to look at section 740.17. This section will reference other sections, but the bulk of the specific rules regarding encryption will be here.

PLAYERS

The Bureau of Export Administration (BIS) is the primary agency you need to deal with if you want to get export approval for your encryption products. However, the National Security Agency is heavily involved in the process, so you will often need to deal with them.

CLASSIFYING YOUR ENCRYPTION PRODUCTS

ECCNs 5A992, 5D992 and 5E992

Certain products that use encryption technology for limited functions fall under 5A992 (hardware) or 5D992 (software). These products are generally of the following nature:

–Authentication

–Access Control Systems

–Digital Signature

–Some Smart Cards

–Some cell phones and components

Other products also fall within these two ECCNs namely:

–Products that use 56-bit DES or comparable algorithm and key exchange under 512

–Products that use 64-bit symmetric algorithms for data confidentiality and are “mass market”

–Products that use symmetric algorithms of any key length for data confidentiality and are “mass-market.”

ECCNs 5A002, 5B002, 5D002

If your product uses encryption and is not covered by the above-mentioned categories, then it is likely caught by 5A002 (hardware), 5B002 (test and production equipment) and 5D002 (software). Technology to make items covered by 5A002, 5B002 or 5D002 is covered by 5E002. Products covered by these ECCNs may be exported in many cases using License Exception ENC. Exports not allowed under ENC need an individual license or Encryption Licensing Arrangement.

EXPORTING ITEMS CLASSIFIED AS 5A992, 5D992 or 5E992

If you make a product that uses encryption (regardless of key length) for limited functions like user authentication, access control, digital signature, or banking you can “self-classify” and ship under No License Required (NLR.)

For products using symmetric algorithms with 64-bit key lengths or less or asymmetric algorithms of 512 bits or less, a simple notification to BIS and NSA is all that is needed to be able to ship under NLR.

If you think you qualify for the exemption for strong crypto “mass market” products, you must file a “review request” to see if BIS agrees with you. The definition of mass market is taken from the Cryptography Note of the regulations:

a. Generally available to the public by being sold, without restriction, from stock at retail selling points by means of any of the following:

1. Over-the-counter transactions;

2. Mail order transactions;

3. Electronic transactions; or

4. Telephone call transactions;

b. The cryptographic functionality cannot be easily changed by the user; and

c. Designed for installation by the user without further substantial support by the supplier.

BIS and NSA have stated that they are going to be “strict” when considering requests to classify strong encryption products as “mass market.” Specifically, they want proof that the product is sold in a computer store like CompUSA.

For all software, hardware and technology controlled by 5A992, 5D992 and 5E992 you can export to all countries except the terrorist countries, to all end-users except the bad guys under NLR and no reporting is required.

EXPORTING ITEMS CLASSIFIED AS 5A002, 5B002, 5D002 and 5E002

License Exception ENC is the authority that allows you to export most encryption products covered by ECCNs 5A002, 5B002, 5D002 and 5E002. However, before you can use this license exception, you usually need to submit a Commodity Classification request to the BIS/NSA. (If your shipments are confined to subsidiaries of US companies you don’t have to go through this step.) You also have to keep records of who you ship to because you need to report to BIS and NSA who you ship to every six months.  You can export products to any end-user under ENC in the following countries immediately upon filing a Commodity Classification Request.

Austria, Australia, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Spain, Sweden, Switzerland, United Kingdom

If your product uses strong encryption but you want to sell outside these countries, you need to wait 30 days before shipping and you cannot ship to “government end-users” unless your product qualifies as a “retail” product. If it qualifies as a “retail product” it can go to any end-user in any country other than the bad countries under ENC. If it is not a “retail product” it can only go to non-government end-users under ENC. You will be informed when your Commodity Classification is complete if your product qualifies as retail.

Retail vs. Non-Retail

The concept of “retail” is similar to the concept of “mass-market” discussed previously. “Retail” products generally available to the public by being

(1) sold through retail outlets,

(2) specially designed for individual consumer use, OR

(3) which are or will be sold in large volume without restrictions through mail order, electronic or telephone sales.

However, these “retail” products CANNOT:

(a) allow the cryptographic functionality to be easily changed by the user,

(b) require substantial support to install and use

(c) be modified or customized for the customer and

(d) be designed to be used as network infrastructure products.

Examples of “retail” products are general purpose operating systems that don’t qualify as “mass-market”, chips designed for retail products, low end routers, firewalls and VPNs designed for the SOHO market, desktop applications that do not qualify as “mass-market”, low end servers and application specific servers, network and security management products designed for low end computers and products which contain short range wireless encryption software/components.

RECORDKEEPING

You need to keep records of whom you provide encryption products (i.e., controlled under ECCNs 5A002, 5B002, 5D002 or 5E002) to under license exception ENC. The reason why you need to do this is because you will need to send a report to the Bureau Industry and Security and the National Security Agency twice a year. (See Reporting section below.)

REPORTING

You are required to send in reports to the BIS and the NSA that contains information on who you ship to, and what kind of technical review the product has undergone. This is only necessary for products that are shipped under license exception ENC. Reports are required for shipments under ENC, EXCEPT in the following instances:

1. You are shipping to a subsidiary of a U.S. company

2. You are shipping to a US bank or financial institution or anyone that does business with them.

3. You are shipping weak crypto products (e.g., under 64-bits).

4. You are shipping a “retail” product to an individual consumer.

5. You are making the software available via free or anonymous download.

6. You are shipping single processor computers, laptops and hand-held devices that are pre-loaded or bundled with encryption software.

The reports are due according to the following schedule:

–For shipments made between January 1st and June 30th, the report is due on August 1st.

–For shipments made between July 1st and December 31st, the report is due on February 1st.

You need to prepare the report in an electronic format and send via e-mail or load onto disk and send to the mailing addresses below:

e-mail addresses:

crypt@bis.doc.gov

enc@ncsc.mil

OR

mailing addresses:

Bureau of Industry and Security

US Department of Commerce

Office of Strategic Trade and Foreign Policy Controls

14th Street and Pennsylvania Avenues

Room 2705

Washington, D.C. 20230

Attn: Encryption Reports

ENC Encryption Request Coordinator

9800 Savage Road

Suite 6131

Ft. Meade, MD 20755-6000

The report should identify:

–Company name and address,

–Contact person and contact information,

–Reporting period

–And for each product the report should include:

–Product name and license or CCATS number for the product

–Ship-to-parties name and addresses, and the quantities and dates of shipment for each

by Felice Laird, Export Strategies