IRS Encourages Poor Cryptography

I’m not sure what to make of this, or even what it means. The IRS has a standard called IDES: International Data Exchange Service: “The International Data Exchange Service (IDES) is an electronic delivery point where Financial Institutions (FI) and Host Country Tax Authorities (HCTA) can transmit and exchange FATCA data with the United States.” It’s like IRS data submission, but for other governments and foreign banks.

Buried in one of the documents are the rules for encryption:

While performing AES encryption, there are several settings and options depending on the tool used to perform encryption. IRS recommended settings should be used to maintain compatibility:

  • Cipher Mode: ECB (Electronic Code Book).
  • Salt: No salt value
  • Initialization Vector: No Initialization Vector (IV). If an IV is present, set to all zeros to avoid affecting the encryption.
  • Key Size: 256 bits / 32 bytes ­ Key size should be verified and moving the key across operating systems can affect the key size.
  • Encoding: There can be no special encoding. The file will contain only the raw encrypted bytes.
  • Padding: PKCS#7 or PKCS#5.

ECB? Are they serious?

Tags: , , ,

Posted on February 18, 2015 at 6:42 AM • 53 Comments

Comments

Musashi • February 18, 2015 7:03 AM

Perhaps this is the new government policy to weaken security to protect us against drug dealers, terrorists and pedophiles…

Z.Lozinski • February 18, 2015 7:07 AM

The IBM cryptanalysis of DES showed why ECB is a bad idea. The example used was encrypting a file with a well-defined structure, which is clearly still visible in the ciphertext. That was published in the IBM Systems Journal back around 1980, when we were trying to get the IT industry to understand why crypto and DES were important, and how best to use it.

Clive Robinson • February 18, 2015 7:24 AM

Any body remember why Swift ended up moving to Switzerland?

It was because a person friendly to the Bush administration was aranging for all the Swift transaction data to be made available to the US Gov to aid in the war on terror… when the Europeans were made aware of this via the work of PI, the kick back was very large , and the fall out was significant.

Thus I would be suspicious that any such “crypto mistake” would be to the NSA’s or GCHQs advantage, in that they could get the data without asking the IRS etc. Which has all sorts of advantages, especialy in political organisations. Thus it is quite possible the standard designers had the same issues/help NIST did with one of theirs…

wiredog • February 18, 2015 7:27 AM

Oh, FFS, guess who else uses ECB? The Department of Defense. Specifically, the Defense Health Service. All the medical records transmitted to/from AHLTA.

Why am I not surprised?

David • February 18, 2015 7:37 AM

It might have changed as I’ve not checked recently, but at least one UK government department explictly states that files submitted to them must NOT be encrypted. seems it’s to ensure they (and of course by extension anyone else on the internet) will have no issues reading the data. Would not be an issue were it not that some of the data is actually quite sensitive.

Pope Jenner • February 18, 2015 8:19 AM

@wiredog: ECB in AHLTA sounds like bad news. What’s encryption like in the private sector?

Last I see about HIPAA on this blog is from 2005. Can anyone offer current updates on medical privacy/security best practices, especially in light of Snowden’s revelations?

lazlo • February 18, 2015 8:37 AM

To me this reeks not of anything underhanded, but purely of someone who does not understand encryption and/or security writing documentation.

65535 • February 18, 2015 8:42 AM

“Buried in one of the documents are the rules for encryption:

“Cipher Mode: ECB (Electronic Code Book).
“Salt: No salt value
“Initialization Vector: No Initialization Vector (IV). If an IV is present, set to all zeros to avoid affecting the encryption.
“Key Size: 256 bits / 32 bytes ¬ Key size should be verified and moving the key across operating systems can affect the key size.
“*Encoding: There can be no special encoding. The file will contain only the raw encrypted bytes.

“*ECB? Are they serious?” -Bruce S

Whoa, the IRS needs some “serious backward” compatibility – or the government wants to ensure the NSA can “man-in-the-middle” [break the encryption] your tax return on the fly.

Steven • February 18, 2015 8:48 AM

The job is to transfer data from here to there. To the people responsible for getting that job done, encryption–and security in general–is an obstacle. They write guidelines like this to minimize the chances that encryption will get in their way. They aren’t recommending ECB with the idea that they–or anyone–will exploit the information that it leaks. They are recommending ECB because it is the simplest, LCD, and therefore most likely to work in practice.

The U.S Navy used to have a similar attitude towards communications security. Commanders were responsible for communicating with ships at sea. They made decisions that effectively traded security for reliability in these communications. Individually, each of these decisions made sense to the commanders who made them. In the aggregate, they created a security environment that made it easy for John Walker to sell the encryption keys to the Soviet Union.

Audit me • February 18, 2015 9:13 AM

Don’t worry, the IRS is on it. NSA sent over a crack tiger team and they’re writing an RFI for a sole-source classified MIPR to Booz Allen, FFP $483.69M for a four-stage program to upgrade to ROT-13.

Zedarth • February 18, 2015 10:23 AM

At the risk of a flame war I am curious as to the plausibility of actually decrypting the data posited by the IRS.

The article that Bruce links is showing an example of cryptanalysis allowing someone to see underlying patterns across a large swath of data, but how is that relevant to common text based files vs images where there are potentially large patches of repeating blocks– more to the point– if I encrypted a small file using the specs outlined above, what would be the realistic level of effort for anyone to decrypt it and actually read the data. How big would the file need to be before cryptanalysis would become possible, also given the fact that every file may use its own key.

I’m not trying to be ignorant, just inquisitive!

I would think this would be relevant to understand before comparing it to ROT13 or DES– and also understanding the nature of the files IRS is receiving and how large they are.

4028uf298u • February 18, 2015 11:04 AM

They also don’t correlate data when processing taxes. This is why organizations and businesses in America can ‘burn books’ so easily..

Dirk Praet • February 18, 2015 11:52 AM

Really ? Sounds like a seriously backward system to me.

Over here, indviduals nowadays use an on-line system called “Tax-on-Web” for filing personal income tax returns. We authenticate using a card reader with chip (and pincode) embedded in our eID identity cards. There’s even a Firefox add-on for it. For businesses, there is BizTax. Many e-government sites and portals such as My.belgium.be and http://www.policeonweb.belgium.be use the same mechanism for access and encryption. For those interested, check out http://eid.belgium.be/en/.

I guess the USG is more interested in penetrating and cracking what others are doing than securing the critical infrastructures of their own country.

@ Audit Me

NSA sent over a crack tiger team and they’re writing an RFI for a sole-source classified MIPR to Booz Allen, FFP $483.69M for a four-stage program to upgrade to ROT-13.

+1

David Leppik • February 18, 2015 12:00 PM

@Zedarth: I’m not a cryptographer, I’m a developer who takes security seriously. And even if you posit that the keys don’t get reused and are for short messages, there are several things going on here that make me wince.

Think of these as my heuristics for people who are serious about security but aren’t cryptographers.

  1. Security fails due to slip-ups. If you have to think about doing it right, the procedures are wrong. Therefore there are good algorithms and bad algorithms, and you don’t want to have to think about the latter. You don’t even want bad algorithms on your computers. (See: the NSA sneaking a bad random number generator into RSA Inc.’s software libraries, so an attack could look like a configuration error.)
  2. Information leakage, however trivial it may seem to you, can often be leveraged by an attacker. If you can avoid leaking it, don’t leak it. That’s especially true for an encryption algorithm, which isn’t supposed to leak anything.
  3. Suggesting a bad algorithm, when better ones exist, suggests that the author of the document doesn’t know that it’s a bad algorithm– and probably doesn’t know a lot about the equally important, mundane details of security. (I.e. my points #1 and #2.) So the document almost certainly has security as a check-list item, rather than a thought-through requirement.

In this case, choosing an algorithm that’s over a decade out of date means somebody copied the security procedure from some other long out-of-date procedure, rather than look at what might be reasonable in the 21st century. So there’s no need to look at the rest of the document to know that the security stinks.

What it comes down to is that real-world security, as practiced by software developers, managers, and front-line staff (e.g. security guards, call center agents), is about gut feelings. If something seems wrong, there’s a good chance it is wrong– not because that particular thing is bad, but because something has changed for apparently no good reason. And if you have to think about whether something is dangerous or just unusual, you’re in the realm of having to outsmart a potentially smarter opponent.

Jacob • February 18, 2015 12:24 PM

I seem to remember the IRS and FBI have been trying to upgrade/migrate their computer systems for at least a decade to the tune of 100s of millions. Still haven’t finished. They are still running COBOL and windows 98 on some.
COBOL is in a lot more places than you would guess. I have seen a functioning 100 year old fire alert system, gamewell so I half expect to see an Amiga OS on a Motorola 68000 chip… 😉

Hanlon’s razor.
“”Never attribute to malice that which can be adequately explained by stupidity.

Anura • February 18, 2015 1:10 PM

This is why I am leaning away from the idea of traditional ciphers in computing: don’t give a choice because people will make the wrong one. With stream ciphers, reusing an IV has disasterous results, and with a block cipher, handling padding incorrectly or choosing the wrong mode of operation can be dangerous, and with any cipher not using an MAC can be dangerous.

I wrote a proof of concept block cipher recently; the idea is that it’s designed to be an efficient block cipher that encrypts every block differently – padding is defined by the algorithm, a message authentication code is automatically appended to the output and checked, and there is no choice of modes of oepration. Because there is no chaining as with CFB and CBC modes, there is no way that a malicious user could force a specific bit or set of bits to flip (as long as the cipher itself is secure, which is beyond the scope of my proof of concept).

An IV is still required; I haven’t found a way around that, but reusing an IV is less bad with this than reusing an IV with a stream cipher and less than or equal to as bad as reusing an IV with a traditional block cipher. With a reused IV, it gives away whether or not two blocks at the same position in two different messages have the same value, but nothing else.

Grumpy • February 18, 2015 1:30 PM

In the minds of children, college students, and many academics, important technical decisions are made by the experts, the folks who really know what they are doing.

The real world is quite different. The folks who are technically incompetent (utterly clueless) are foisted off on all the meetings. They’re seen. They’re the ones who get promoted. Add this to a top-heavy hierarchy, where most of the staff is “managing” the very few people at the bottom who are working their asses off. And then play the old “telephone” game where directives are passed up and down the hierarchy, with little out-of-band information or details to go on other than “we need security” or “no you don’t get a budget increase for adding security”. Oh, and remember that anybody even remotely competent at the bottom is aggressively searching for a better job and just doing the minimum they need to get by. And that it’s just basically a “we have security” checkbox for the sales team where nobody discovers how worthless your security is until after their check has cleared.

It’s a recipe for disaster, and I’ve seen it many a time. My favorite was the guys who said their password file was encrypted. Later I found out this meant they XOR’ed every byte in the file with the same 8-bit value. And most of that data was NULLs (zeros). Rot13 would have been an upgrade!

The other side of this is politics. All those folks doing the managing are playing political turf wars with each other to advance their careers. So there’s intentional sabotage as well as accidental. Or lip service being paid to intentions while the letter of the requirements is fulfilled.

Consider too how many graduating students want to go work for Google, Apple, Microsoft, etc vs how many want to work for the IRS. What is the caliber, the technical proficiency, of their employees?

I don’t think this is deliberate, or involves the NSA or anything. It’s more the level of incompetence that I’ve come to expect.

Thomas • February 18, 2015 1:31 PM

“IRS recommended settings should be used to maintain compatibility: ”

All these good compatibility recommendations, and then they leave the end-user to choose their own keys rather than standardise those as well.

Typical sloppy government work, as it leaves the possibility not only of incompatibility, but also insecurity due to “Weak keys”: http://downlode.org/Etext/alicebob.html

Anura • February 18, 2015 2:56 PM

Thinking about it, in the past I’ve worked with APIs in the past for sending sensitive XML-encoded data to banks and various vendors, and they came up with a couple novel solutions:

1) Create a TLS connection and send using a SOAP API. In some cases, this also made use of client certificates, in others a static API key.
2) Send PGP files over FTP

Okay, maybe not novel, but they seemed to work without any compatibility issues.

Thoth • February 18, 2015 6:17 PM

I am guessing ECB mode is used for the sake of simplicity so that code cutters and security contractors writing codes don’t need to meddle with anything more complex. Of course it is a bad excuse and a very bad one. Their goals are to simply complete security audit requirements and not to actually promote security anyway so I am not surprised they are not bothered to do any clean and good crypto. This is a good example how to fail crypto compliance audit.

What they should have done is to follow the standard PGP/GPG style as it has been well tested and deployed rather than creating their own standards.

Paul Coddington • February 18, 2015 8:18 PM

Could be much worse. I once attended a meeting at a big government department where the entrenched developers (who despised us know-nothing temporary contractors) came to the conclusion that the department must implement its own encryption algorithms for Internet communications, because all the others in common use were widely known, had source code publically available and were therefore completely insecure.

Luckily, people who think like this end up in non-critical areas, such as designing systems for monitoring border security (I wish I were kidding).

Victor • February 19, 2015 2:02 AM

I guess somebody over there panicked (or the site blocks UK IP addresses). All I get at the “rules for encryption” link is “This article doesn’t have a translation for English” (which is their default 404 page, it seems) and no link to any translations.

keiner • February 19, 2015 2:16 AM

Click on link under “documents” and then click on “Step 3 Encrypt the XML…”

…this will work

Alain • February 19, 2015 3:23 AM

@Dirk Praet

The Belgian ” eID identity card” is a security and privacy disaster, everything is easy readable when you put an e-id in a reader, including a certificate, the photo of the user and the national nr of the user. There’s no security for the data on the card (except maybe a check for genuine cads).

So anytime you put you’re eID in a reader, the owner of the reader has all that info.

Oh yeah, the certificate uses you’re national nr open and clear. With the default software it’s by default installed on the computer, this is more user friendly.

My advice is : Never, really never, use the eID except when forced to by cops. And then I would ask their ID first.

BTW. The Belgian taxes allow another way of identity check, which is simple (a printed pad with 20 codes + username + password) and given the low use of the application more secure.

Dave • February 19, 2015 4:01 AM

At the risk of a flame war I am curious as to the plausibility of actually decrypting the data posited by the IRS.

My feelings as well. If someone really wants some person’s tax records badly enough then they’ll blackmail/bribe/whatever one of the X million IRS employees to get them, not carry out some large-scale wiretap, capturing all IRS traffic, and then looking for patterns in the ECB-mode data and trying to figure out what they represent. Sure, it’s awful encryption, but it’s nowhere near the weakest link in the chain. If no-one’s going to bother attacking your encryption then it doesn’t matter whether you use AES-256-GCM, AES-128-ECB, or RC4-40, it’ll be all the same to an attacker.

(There’s a pity quote in there somewhere, just can’t think of it at the moment. Bruce?).

Peter • February 19, 2015 5:44 AM

It’s not as bad as one third party card payment company I once worked with. They supplied my client with a key which was to be kept private and used to Vigenère-encrypt some transaction data; this would then be sent via a form submission on the end user’s browser to the payment company, making the end user a man in the middle who could easily extract the key. The payment company would presumably then have blamed my client for not protecting they key well enough.

When I kicked up a fuss, they turned out “by coincidence” to be working on an AES-based system, whose deployment they “accelerated” for me.

Eliot Spitzer in socks • February 19, 2015 10:04 AM

Dave, re “If someone really wants some person’s tax records.” We’re not talking about someone, we’re talking about NSA, which is already carrying out a large-scale wiretap, capturing all IRS traffic. Direct surveillance and parallel construction bypass legal restraints on explicit inter-agency cooperation. It lets you investigate the man and not the crime.

Rule by secret decree after 9/11 institutionalized the Huston Plan for domestic surveillance. IRS is actively complicit with intelligence agencies’ domestic operations – Why do you think David Cohen went to CIA? Pretend encryption just is the most effectively way to help the spies.

moo • February 19, 2015 10:49 AM

Can’t wait for squid post, this is too nuts:

http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/

Some adware company called Superfish Inc. got Lenovo to bundle their adware with new machines. It installs a self-signed root certificate and MITMs your SSL connections.

I used to roll my eyes at the guys who clean out all the pre-installed root certs and only whitelist specific certs themselves, but this kind of crap certainly justifies their level of paranoia. I wonder if Lenovo will be sued for this?

mesrik • February 19, 2015 12:30 PM

@Clive

“Any body remember why Swift ended up moving to Switzerland?”

Hmm… AFAIK, SWIFT HQ is located in La Hulpe, Belgium.

I think it’s Switzerland’s significant role in banking industry and because SWIFT starts with an S that many (wrongly) conclude it’s Swiss … something. But really it’s not, it’s Society for Worldwide Interbank Financial Telecommunication that the abreviation comes from.

Cheers,

🙂 riku

sabu • February 19, 2015 3:13 PM

“moving the key across operating systems can affect the key size.”

Sure it can. Why, just the other day I copied my 256-bit key to a Linux machine and found that it was now 192 bits.

Dave • February 19, 2015 4:08 PM

@Eliot Spitzer: Given that the NSA is one branch of the USG and the IRS is another, I suspect if some part of the USG (whether it’s the NSA, FBI, DHS, or whatever) wants access to IRS records they won’t need to resort to traffic-interception to get them. Even if they want to get them surreptitiously, I’m sure they have easier means than going for encrypted traffic.

Eliot Spitzer's black socks • February 19, 2015 5:54 PM

Dave, they have it anyway, since they Collect It All. Why go all the way to Federal Triangle when it’s at your fingertips? Much of it doesn’t even have to be encrypted. For a long time IRS did not bother with encryption because… their protocols were so obsolete that nobody understood them anymore. No really. More importantly, when you ask for it, that might generate a paper trail. Or somebody might want to run it by the counsel’s office. When you’re breaking the law spying on State Senator Obama, or Chief Justice Alito, or Colin Powell, or General Petraeus, or journalists, bankers, attorneys, and all the other people NSA spies on and blackmails, it’s crazy not to use what you already stole.

Vincent • February 20, 2015 3:21 PM

Looks like someone tinkered with the available settings until some rather limited test case succeeded.

Worrying about changing key size when “moving the key across operating systems” on the one hand and disregarding encoding on the other hand is pretty much giving away one simple explanation: Whoever wrote that specification is completely clueless whey those annoying settings are there.

z • February 20, 2015 4:22 PM

So, the IDES is an IRS electronic delivery point so FIs and HCTAs can transmit FACTA data within the USA, using AES in ECB mode with no IV and PKCS#7 or PKCS#5 padding?

The government must have a special acronym agency (SAA) just to keep track of all that.

Anura • February 21, 2015 5:01 PM

@Dave

I tend to agree that it’s probably not that big of a deal; considering the data is compressed first, it’s unlikely to even have patterns, especially those that are exploitable. However, this is cryptography 101; the fact that they rolled their own and didn’t follow even basic rules is facepalm worthy. They could have simply used PGP and would have had no issues.

Michael • February 22, 2015 10:19 PM

Could we consider another explanation? The purpose of this particular system is for non-US institutions to make reports. Encrytion tools much stronger than this are likely going to exceed the standards of US export control laws. The IRS isn’t allowed to ignore those laws. Thus, the agency must presume that the foreign institutions are not going to have access to anything better. (Insert eye roll here.)

Nathanael • February 23, 2015 12:48 PM

“I guess the USG is more interested in penetrating and cracking what others are doing than securing the critical infrastructures of their own country.”

Yes.

When done by the IRS, this is merely incompetence.

When done by people at the NSA, CIA, DOD, and DHS, who are supposed to be securing the critical infrastructure of the country,… it’s treason.

There’s only one US government agency I know of which is actually helping secure the nation’s critical infrastructure. It’s the EPA.

Nathan • February 25, 2015 12:24 PM

I can SORT OF understand the “moving the key across operating systems” thing if they’re directly using a file as a key, and that might be affected by endline issues on MS Wordpad versus saner OSes. Now, if they’re doing that with no ASCII armoring, base64, etc, they’re just plain stupid.

As for this being some kind of NSA backdoor, generally their backdoors aren’t totally obvious to anyone who reads the standard after doing a master’s in CS. I’d expect something more like a “convenient” encryption library that leaks data, or uses a given set of 2^45 keys, or, well, anything that can’t be uncovered by skimming the first page of a Google search on “electronic code book”.

The flip side is that WE know that 256 bit AES is undermined by having too few rounds, and I don’t think it’s totally implausible that the NSA knows some way to leverage that in combination with using basically the worst possible settings for the cypher. No IV might be handy if they’re pre-computing some huge structure for use in the attack (which also has the advantage that it would be impossible for Joe Hacker looking for credit cards to save said structure).

Stefan • February 26, 2015 5:12 AM

The IRS IDES user guide at the irs.gov (http://www.irs.gov/pub/fatca/p5190idesuserguide.pdf , p.89) references NIST sp800-38a.

In the definitions section (p.3) it says:
“The confidentiality modes in this recommendation are the ECB, CBC, CFB, OFB, and CTR modes.”
Some non-crypto-familiar clerk might just pick the first one, without knowing about the implications.

Further, the statement in the ECB section (sec. 6.1, p.9 et seq.)is:
“In the ECB mode, under a given key, any given plaintext block always gets encrypted to the same ciphertext block. If this property is undesirable in a particular application, the ECB mode should not be used.”
Maybe someone finds this desireable…. 🙂

Anyway, it seems that someone is just following recommendations without basic knowledge on the topic. Even if the consequences are probably neglectable, I don’t think that’s the right approach to security topics.

Seniorexpat • March 16, 2015 2:44 AM

@ mesrik
@ clive

Here is documention of the claim about SWIFT:
“SWIFT will open a new server in Switzerland for inner-European transactions in September, which would exclude US authorities from accessing these”, 2009

jon • July 9, 2015 4:41 PM

I thought salt was used for hashing. Can someone explain how to use salt with encryption?

Wael • July 10, 2015 12:56 AM

@jon,

Unfortunately “salt” and “IV” are sometimes used interchangeably. Sometimes the term “nonce” is used instead of the word “salt” as well. Salt applies to hashing, IV applies to both encryption and bashing [1], and nonce applies, among other uses, to some modes such as CCM.

And ECB is weak (as clear from the X-rated picture of Tux — X-rated means you can see through) but does have its uses, such as when the clear text is not more than one or two blocks, and the use of an IV is “less convenient”. But generally speaking, ECB should be avoided.

Another possible answer is when you lump hashing and encryption under “cryptographic operations” then IV and salt can apply to the “operation”.

[1] IV for encryption stands for Initialization Vector, IV used in hashing stands for Initial Hash Value.

Asus guy • July 22, 2015 8:02 AM

It’s even worse than encouraging poor cryptography. Now the IRS is encouraging no cryptography whatsoever:

D13. I uploaded a FATCA Report to IDES 3 days ago and have not received a notification about the status of my FATCA Report. Does the XML format cause a problem?

The IRS has identified a specific scenario where notifications are not issued to filers when certain errors are present. A possible cause for a missing notification is XML that is not formatted and is contained on one continuous line. In this scenario, you can reformat the XML into an acceptable format using a variety of online tools, such as XML Pretty Print. The correctly formatted version of the XML can be resubmitted in a new data packet.

The IRS are recommending that IDES users (i.e. banks & governments trying to submit private taxpayer data to the IRS) use some random website to reformat the XML files containing that data prior to submission.

The IRS didn’t even bother trying to find a website which does the reformatting on the client side using Javascript; that one happily POSTs the XML you paste into the form over to the server, without SSL either (no doubt because the poor guy who put that website up as a weekend project never expected a tax agency would tell banks to use it for confidential data.)

Tax Payer • May 23, 2016 2:21 PM

No comment is necessary or sufficient:

https://content.govdelivery.com/accounts/USIRS/bulletins/13fe1c6

“The Internal Revenue Service (IRS) maintains a high standard of confidentiality and continuously evaluates security protocols related to information technology. During a routine review, the IRS decided to update the cipher mode used for encryption from Electronic Code Book (ECB) to Cipher Block Chaining (CBC). The CBC cipher is a stronger algorithm for encrypting data that can be implemented in code or by your software of choice.”

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.