In a comment, badger points to an IRS memorandum released last Friday: AM2015-005, “International Data Exchange Service (IDES) — responsibility for data transmitted under Sections 6103 and 6105, and tax treaties”. (KPMG has a summary.) Large sections of the fourteen-page memorandum have been redacted, including a page-and-a-half from a three-page section discussing technical details of IDES. (In the technology world, this is known as “security through obscurity”.) Nevertheless, the memorandum still contains some amusing revelations, such as this, from page 1:
We understand that earlier in the development of IDES, oral advice was rendered by Counsel that IDES was a sufficiently secure means of transmission so that using it did not give rise to an improper disclosure of tax return information.
As first pointed out by actual security expert Bruce Schneier in February (and as we discussed last month), in the IDES user manual the IRS recommended the use of the insecure ECB mode of AES in order to encrypt FATCA bank account data uploads. (As of the time of this post, that recommendation still appears on the IDES website.)
Above you can see the IRS’ logo “encrypted” using these settings. AES, like all encryption, is secure only when used properly; using ECB mode on plaintext which is far longer than the AES block length and has numerous repetitions — like an image with a plain background, or an XML file — does not qualify as proper usage. Apparently someone in the IRS was worried that the suggestion to use these insecure encryption settings could expose the IRS to liability, but rather than asking tech experts to recommend correct settings, they decided it was a better use of IRS employee time & taxpayer dollars to ask lawyers whether it was illegal to recommend incorrect settings.
Even worse, in the latest update to the IDES FAQ, the IRS instructs banks to use totally unsecured-and-unvetted online tools to reformat the FATCA XML files prior to submitting them to IDES. These tools will send the XML file to privately-operated websites with no encryption whatsoever during transit and no guarantee that the owners of the websites will not misuse the data.
The rest of the memorandum includes a lengthy discussion of whether Section 6103 protection arises at the time a non-U.S. bank uploads FATCA data to IDES, or whether protection only begins at the time the IRS downloads the data. (26 USC 6103, “Confidentiality and disclosure of returns and return information”, makes it illegal for U.S. state and federal government employees, and certain other persons with access to return information, to disclose it except in circumstances provided for by that section.) The IRS lawyers weren’t quite sure either way, because ▇▇▇▇▇▇▇▇.
Under the current facts and circumstances, we believe ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ that 6103 protection arises on the inbound transfer of information at the time that the information is uploaded to IDES. Furthermore, we believe section 6105 and treaty protections are likely to follow the conclusion under section 6103. We understand that the IRS will likely act as if the information were protected at upload and that business decision would be conservative and justified under the current state of the law.
(Note that the IRS staff redacted the PDF file correctly. Apparently they learned something from the woes of the TSA and HSBC five years ago. They didn’t simply change the background colour of the redacted text to black, but completely removed the words underneath from the PDF file. They take the security of Office of Chief Counsel memoranda quite seriously, even if they don’t care about the security of U.S. Persons’ FATCA data.)
However, one thing that’s quite clear from the memorandum, despite the pages and pages of blacked-out sections, is that the IRS lawyers believe there is no Section 6103 protection for FATCA information collected by banks prior to its upload. Conveniently, this position absolves the IRS of all responsibility for illegal disclosure of FATCA data by banks, even though it’s the IRS which demanded that banks act as agents of the United States government to hunt down U.S. Persons and collect all this information on them in the first place.
On 14 July, a few days before releasing the above memorandum, the IRS also posted an update to the IDES FAQ. They added questions about currency rounding (A15), enrollment for testing (B9), URL of test environment (B10), confirmation of receipt of uploads (D12), bug causing missing confirmations (D13), who gets a confirmation when a third-party preparer does the upload (F6), IDES enrollment in Model 1 countries (F7), and third-party preparers serving clients in both Model 1 and Model 2 countries (F8).
The answer to D13 is the most disturbing one from a security perspective:
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.
<form method="POST" action="xml-pretty-printer.php"> <p> A simple <em>XML pretty printer</em>. </p> <p> Put XML in the text area below, click the "<i>Pretty Print XML</i>" button, and see <em>pretty printed XML</em>. </p> <textarea name="xml_data" id="xml_data"></textarea> <input type="submit" value="Pretty Print XML" /> </form>
For those of you to whom that means nothing: when you press the “Submit” button, this will send the data you pasted in the form over the internet to the URL http://www.xmlprettyprint.com/xml-pretty-printer.php. Recall that a FATCA data submission has names, addresses, account numbers & balances, SSNs, and other such private data. If a bank pastes its FATCA data submission into this form for reformatting as instructed by the IRS and then presses “Submit”, the data will be sent to the operators of the XML Pretty Print website.
Worse yet, note the URL: http not https. It’s been well-known ever since online shopping began to become popular in the 2000s that you do not send private financial information like credit card numbers to websites which do not use TLS (those which do will have an https address), because the credit card number will not be encrypted, and every single server through which your credit card number passes in between your computer and the website can see that data.
Note that I’m not blaming XML Pretty Print’s operator for any of this. His website’s lack of support for TLS is not due to some error he made, but because he chose not to pay for a certificate. He probably put up the website to be helpful to folks who need to reformat configuration files and other similar things which don’t need to be kept private and secure. He certainly had no reason to expect a tax agency to recommend that banks use his website to reformat XML files full of private financial data, and would probably be horrified if he found out that they had. Also, I have not the slightest reason to suspect that he is a dishonest person or that he has any intention of saving the data he receives through that form, let alone doing anything untoward with it.
The blame lies squarely at the feet of the IRS. Bank employees should not be sending private financial information in plain text over the Internet to the operators of random websites. Yet the IRS is recommending precisely that. Their technical staff do not even have the level of common sense of the average online shopper.
FATCA data theft will cause security threats in U.S.
Thanks to FATCA, banks with poor security are sending threatening letters to — and gathering up data from — accidental Americans who have no practical connection to the U.S. and have never held its passport. Some of these poor folks are now struggling to apply for Social Security numbers for the first time to comply with the “Internal” Revenue Code. And the vast majority of them will use their newly-minted SSN for nothing else besides writing it at the top of IRS forms; they will not notice if someone steals it and uses it to obtain credit, or social services, or even a U.S. passport under their name.
If Homelanders are very lucky, the identity thieves who steal these accidental Americans’ data from insecure FATCA-ed banks — whether by hacking or by offering bribes to bank employees — will sell the data only to economic migrants who need an SSN in order to work in the U.S., and not to violent extremists who want to attack the country. Homelanders may not care that FATCA threatens the security of U.S. Persons in other countries, but perhaps they’ll care if it threatens their own necks?