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

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:

1. your technology does not include any classified information;
2. your encryption is truly “end-to-end”[2];
3. 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
4. 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:

1. 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?
2. §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.
3. 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]

[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.”