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.