ExportLawBlog » Encryption

Archive for the ‘Encryption’ Category

Oct

19

Beijing’s Review of U.S. Software Risks Export Woes for Those Who Allow It

Posted by Clif Burns at 10:43 pm on October 19, 2015

140515-D-VO565-003 by Chief of Joint Chiefs of Staff via Flickr https://flic.kr/p/nkMLsf [Public Domain - Work of U.S. Government]

An article that appeared last Friday in the Wall Street Journal suggests that at least one U.S. company is providing the Chinese government with access to proprietary U.S. source code as a condition for access to the Chinese market. What could possibly go wrong with that??

Just as a burglar, who normallyÂ suspects everyone else of having his own larcenous motives, puts extra bars on his own doors and windows, the Chinese seem to be worried that U.S. software might have backdoors that allow the U.S. to hack into Chinese systems. Imagine that.

IBM has begun allowing officials from Chinaâ€™s Ministry of Industry and Information Technology to examine proprietary source codeâ€”the secret sauce behind its softwareâ€”in a controlled space without the ability to remove it from the room, the people said. It wasnâ€™t clear which products IBM was allowing reviews of or how much time ministry officials can spend looking at the code. The people said the practice was new and implemented recently.

The Wall Street Journal suggests that this access, which is designed to quell Chinese fears that the U.S. will do unto China what China has done unto the U.S., is largely symbolic because the Chinese are not being given sufficient time to comb through thousands of line of code looking for back doors.

The problem here, however, is that most software programs these days, particularly ones that might have “back door” entry concerns, will have encryption; and the EAR poses special restrictions on exporting certain types of encryption source code to certainÂ government end-users. Encryption source code that is classified as ECCN 5D002 (i.e., is not mass market) and is not publicly available is classified under section 740.17(b)(2)(i)(B) of license exception ENC. Under paragraphs (1) and (2) of the Note to 740.17(b)(2), such encryption source code can, after a classification request, be immediatelyÂ exported under license exception ENC to any end-user (including a government end-user) in a Supplement 3 country and to non-government end-users in countries, such as China, which are not a Supplement 3 country. However, exports of 5D002 encryption source code that is not publicly available, i.e., that is not available by download or otherwise to members of the public, can only be exported to a government end-user outside Supplement 3, such asÂ the Chinese government,Â with a license from the Bureau of Industry and Security. Â (A very good chart explaining the baroque complexities ofÂ Â license exception ENC Â can be found here.)

Now, here’s the catch. Most encryption algorithms are publicly available, but the code used by specific software to implement that algorithm is not. Indeed, if that code were publicly available, the Chinese wouldn’t need to review it, and the reviewing company would not insist that the code be examined in a “controlled space.” Indeed, you have to imagine that it is precisely the non-public code implementing the public algorithm which would be of most interest to Chinese reviewers concerned about U.S. software having back doors for Uncle Sam to come snooping.

Let me be clear: I’m not saying that IBM has broken any laws here. We don’t know whether the software being examined is 5D002 softwareÂ or, if it is, that IBM hasn’t applied for and received a license. Rather my point is this: companies that consider giving source code access to the Chinese should only move ahead with a great deal of caution if the software utilizes encryption.

Permalink

Comments Off

Jan

7

Behind Every Cloud Is Another Cloud

Posted by Clif Burns at 10:51 pm on January 7, 2015

Category: BIS • Cloud Computing • Encryption

Lonely Cloud by Kate Haskell https://www.flickr.com/photos/fuzzcat/32487111/ CC BY 2.0 [https://creativecommons.org/licenses/by/2.0/] (cropped) Breaking News: the Commerce Department has finally figured out how the Internet works. Or, perhaps more accurately, the Commerce Department has figured out that clouds aren’t just fluffy things that float in the sky from time to time.

Readers of this blog will know that I have been arguing for quite some time that the export agencies, including the Commerce and State Departments, need to revisit their absurd position that exports of encrypted technical data are the same thing as export of the technical data in plain text. If a company puts encrypted controlled technical data or technology on a foreign cloud server, then, under current rules and policies, the company will have exported that technical data or technology and will have violated the law if a license was required to export that information to that country.

According to this report (subscription required), BIS Assistant Secretary for Export Administration Kevin Wolf has revealed that this is being rethought

Among the terms to be defined is what constitutes an “export,” and one element of that definition will be that controlled information encrypted “in a certain way” will not constitute an export for purposes of cloud computing, while the unencrypted version would be, Wolf said.

That was the good news. Now for the bad news: according to Wolf, the various stakeholder agencies have not yet been able to agree on just what type of encryption will be sufficient to prevent an “export” of the transferred data.

The irony here is that the Department of Defense itself did not engage in any hand-wringing over encryption standards when it plopped its own, and presumably highly sensitive, communications on Chinese satellite transponders, rebuffing critics by noting simply that everything was encrypted. But — to end on a positive note — Assistant Secretary Wolf, who has been one of the driving forces behind export control reform, clearly understands this issue and I am sure he will do what he can to end this pointless interagency squabbling over the comparative merits and demerits of Blowfish, Triple DES and AES-256.

Permalink

Comments Off

Oct

8

Intel Sub Fined for Encryption Exports

Posted by Clif Burns at 9:14 pm on October 8, 2014

Category: BIS • Encryption

Wind River Convention Booth via https://twitter.com/WindRiver/media [Fair Use] The Bureau of Industry and Security (“BIS”) announced today that it had convinced Wind River, an Intel subsidiary, to pay a whopping $750,000 to settle charges that it exported products with encryption functionality without required licenses. There were also four unlicensed exports of the items to parties on the BIS Entity List. Â This is the first announced fine (at least to my knowledge) involving encryption exports, and it has created a bit of a stir among those of us who handle encryption export matters.

Basically the encryption rules try to prevent the export of technology that every twelve-year-old in Estonia already has. Door to empty barn, meet escaping horses; escaping horses, meet door to empty barn. It is a not-so-well-kept secret that the encryption rules are not really there to protect sensitive U.S. technology but as a means to permit the NSA to see who is using what encryption where in order to better snoop on everyone using encryption.

As usual, details are scarce in the settlement documents as to what exactly went on, with the documents simply saying that Wind River exported items classified as 5D002 to government end users in China, Hong Kong, Russia, Israel, South Africa and South Korea. A little snooping of our own showed that the items involved, mostly real time operating systems, were classified by Wind River as 5D002 “ENC restricted.” All ENC restricted items require licenses to government end users in countries other than those countries listed in Supplement 3 to Part 740 of the EAR. The countries involved in the exports at issue are not Supp. 3 countries and, hence, required a license.

The BIS press release justified the size of the fine, despite Wind River’s voluntary disclosure of the violation, because it would “serve as a reminder to companies of their responsibility to know their customers and, when using license exceptions, to ensure their customers are eligible recipients.” This suggests that Wind River’s problemsÂ may have arisenÂ because it was dealing with entities that it did not realize were government end users.

However the BIS definition of government end users is hardly a model of clarity:

A government end-user is any foreign central, regional or local government department, agency, or other entity performing governmental functions; including governmental research institutions, governmental corporations or their separate business units (as defined in part 772 of the EAR) which are engaged in the manufacture or distribution of items or services controlled on the Wassenaar Munitions List. â€¦

Consider the portion of the definition that includes “governmental corporations or their separate business units (as defined in part 772 of the EAR) which are engaged in the manufacture or distribution of items or services controlled on the Wassenaar Munitions List.” Â For starters, does the qualifier “engaged in manufacture â€¦ of items â€¦ on the Wassenaar Munitions List” qualify just “separate business units” or both “governmental corporations” and “separate business units”? And what are government corporations? Companies that have a government charter but private ownership? Companies that have a significant percentage owned by the government? Private companies given a government monopoly and that perform a traditional government function? Who knows? But if you get it wrong, expect to be fined by BIS and to be the object of a snide comment that it’s your own darn fault for not figuring out that the company was a government corporation under an essentially meaningless definition.

Permalink

Comments (1)

Jun

11

DDTC Deflates Cloud Puffery

Posted by Clif Burns at 5:25 pm on June 11, 2014

Category: DDTC • Deemed Exports • Encryption

Lonely Cloud by Kate Haskell https://www.flickr.com/photos/fuzzcat/32487111/ CC BY 2.0 [https://creativecommons.org/licenses/by/2.0/] (cropped) One of the most frustrating ways in which the Luddites at DDTC have made life difficult for exporters in the 21st century is by taking the position that encrypted technical data is the same thing as unencrypted technical data for purposes of the ITAR. So if you put encrypted technical data on a cloud server outside the United States, you’d better get measured for an orange jumpsuit, because you’ve just exported technical data. Never mind, of course, that no one outside the United States can actually read or decrypt the data; you’ve still exported it.

Even the DoD, hardly a progressive force in these matters, thinks this position is nonsense. As we reported a while back, the DoD defended its decision to use Chinese satellites to transmit its own data on the grounds that all the data encrypted and thus meaningless to our friends in Beijing. Since DoD has guns, and DDTC does not, you won’t be surprised as to who would win any argument between DoD and State on the efficacy of encryption for these purposes.

So earlier this month, you might have been surprised to see this press release from Perspecsys:

Perspecsys, the leader in enterprise cloud data protection, announced today that it received a written ruling from the U.S. Department of Stateâ€™s Directorate of Defense Trade Controls (DDTC) confirming that technical data secured using Perspecsys tokenization can be processed outside the U.S. through the cloud without obtaining an export license under the International Traffic in Arms Regulations (ITAR).

In its groundbreaking decision, DDTC reinterpreted the ITAR to authorize the use of Perspecsys tokenization to process ITAR technical data in the cloud without a license, even where the tokenized technical data may be transferred to servers located outside the United States. DDTCâ€™s new interpretation shifts the regulatory landscape â€“ opening the cloud to companies subject to the ITAR.

Tokenization is a process whereby a random token is issued to replace sensitive data such as a credit card number. Unlike encryption, there is no algorithm to decode the token back into the credit card number. Rather the token and the original data are maintained on a secure server which can be used to replace the token when necessary. Thus, if the press release were to be believed, if the translation server remained in the United States, the token for technical data could be transferred to a cloud outside the United States without need for an export license.

Of course, before you get too excited, I regret to inform you that this is not what the DDTC advisory opinion actually said. Instead, it said that section 125.4(b)(9) might exempt tokenized data if it was sent by by a U.S. employee overseas to another U.S. employee and no foreign person had access to the tokenized data. In other words, tokenized data would be treated exactly the same as its non-tokenized counterpart and was eligible only for export subject to exceptions that would be applicable to all technical data, whether encrypted, tokenized or in plain text.

DDTC was not amused by Perspecsys’s suggestion in its press release that the agency had finally entered the 21st century. Â So the agency “requested” that Perspecsys post a statementÂ that amounts to a retraction of Perspecsys’s earlier press release. In that statement, DDTC clarified (a) that only transfers from a U.S. corporation to its own U.S. national employees was covered by the advisory opinion, (b) that steps must be taken to assure that no foreign persons had access to the data and (c) that the advisory opinion did not hold that tokenization constituted sufficient steps to prevent foreign access to the technical data.

All this makes me wonder: if you shred controlled technical data into a million tiny bits of paper do you have to make sure that the garbage collector is not a foreign person and that no foreign persons are allowed to visit the garbage dump?

[Thanks to an alert reader who pointed out the two press releases to me!]

Permalink

Comments (2)

Sep

12

UK Uses Encryption Controls To Prevent Export of FinSpy Trojan

Posted by Clif Burns at 6:33 pm on September 12, 2012

Category: Encryption • Foreign Export Controls

ABOVE: Gamma International
headquarters in Andover, UK

Bloomberg News reported yesterday that the U.K. has imposed export controls on Gamma International’s FinFisher software. FinFisher is commercial trojan software that can take over computers and mobile phones and which the company has marketed to foreign governments anxious to keep really, really close tabs on political dissidents. Reporters and privacy groups have uncovered evidence recently that the nice folks in Bahrain were using this software against political dissidents in that country.

Of particular interest is the rational used by the U.K. to assert export controls over the software. According to a letter sent by the U.K. government, the software required an export license because it uses cryptographic functionality covered by Category 5, Part 2 of the E.U.’s Dual Use Control List:

The Secretary of State, having carried out an assessment of the FinSpy system to which your letter specifically refers, has advised Gamma International that the system does require a licence to export to all destinations outside the EU under Category 5, Part 2 (â€˜Information Securityâ€™) of Annex I to the Dual-Use Regulation. This is because it is designed to use controlled cryptography and therefore falls within the scope of Annex I to the Dual-Use Regulation. The Secretary of State also understands that other products in the Finfisher [sic] portfolio could be controlled for export in the same way.

Of course, the interesting question here is whether the similar controls placed on encryption in Category 5, Part 2 of the Commerce Control List would require an export license if a U.S. company wanted to export similar trojan software for surveillance purposes. More particularly, the issue is whether under License Exception ENC a U.S. company could self-classify the item and export it without license if it had previously registered and received an Encryption Registration Number. It seems to me that it could not because the software at issue falls within 740.17(b)(2)(i)(C)(3) which excludes from self-classification items that have been designed for government end users. It is abundantly clear that Gamma International only sells this trojan software to government end users. Nevertheless, items in this category can be exported immediately upon filing a classification request to countries outside those listed in Supplement 3 to Part 740, e.g., most NATO countries as well as Japan, Switzerland, Malta, Australia and New Zealand. Licenses would be required, however, for exporting the software to countries outside those listed in Supplement 3. The U.K. will apparently require licenses to all destinations.

An additional control on such software in the United States could be found in ECCN 5D980 which controls software “primarily useful for the surreptitious interception of wire, oral, and electronic communications.” However, at least under current policy licenses to export such software to government agencies in countries other than Cuba, Iran, North Korea, Sudan, and Syria are generally approved. Whether that policy will hold given the current publicity over the use of FinFisher by oppressive regimes is another matter.

Permalink

Comments (2)