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.
The IRS, duplicitous as well as being grossly incompetent.
Our current Minister for Revenue Diane Lebouthillier and our local revenue agency the CRA has ‘faith’ in the IRS regardless;
……”……Mr. Long, our government takes the matter of privacy protection very seriously. All the information exchanged with the United States is subject to very strict confidentiality rules. The Canada Revenue Agency makes sure that tax cooperation with its partners is fully consistent with the privacy rights in effect in Canada. Information exchange is done electronically, through a dedicated, secure and effective transmission system.
……………..
Protecting the confidentiality of all transmissions is a major requirement for the agency. Protecting privacy really is a priority for the agency and for our government.”
https://openparliament.ca/committees/ethics/42-1/8/diane-lebouthillier-4/
Thanks once again @ Eric. This is an aspect you expose that most of us would not be able to make sense of or follow on our own.
I see the OECD is trying to assure its audience that the CRS mandated financial and personal data is secure;
“…The OECD’s Forum on Tax Administration (FTA) has just agreed a Common Transmission System (CTS) creating the first global bilateral exchange system to operationalise automatic exchanges in a truly transformative way. The cornerstone of the CTS is data security, with leading industry standards of encryption applied to each transmission. ……”
https://www.oecd.org/ctp/global-tax-transparency-we-have-the-tools.htm
Wonder how the IRS standards for encryption and transmission of FATCA data compares to whatever the OECD is touting re the CRS?
The Call for Tenders states the Terms of Reference and the Requirements.
http://www.oecd.org/callsfortenders/CFT%20common%20data%20transmission%20system%20100001411.pdf
This guy is somewhat crazy to even notify them of this. It is very common for people pointing out government systems security flaws (in order to help the government!) to be arrested for hacking.
@pukekonz
Don’t they actually have to demonstrate the hack in order to be arrested? I can’t find any accounts of where arrests have been made for just warning the US government, including someone who used the NSA as a “guinea pig” to demonstrate its system’s vulnerabilities created by the US government itself:
http://motherboard.vice.com/read/a-group-hacked-the-nsa-website-to-demonstrate-widespread-bug-freak
Eric: As always, thank you for your research. I echo Badger’s comment above: “This is an aspect you expose that most of us would not be able to make sense of or follow on our own.”
Eric, you have done so much of heavy lifting on this issue. I am very grateful for your research, expertise and each of your posts here at Brock.
IRS technology is museum worthy.
https://www.taxconnections.com/taxblog/who-uses-56-year-old-technology-the-irs/
See section on data protection and FATCA and CRS conflict with EU provisions as mentioned in this paper;
Avi-Yonah, Reuven S. and Mazzoni, Gianluca, Taxation and Human Rights: A Delicate Balance (September 5, 2016). Available at SSRN: http://ssrn.com/abstract=2834883 or http://dx.doi.org/10.2139/ssrn.2834883
Reuven S. Avi-Yonah, one of the authors of the taxation/human rights paper cited above, is one of the participants in a conference starting today at NYU School of Law. Allison Christians is participating in the same session as Avi-Yonah.
Human Rights and Tax in an Unequal World – Sept. 22-23
http://chrgj.org/event/human-rights-and-tax-in-an-unequal-world/
Thanks for noting that @iota. I see that Canadian prof. Arthur Cockfield will also be participating
http://chrgj.org/wp-content/uploads/2016/09/Human-Rights-Tax-in-an-Unequal-World_Conference-Program-1.pdf
As a refresher for those not familiar, Prof. Cockfield appeared with Prof. Christians before the Canadian Parliament speaking against the enabling leglislation and FATCAnization of Canada;
Christians, Allison and Cockfield, Arthur J., Submission to Finance Department on Implementation of FATCA in Canada (March 10, 2014). Available at SSRN: http://ssrn.com/abstract=2407264 or http://dx.doi.org/10.2139/ssrn.2407264
and
Cockfield, Arthur J., FATCA and the Erosion of Canadian Taxpayer Privacy (April 1, 2014). Report to the Office of the Privacy Commissioner of Canada, April 2014. Available at SSRN: http://ssrn.com/abstract=2433198
See some of the other papers by Cockfield, and by Christians:
http://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=117948#reg
http://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=348301#reg
Hope that the US homelanders who are participants won’t just start from the usual US navel gazing assumption that the US extraterritorial worldview is an unquestionable given right.
“IRS technology is museum worthy.
https://www.taxconnections.com/taxblog/who-uses-56-year-old-technology-the-irs/”
That article’s writer is as offensive as the compliance condors. Just because she found a photo of a 56 year old computer doesn’t mean that the IRS is still using that model. Just because that article’s writer takes a plane flight doesn’t mean that she boards the same model the Wright Brothers built 113 years ago.
The IRS deserves to be pilloried for illegal and stupid actions actually taken by the IRS. Fabricating this straw man only detracts from what needs to be done.
Tangentially related: TIGTA: IRS Exposed 28 Million Taxpayers To Identity Theft By Sending Unencrypted Email
http://taxprof.typepad.com/taxprof_blog/2016/11/tigta-irs-does-not-adequately-protect-taxpayer-information-in-email.html
Or, like I said in the earlier post:
Oh, this is gonna be hilarious:
https://techcrunch.com/2017/12/30/how-a-simple-tech-upgrade-at-the-irs-could-transform-the-economy/
On the bright side, that whole ACA proposal to strip-search and probe you in the bank lobby is about to get a lot more efficient! They can do it once a day and twice on Sundays! (Good thing banks aren’t open on Sundays.)
“An API would allow the agency to provide your transcripts the instant you give your authorization. […] This could cut financial fraud”
It wouldn’t do a thing to cut financial fraud. Monica Hernandez and other minnows (criminal minnows working at the IRS, not innocent minnows like us) were jailed, but the ring leaders are still scot free. The US Department of “Justice” has their own reason for preventing courts from taking jurisdiction over these financial frauds; maybe because they’re harbouring the ring leaders?
Also, which transcripts would credit agencies get? Here’s how IRS transcripts change over time: “This person filed a return but 6 months later or 14 months later there was no return on file” … “We deleted records of the original filing and the or 14 months later destruction of filing” … “We reinstated those records” … “We deleted those records again”. Courts do not care, and the DOJ is still hard at work keeping the victims vicitmized.
“Tangentially related: TIGTA: IRS Exposed 28 Million Taxpayers To Identity Theft By Sending Unencrypted Email”
No problem. The DOJ intentionally violates the Privacy Act of 1974 and 26 USC section 6103 (protection of tax return information) and court rules and the DOJ’s own Criminal Tax Manual by intentionally filing exhibits without redaction, disclosing social security numbers to every identity thief who has an internet connection and a credit card. In 2017 the 9th Circuit ruled that the DOJ did the right thing, when a tax matter is in litigation the DOJ is SUPPOSED TO disclose the social security number to the public.
Eric: “On the bright side, that whole ACA proposal to strip-search and probe you in the bank lobby is about to get a lot more efficient! They can do it once a day and twice on Sundays! (Good thing banks aren’t open on Sundays.)”
Indeed. Or perhaps the API would just be incorporated into the due diligence screening and the “apply online! instant decision” process.
Potentially a very efficient way to decontaminate a bank’s customer database. But perhaps not as attractive to banks as it might have been pre-IGA and pre-CRS.