ITAR Defense Controls Catches Up to Modern IT, Allowing Exporters to Use Encryption to Protect Defense Technology on the Cloud

Aerial view of water and dock covered in shipping containers

In a surprise holiday present, the State Department finally brought the International Traffic in Arms Regulations (ITAR) into the 21st century by releasing an Interim Final Rule adopting cloud computing encryption standards that the Commerce Department adopted in 2015. Well, better late than never.

The good news is that, for the most part, State resisted the temptation to do something just a little different in the ITAR regulation, so the joint Commerce-State solution works. The chart below[1] provides a quick side-by-side comparison of the two very similar solutions.

1. What does the Interim Final Rule mean for the exporting community?

Companies that held off transitioning data to cloud service providers or implementing the encryption standards adopted by Commerce in 2015 on their network systems because their servers contained ITAR-controlled defense technology in addition to Commerce-controlled dual-use technology can now proceed to use the cloud for both ITAR- and EAR-controlled technology without making sure all the cloud servers are located in the United States.

2. What is the catch?

There are two major catches: First, you still need to make sure that the requirements that are now in both Commerce and State regulations are met:

your technology does not include any classified information;
your encryption is truly “end-to-end”[2];
your cloud provider is using cryptographic modules (hardware or software) compliant with the Federal Information Processing Standards Publication 140-2 (FIPS 140-2) (or other compliant encryption); and
your cloud provider’s servers are not in the ITAR proscribed 126.1 countries (Commerce’s country group D:5) or Russia.

Second, while this regulation (and the preexisting Commerce regulations) jointly address nearly all US export-controlled technology (minus Department of Energy controlled technology), it does not take care of non-US export-controlled technology. If, for example, some of your defense technology is developed and housed in the European Union, you will need to wait for the EU to catch up before implementing this as a global solution. But, in an encouraging sign, State says in the preamble 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 utilize the US solution in conjunction with licenses in other countries where the company has data subject to local export control restrictions.

3. So what’s new and different in the State solution?

There are a lot of little nuances that probably will not have a significant impact, except perhaps down the road in an enforcement context:

Encryption strength. State has said that if the encryption is not FIPS 140-2, then the encryption needs to provide security strength that is at least comparable to the minimum 128 bits of security strength achieved by the Advanced Encryption Standard (AES-128). Commerce said it had to be FIPS 140-2 or “other equally or more effective cryptographic means.” By establishing a clear industry standard, State has made life easier for exporters and cloud providers, although one suspects most exporters will insist on FIPS 140-2. Why risk it?
§126.1 Countries. State slightly changed the prohibition on ITAR proscribed countries. State says it is not enough that the technology is not intentionally stored in a §126.1 country or the Russian Federation. It also cannot intentionally be sent to a person in one of those countries. This may not make much of a difference in practice: if you send an encrypted technical email to an end-user in Russia, you would expect that it be stored in Russia, and data-in-transit over the internet still does not count as being stored.
Access Information. State indicates providing access 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 unauthorized foreign person. Commerce says that only “knowingly” providing such access information is a problem. However, given Commerce’s broad definition of “knowing” and State’s ability not to penalize inadvertent errors, this too may not be a big difference.

4. Are there hidden gems in the preamble to the rule?

Well, perhaps not gems but certainly interesting informational tidbits.

On the good side, we do not have to worry if a foreign intelligence service “incidentally” collects our encrypted communications. Excellent, as we did not have any way of preventing this in the first place!
Another pro: if, for example, German defense technology comes into the United States properly encrypted, State does not need to authorize its subsequent reexport – unless it is being exported to a §126.1 country or the Russian Federation. So note to non-US defense companies that are doing business with §126.1 countries or the Russian Federation: still not a good idea to send your non-US defense technology to the United States. And you still have to check and comply with German defense trade controls.
If you meet the encryption requirements of the rule, shipment or carriage of defense technology on a physical medium is also not an export. In other words, if all the requirements are met, you can send your defense technology out on a USB. However, whether this is a good idea (probably not!), is a separate question.
On the not so good side, State does not provide a guaranteed safe harbor to exporters who manage to obtain contractual assurances from their cloud service providers that the data will not be stored in a §126.1 country or Russia. State is only willing to “review potential violations on a case-by-case basis, subject to the totality of the facts and circumstances comprising the issue at hand.” We suspect that exporters will continue to ask their cloud providers for assurances.
If your virus scan or spell-check renders the data into clear text during transmission, you are out of luck – that is not end-to-end encryption.
If your encryption does not work or someone other than you, US persons in the United States, or an authorized non-US recipient manages to decrypt your technology, then your original encrypted transmission was a violation (or as State has taken to calling it a “controlled event” – a funny term in this context because the decryption of the transmission was an “uncontrolled” event).

5. Can we comment on this rule?

Yes, until January 27, 2020, 30 days after its publication on the Federal Register.

6. Is the new rule in effect now?

No, State has made the interim rule effective 90 days after its publication in the Federal Register, or March 25, 2020. In other words, if you start encrypting and sending out your defense controlled technology now, you are technically violating the ITAR. Why add 90 days to our 4.5 years wait, State? Additionally, because the Interim Final Rule is subject to public comments, you should be aware that a final rule with further revisions may be published at a later date.

[1]

NEW ITAR	EAR
§ 120.54 Activities that are not exports, reexports, 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.	§734.18 Activities that are not exports, reexports, 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 1 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.	(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.”
§ 120.55 Access 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.	§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.
§ 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.	§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. §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.

[2]

According to State’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.”