With tax data breaches back in the headlines due to recent Congressional hearings, the IRS is moving to reassure FATCA subjects that they have absolutely no reason to be concerned about data security & privacy and that they should ignore all the wreckers making defeatist comments. Jim Calvin over at FSI Tax Posts notes last week’s update to the IRS’ FATCA International Data Exchange Service FAQ — made a few days after the Senate hearings — which includes this gem. (Hat tip: bubblebustin in comments).
E16. I read in a recent cybersecurity blog that there is a concern the encryption standards being used for FATCA data are no longer current. Is this correct?
No. The encryption process used to protect your FATCA data was assessed by the IRS prior to granting FATCA-related information technology systems the authority to operate. The IRS also assessed a number of security controls which are documented in NIST Special Publication 800-53 Revision 4. The IRS would not have approved IDES for use in transmitting tax information otherwise.
Jim was too polite to draw attention to the absurdity of the IRS’ claim. AES, when used properly, is secure. Unfortunately the IRS is using it improperly. The specific issue here, discussed by that “recent cybersecurity blog” (Schneier on Security back in February), is that the IRS’ IDES User Guide recommends (at page 89, and on the IDES website itself), for “compatibility”, the use of the insecure Electronic Codebook (ECB) cipher mode for encrypting FATCA data.
How insecure is ECB? Wikipedia has a rather dramatic illustration using Tux the Penguin. This image and others like it come up quite prominently on Google if you can be bothered to search for the phrase “is ECB secure” or something similar. They were all generated by a similar procedure: converting the image to an uncompressed format (e.g. PPM), skipping the header, and encrypting the body. Above I followed a similar procedure with the IRS logo: the image on the left is unencrypted, the image on the right encrypted with the IRS’ recommended settings (openssl enc -aes-256-ecb).
To be perfectly clear: what you see on the right is not a joke or a fake drawing made in order to emphasise the point of this post. It is the actual result of encrypting an image using the IRS’ recommended settings. This is the level of encryption that your bank will be using when transmitting your personal data to the IRS.
Why does this happen?
Well, if you read NIST’s publications, you’d know why. The IRS claims they have. As one of Bruce Schneier’s commenters noted, NIST themselves point out exactly why ECB is insecure:
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.
In other words, if your unencrypted data is longer than one block and has a sequence of bytes which appears repeatedly (e.g. a string of all-white pixels, an address, XML tags, etc.), then the “encrypted” version of those bytes will also appear repeatedly in the output. Even the human eye can see the patterns that result; for example, this is why there are vertical lines in the background of the IRS logo above (if I’d used another image whose width wasn’t an exact multiple of the AES block size, you’d see diagonal lines instead, like in the Tux image on Wikipedia). A computer will have an even easier time recovering large portions of the original data without having to know the key.
Initialization vector all zeroes
Aside from recommending ECB, the IRS also states:
Initialization Vector: No Initialization Vector (IV). If an IV is present, set to all zeros to avoid affecting the encryption.
ECB operates one block at a time, without interactions between blocks, so the initialization vector is irrelevant. So the IRS’ “no initialization vector” recommendation doesn’t make things any worse, in that specific scenario. I’m quite sure of course that the IRS is aware of this fact and that the scurrilous accusations of Bruce Schneier’s commenters (“[l]ooks like someone tinkered with the available settings until some rather limited test case succeeded”) are totally false.
But anyway, say the IT staff at a FATCA’ed “Foreign Financial Institution” ignore the IRS’ misleading reassurances, get half a clue, and read on some “recent cybersecurity blog” that ECB is insecure. So instead they switch to one of the other
three-letter acronyms block-cipher modes. At the level of a single message this even superficially appears more secure.
But if they don’t know enough about encryption to understand what exactly the initialization vector is for, they’ll probably leave that on the IRS’ recommended setting. However, if you reuse the same initialization vector and the same key (e.g. for multiple transmissions from the same bank, whether for entities with different GIINs, or in different years), you still have a problem, even with CBC (let alone OFB).
AES (as any block cipher) strifes to be indistinguishable from a random permutation, so any property like C1 ⊕ C2 = P1 ⊕ P2 would be quite bad.
This property (with K as the “key stream bits”) is valid for synchronous stream ciphers, including the one time pad and stream cipher modes of block ciphers (CTR, OFB, and for the first block also CFB), but not for those modes of operation who actually put the plaintext through the cipher, like CBC.
This is why you should never reuse the same key with the same initialization vector for stream ciphers (or reuse the same key at all for stream ciphers which don’t have an initialization vector).
For CBC, the effect of such a misuse is just that identical plaintexts (or actually identical starting plaintext blocks) give identical ciphertexts (identical starting ciphertext blocks). This is still something one doesn’t want, so you should use a fresh random IV for each message even for CBC mode.
How big a deal is this?
Well, most data breaches probably don’t occur due to thieves intercepting insecurely-encrypted data in transit and then decrypting it. It’s much easier for them to hack into one of the badly-administered endpoint systems where that data is stored, whether by technological methods or social engineering or plain old bribery. Absurd recommendations for encryption settings are thus “merely” a symptom of an underlying sickness: organisations which aren’t following best practices on encryption probably aren’t following best practices anywhere else in their computer infrastructure.
The fact that the IRS publishes comments like “Key size should be verified and moving the key across operating systems can affect the key size” with a straight face demonstrates pretty definitively that anyone there who has a technological clue is not having his or her voice heard. Another question in the IRS’ IDES FAQ suggests something similar:
C17. Are there any characters that pose a security threat and should be avoided in submitted XML documents?
Use of the apostrophe (‘), double dash (–), quotation mark (“), and hash (#) symbols are prohibited as they can be used in a security threat and will cause the transmission to be rejected with a failed threat detection error notification. Replacing the characters with an entity reference will still cause a rejection.
Yep, that character blacklist makes me totally confident they haven’t forgotten any edge cases which will leave open yet another giant security hole.
Thus it seems that if I fill out my W-9 form for my bank using Pig Latin, that offers a similar level of security as AES. Maybe I’ll try that with my electronically submitted FBARs this year.
The whole chain is vulnerable.
As you mention, the IT consultant who administers the database can be easily motivated to acquire the data and pass it to bad actors.
Same as any upper-level administrator. In most countries (other than a few virgin-pure locations), top administrators in banks receive their jobs because of their connections—-connections to government factions and connections to black money sources.
FATCA is a danger to Americans. The danger to Americans was created by America.
Thanks Eric! The incompetence of Robert Stack, Mark Mazur and the IRS seems to know no bounds.
Beyond inadequate data transmission encryption, simple theft of FATCA data by tellers and other bank employees could also pose a threat to American citizens living and working abroad. Bloomberg posted an article yesterday on the topic of teller theft of bank account data in the US:
“New York Attorney General Eric Schneiderman, who on Friday warned that tellers and other branch workers have a wealth of client data at their fingertips and managed in a few instances to swipe it. In a letter to nine lenders, he said investigators uncovered identity-theft schemes hatched by tellers at some of the biggest institutions. Hundreds of bank customers have lost millions of dollars, he said.”
Of course, tellers outside the US have higher ethical standards than those in the US ….
If a bank employee steals money from a bank client- doesn’t the bank have to cover for it?
They have set on a course that they refuse to consider any other regardless of the facts. Damn the torpedoes and full sail into the iceberg ahead
Stupid is as stupid does
The IRS preaching encryption is pointless. FATCA data will sit on a bank’s server unencrypted until a low paid bank employee decided to steal it in a sort of steal for order operation. FATCA makes US expats sitting ducks.
That exemplifies how much respect the US Congress has for its citizens living abroad.
The PetroYuan is born.
As China now has currency swap deals with about a dozen major economies, Russia will have places to spend those Yuans. The Yuan’s use will continue to increase worldwide and the dollar will decline.
If the petrodollar supply drops by $900B, as forecasted in the article, how is the US Government going to make up that sort of shortfall? Are they going to wack ex-pats with big fines, try overseas collects, or raise the renunciation fee again? The US is going to have to look into the mirror and say to Homelanders taxes are either going up or we’re going to cut off your Food Stamps or some other government benefit.
The technologically clueless thank you, Eric (and all the participants in blogs around the world who seek the truth).
Cybersecurity a big concern in this newly released annual report from the Financial Stability Oversight Council. No mention of FATCA I could see.
Yes, thanks, Eric. Amazing understanding and work — all you contribute here.
I expect all of this data will end up in Israel but don’t worry they got an NSA memo to suggest they not peek at some things … like that would stop them. The most demented, devious and dangerous country on the planet will likely end up with the FATCA/DATCA goods on every single US person. What could possibly go wrong? Meanwhile tucked inside the same bill that includes the now infamous Sec. 603 are more assurances for expedited US-Israel trade and reassurances that the promotion of BDS will not be tolerated in the USA.
Non-Anglophone bank employees can’t understand why the hell the IRS’ duck-tape-and-baling-wire system is rejecting their FATCA submissions. Their solution? Ask for help on Reddit.
Yeah, this is going to end well …
Oh yeah, here’s how people are dealing with the “no commas no quotation marks” rule:
literal horror show for anyone who’s ever worked in tech
Any idea about the significance of this recent legal memorandum, issued publicly by the IRS?
“FATCA – IRS memo on protection of IDES-provided data
July 20: The IRS publicly released an legal advice memorandum* addressing the IRS legal responsibilities to protect tax return information for electronic data transmitted via the International Data Exchange Service (IDES) under the FATCA regime. AM2015-005 (release date July 17, 2015, and dated June 9, 2015)
*The memorandum is legal advice, signed by executives in the National Office of the Office of Chief Counsel and issued to IRS personnel who are national program executives and managers. The memo is issued to assist IRS personnel in administering their programs by providing authoritative legal opinions on certain matters, such as industry-wide issues. It is not to be used or cited as precedent.
Returns, return information, and tax convention information are categories of information related to taxes generally protected from disclosure under Code sections 6103 and 6105.
The IRS memo [PDF 576 KB] concludes that the protection under section 6103 arises on the inbound transfer of information at the time that the information is uploaded to IDES, and that section 6105 and treaty protections are likely to follow the conclusions under section 6103.”
Purpose of this new IRS legal memo re data? They don’t issue legal advice memos for nothing.