Tag Archives: Data Protection

First, as renowned computer security expert Bruce Schneier first noted in February 2015 (and as we discussed last June), the IRS previously recommended that non-U.S. financial institutions use the insecure ECB mode of AES to encrypt FATCA data before uploading it to the International Data “Exchange” Service (IDES). The above image portrays the IRS’ logo encrypted using the IRS’ recommended settings. Several IDES users pointed out their concerns with that recommendation, but the IRS ignored them, and added the following to the IDES Technical FAQ (the date stamp in later versions of the FAQ falsely claims this was added in June 2015, but the question and its answer actually appeared on the IRS website as early as April):

E15. 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.

Second, as covered here last year, the IRS recommended that financial institutions having trouble due to a bug in IDES should submit their XML files to totally-unencrypted online tools in order to reformat them prior to IDES upload:

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.

As of June 2016, both of these recommendations have been removed. D13 is totally gone and flushed down the memory hole with no acknowledgement of having been there. E15 is also now gone, but a new question E19 appeared in late March 2016, in which the IRS claim to have come up with the idea of fixing their absurd encryption recommendation all on their lonesome after a “routine security review”, with no credit whatsoever given to Schneier:

E19. We heard the IRS is changing the AES encryption cipher mode used during data packaging. What is this change?

The encryption standard used by the IRS meets current ISO standard(s). We continuously evaluate encryption algorithms to improve data security. During a routine security review, the IRS decided to improve encryption by replacing the Electronic Code Book (ECB) cipher mode with the Cipher Block Chaining (CBC) cipher mode. CBC is a stronger algorithm for encrypting data and its adoption will improve the current secure data packaging process. CBC requires an Initialization Vector (IV) for data packaging. Review the IDES Resources web page for more information

I wonder how many financial institutions will change their code to use CBC instead of ECB, but will leave the initialization vector on the all-zeroes setting previously recommended by the IRS (even though setting an IV at all should have been entirely unnecessary back then, as ECB doesn’t use it). If so, that will effectively nullify the benefits of switching to CBC.

I recall that the XML Pretty Print recommendation continued to appear on the IRS website earlier this year. Unfortunately, the Internet Archive did not automatically save any snapshots of the FAQ this year, and I didn’t remember to save it myself manually until today. The most recent previous Internet Archive snapshot is from September 2015, when both E15 and D13 still appeared. Question B11 makes reference to an “April 2016 maintenance release” of IDES; that release may have quietly addressed the line-length bug which caused the IRS to suggest XML Pretty Print as a work-around.

Ironically, XML Pretty Print is operated by a Canadian. I emailed him to point out the issue last year and he replied, but I didn’t hear back from him to get his permission to quote him for these posts.

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.

Continue reading →