Archive for the ‘Encryption’ Category


Sep

22

Don’t Forget Croatia


Posted by at 7:43 am on September 22, 2016
Category: BISEncryption

Sea view. Rovinj, Croatia by Andrey[CC-BY-SA-2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Flickr https://flic.kr/p/5oVXCk [cropped and processed]

Yesterday, the Bureau of Industry and Security (“BIS”) announced various amendments to the encryption rules. I realize that the encryption rules are a sprawling mess, scattered through various sections of the EAR and written in an incomprehensible jargon that sounds like they were translated into English from a Vulcan paraphrase of the original Sanskrit. I also realize that your eyes understandably glazed over when you saw the word “encryption.” So I’ll try to make this as painless and entertaining as possible.

Let’s start with the really big news. Croatia has been added to the list of Supplement 3 Countries! Woohoo! For those of you aren’t really excited about this, that is probably because you forgot that if you are not a Supp. 3 country, there is a 30 day waiting period after a review request has been filed before encryption items described in 740.17(b)(2) and (b)(3) such as source code and high-performance network equipment can be exported to that country. And if those items were going to government end users in  country not on the Supp. 3 list, a license was required. So, today was declared a national holiday in Croatia and papier-mâché effigies of key BIS officials were draped with garlands and paraded through town squares across the country.

While we’re on the subject of government end users, the amendments create a new kind of government end user — “less sensitive government end users.” These are government agencies that are the toughest of their kind and at which you can hurl the most frightening insults — say, “you cabal of pointy-headed bureaucrats!” — without hurting their feelings. No, I’m just kidding with you. “Less sensitive government end users” are government agencies that are less likely to use encryption for evil purposes, like museums, water treatment plants and census bureaus.

The reason for identifying “less sensitive government end users” is that high performance network infrastructure equipment used to require a license to go to any government on the Naughty List (i.e., not on the Supp. 3 Nice list). Now these items can be exported 30-days after a review request is filed provided that it’s a less sensitive government end user.

The best news I’ve saved for last.  No more encryption registration numbers!  For the 50 or so companies out there who still don’t have an ERN, you’re off the hook.  Annual self-classification reports will still have to be filed; and the new format for the report, which is detailed in an amended Supplement 8 to Part 742, incorporates some of the information that used to be required by the ERN application.

For a summary of the remaining changes, including a long-needed update of the performance parameters for high performance network infrastructure equipment subject to higher encryption controls, you can read this excellent summary, which is mostly clear and more or less written in English, helpfully provided by the nice people at BIS.

Photo Credit: Sea view. Rovinj, Croatia by Andrey [CC-BY-SA-2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Flickr https://flic.kr/p/5oVXCk [cropped and processed]. Copyright 2008 Andrey

 

Permalink Comments (3)

Bookmark and Share


Copyright © 2016 Clif Burns. All Rights Reserved.
(No republication, syndication or use permitted without my consent.)

Oct

19

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


Posted by at 10:43 pm on October 19, 2015
Category: BISChinaEncryption

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 on Beijing’s Review of U.S. Software Risks Export Woes for Those Who Allow It

Bookmark and Share


Copyright © 2015 Clif Burns. All Rights Reserved.
(No republication, syndication or use permitted without my consent.)

Jan

7

Behind Every Cloud Is Another Cloud


Posted by at 10:51 pm on January 7, 2015
Category: BISCloud ComputingEncryption

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 on Behind Every Cloud Is Another Cloud

Bookmark and Share


Copyright © 2015 Clif Burns. All Rights Reserved.
(No republication, syndication or use permitted without my consent.)

Oct

8

Intel Sub Fined for Encryption Exports


Posted by at 9:14 pm on October 8, 2014
Category: BISEncryption

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)

Bookmark and Share


Copyright © 2014 Clif Burns. All Rights Reserved.
(No republication, syndication or use permitted without my consent.)

Jun

11

DDTC Deflates Cloud Puffery


Posted by at 5:25 pm on June 11, 2014
Category: DDTCDeemed ExportsEncryption

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)

Bookmark and Share


Copyright © 2014 Clif Burns. All Rights Reserved.
(No republication, syndication or use permitted without my consent.)