Introduction
What does interim final rule mean for exporting community?
What's the catch?
What's new about State Department solution?
Are there hidden gems in the rule's preamble?
Is the rule open to comments?
Is the rule in effect now?
Comparison of ITAR and EAR
End-to-end encryption


Introduction

The State Department has finally brought the International Traffic in Arms Regulations (ITAR) into the 21st century by releasing an interim final rule adopting the cloud computing encryption standards that the Commerce Department adopted in 2015.

The good news is that, for the most part, the State Department resisted the temptation to do something different in the ITAR, so the joint Commerce-State solution works (see the table below for a side-by-side comparison of the two solutions).

What does interim final rule mean for exporting community?

Companies that held off transitioning data to cloud service providers or implementing the encryption standards adopted by the Commerce Department in 2015 on their network systems because their servers contained ITAR-controlled defence technology in addition to Commerce Department-controlled dual-use technology can now proceed to use the Cloud for both ITAR and Export Administration Regulation (EAR)-controlled technology without ensuring that all of the cloud servers are located in the United States.

What's the catch?

There are two major catches.

First, the requirements that are now in both the Commerce Department and State Department regulations must be met. Specifically:

  • technology cannot include any classified information;
  • encryption must be truly end-to-end (see below);
  • the cloud provider must use cryptographic modules (hardware or software) which are compliant with the Federal Information Processing Standards (FIPS) Publication 140-2 or other compliant encryption; and
  • the cloud provider's servers cannot be in the ITAR proscribed 126.1 countries (Commerce Department's Country Group D:5) or Russia.

Second, while this regulation (and the pre-existing Commerce Department regulations) jointly address nearly all US export-controlled technology (minus Department of Energy-controlled technology), it does not cover non-US export-controlled technology. If, for example, defence technology is developed and housed in the European Union, the European Union must catch up before this can be implemented as a global solution. However, in an encouraging sign, the State Department states in the preamble to the rule that the US government is in talks with allies regarding making these global standards. In the meantime, it may be possible in some jurisdictions to use the US solution in conjunction with licences in other countries where the company has data, subject to local export control restrictions.

What's new about State Department solution?

There are numerous nuances that are unlikely to have a significant impact, except perhaps down the road in an enforcement context.

Encryption strength
The State Department has said that if an encryption is not FIPS 140-2, it must provide security strength that is at least comparable to the minimum 128 bits of security strength achieved by the advanced encryption standard (AES-128). The Commerce Department said that encryption had to be FIPS 140-2 or "other equally or more effective cryptographic means". By establishing a clear industry standard, the State Department has made life easier for exporters and cloud providers, although most exporters will likely insist on FIPS 140-2.

Section 126.1 countries
The State Department slightly changed the prohibition on ITAR-proscribed countries. According to the department, it is not enough that technology is not intentionally stored in a Section 126.1 country or Russia; it also cannot intentionally be sent to a person in one of those countries. This may make little difference in practice: if an encrypted technical email is sent to an end-user in Russia, it would be expected to be stored in Russia, and data-in-transit over the Internet still does not count as being stored.

Access information
The State Department indicates that providing access to information to non-US nationals is a problem even if it is done unknowingly – such as accidentally providing decryption keys to a list of individuals that includes even one unauthorised foreign person. The Commerce Department says that only knowingly providing such access information is a problem. However, given the Commerce Department's broad definition of 'knowing' and the State Department's ability not to penalise inadvertent errors, this too may not be a big difference.

Are there hidden gems in the rule's preamble?

Although there are no real gems in the preamble, there are interesting informational tidbits.

  • On the plus side, one need not worry if a foreign intelligence service incidentally collects their encrypted communications, which is good as there was no way of preventing this in the first place.
  • Another pro: if, for example, German defence technology enters the United States properly encrypted, the State Department need not authorise its subsequent re-export – unless it is being exported to a Section 126.1 country or Russia. However, non-US defence companies that are doing business with Section 126.1 countries or Russia should note that it is still not a good idea to send non-US defence technology to the United States. Further, they must still check and comply with German defence trade controls.
  • If the rule's encryption requirements are met, shipment or carriage of defence technology on a physical medium is also not an export. In other words, if all of the requirements are met, the defence technology can be sent out on a USB. However, whether this is a good idea (probably not) is a separate question.
  • On the not-so-good side, the State Department does not provide a guaranteed safe harbour to exporters that manage to obtain contractual assurances from their cloud service providers that the data will not be stored in a Section 126.1 country or Russia. The State Department is willing only to "review potential violations on a case-by-case basis, subject to the totality of the facts and circumstances comprising the issue at hand". Thus, exporters are likely to continue to ask their cloud providers for assurances.
  • If a virus scan or spellcheck renders data into clear text during transmission, this is not end-to-end encryption.
  • If encryption does not work or someone other than the technology owner, US persons in the United States or authorised non-US recipients manages to decrypt the technology, the original encrypted transmission was a violation or, as the State Department calls it, a 'controlled event' (ironic given that the decryption of a transmission is an 'uncontrolled event').

Is the rule open to comments?

Yes – comments can be submitted until 27 January 2020 (30 days after the rule's publication in the Federal Register).

Is the rule in effect now?

No – the State Department has made the interim rule effective 90 days after its publication in the Federal Register (ie, 25 March 2020). In other words, if companies encrypt and send out their defence-controlled technology now, they will technically violate the ITAR. In addition, because the interim final rule is subject to public comment, companies should be aware that a final rule with further revisions may be published at a later date.

Comparison of ITAR and EAR

The table below provides a side-by-side comparison of the new ITAR and the EAR.

New ITAR

EAR

Section 120.54 – Activities that are not exports, re-exports, retransfers or temporary imports

(a) The following activities are not exports, reexports, retransfers, or temporary imports:

(1) Launching a spacecraft, launch vehicle, payload, or other items into space.

(2) Transmitting or otherwise transferring technical data to a US person in the United States from a person in the United States.

(3) Transmitting or otherwise transferring within the same foreign country technical data between or among only US persons, so long as the transmission or transfer does not result in a release to a foreign person or transfer to a person prohibited from receiving the technical data.

(4) Shipping, moving or transferring defense articles between or among the United States as defined in §120.13 of this subchapter.

(5) Sending, taking, or storing technical data that is:

(i) Unclassified;

(ii) Secured using end-to-end encryption;

(iii) Secured using cryptographic modules (hardware or software) compliant with the Federal Information Processing Standards Publication 140-2 (FIPS 140-2) or its successors, supplemented by software implementation, cryptographic key management, and other procedures and controls that are in accordance with guidance provided in current US National Institute for Standards and Technology (NIST) publications, or by other cryptographic means that provide security strength that is at least comparable to the minimum 128 bits of security strength achieved by the Advanced Encryption Standard (AES-128);

(iv) Not intentionally sent to a person in or stored in a country proscribed in §126.1 of this subchapter or the Russian Federation; and

Note to Paragraph (a)(5)(iv): data in-transit via the Internet is not deemed to be stored.

Section 734.18 – Activities that are not exports, re-exports, or transfers

(a) Activities that are not exports, reexports, or transfers. The following activities are not exports, reexports, or transfers:

(1) Launching a spacecraft, launch vehicle, payload, or other items into space.

(2) Transmitting or otherwise transferring "technology" or "software" to a person in the United States who is not a foreign person from another person in the United States.

(3) Transmitting or otherwise making a transfer (in-country) within the same foreign country of "technology" or "software" between or among only persons who are not "foreign persons," so long as the transmission or transfer does not result in a release to a foreign person or to a person prohibited from receiving the "technology" or "software."

(4) Shipping, moving or transferring items between or among the United States, the District of Columbia, the Commonwealth of Puerto Rico, or the Commonwealth of the Northern Mariana Islands or any territory, dependency, or possession of the United States as listed in Schedule C, Classification Codes and Descriptions for US Export Statistics, issued by the Bureau of the Census.

(5) Sending, taking, or storing "technology" or "software" that is:

(i) Unclassified;

(ii) Secured using 'end-to-end encryption;'

(iii) Secured using cryptographic modules (hardware or "software") compliant with Federal Information Processing Standards Publication 140-2 (FIPS 140-2) or its successors, supplemented by "software" implementation, cryptographic key management and other procedures and controls that are in accordance with guidance provided in current U.S. National Institute for Standards and Technology publications, or other equally or more effective cryptographic means; and

(iv) Not intentionally stored in a country listed in Country Group D:5 (see supplement no. 1 to part 740 of the EAR) or in the Russian Federation.

Note to Paragraph (a)(5)(iv): data in-transit via the Internet is not deemed to be stored.

(b)(1) For purposes of this section, end-to-end encryption is defined as:

(i) The provision of cryptographic protection of data, such that the data is not in an unencrypted form, between an originator (or the originator's in-country security boundary) and an intended recipient (or the recipient's in-country security boundary); and

(ii) The means of decryption are not provided to any third party.

(2) The originator and the intended recipient may be the same person. The intended recipient must be the originator, a US person in the United States, or a person otherwise authorized to receive the technical data, such as by a license or other approval pursuant to this subchapter.
(Emphasis added.)

(b) Definitions. For purposes of this section, End-to-end encryption means

(i) the provision of cryptographic protection of data such that the data is not in unencrypted form between an originator (or the originator's in-country security boundary) and an intended recipient (or the recipient's in-country security boundary), and

(ii) the means of decryption are not provided to any third party. The originator and the recipient may be the same person.

(c) The ability to access technical data in encrypted form that satisfies the criteria set forth in paragraph (a)(5) of this section does not constitute the release or export of such technical data.

(c) Ability to access "technology" or "software" in encrypted form. The ability to access "technology" or "software" in encrypted form that satisfies the criteria set forth in paragraph (a)(5) of this section does not constitute the release or export of such "technology" or "software."

Section 120.55Access information

Access information is information that allows access to encrypted technical data subject to this subchapter in an unencrypted form. Examples include decryption keys, network access codes, and passwords. (Emphasis added.)

Section 772.1 – Access information

Information that allows access to encrypted technology or encrypted software in an unencrypted form. Examples include decryption keys, network access codes, and passwords.

Section 120.50Release

(a) * * *
(3) The use of access information to cause or enable a foreign person, including yourself, to access, view, or possess unencrypted technical data; or

(4) The use of access information to cause technical data outside of the United States to be in unencrypted form.

(b) Authorization for a release of technical data to a foreign person is required to provide access information to that foreign person, if that access information can cause or enable access, viewing, or possession of the unencrypted technical data. (Emphasis added.)

Section 734.15 – Release

(a) Except as set forth in §734.18, "technology" and "software" are "released" through:

(1) Visual or other inspection by a foreign person of items that reveals "technology" or source code subject to the EAR to a foreign person; or

(2) Oral or written exchanges with a foreign person of "technology" or source code in the United States or abroad.

(b) Any act causing the "release" of "technology" or "software," through use of "access information" or otherwise, to yourself or another person requires an authorization to the same extent an authorization would be required to export or reexport such "technology" or "software" to that person.

Section – 734.19 Transfer of access information

To the extent an authorization would be required to transfer "technology" or "software," a comparable authorization is required to transfer access information if done with "knowledge" that such transfer would result in the release of such "technology" or "software" without a required authorization. (Emphasis added.)

End-to-end encryption

According to the State Department's Federal Register Notice, for encryption to be 'end-to-end':

the cryptographic protection must be applied prior to the data being sent outside of the originator's security boundary and remain undisturbed until it arrives within the security boundary of the intended recipient. For communications between individuals, this can be accomplished by encrypting the data on the sender's computer prior to emailing or otherwise sending it to the intended recipient. For large entities, the security boundary may be managed by IT staff, who will encrypt the data before it leaves the entity's secure network and decrypt it on the way into the network. However, in all instances, the means of decryption must not be provided to any third party and the data must not have the cryptographic protection removed at any point in transit.

For further information on this topic please contact Kay C Georgi, Regan K Alberda or Sylvia G Costelloe at Arent Fox LLP's Washington DC office by telephone (+1 202 857 6000) or email ([email protected], [email protected] or [email protected]). Alternatively, contact Marwa M Hassoun at Arent Fox LLP's Los Angeles office by telephone (+1 213 629 7400) or email ([email protected]). The Arent Fox LLP website can be accessed at www.arentfox.com.