When the soothsayer in Shakespeare’s Julius Caesar uttered the immortal line “beware the ides of March”, warning the Emperor of his impending death, he was of course referring to the 15th day of March. This is ironic enough, given that March 15th is the US reporting deadline in the Chapter 3 QI world. However, it is the 11th of July that should be of concern to those who submit FATCA XML documents via IDES. IDES is the acronym that stands for the International Data Exchange System and is the tool that Participating FFIs (Foreign Financial Institution) in non-IGA markets and governments in IGA markets use for exchange of tax data under FATCA. The following was issued by the IRS a while ago.

“Beginning July 11, 2016, the IRS will change the cipher mode from Electronic Code Book (ECB) to Cipher Block Chaining (CBC) and IDES will no longer accept data packets encrypted with the ECB cipher mode”. – IRS FATCA News, 1st June.

In layman’s terms, from July 11th, IDES submissions need to be protected with a different, more secure form of encryption algorithm. While on the surface this may seem like an entirely positive move, there are potential pitfalls that Host Country Tax Authorities (HCTA) and Financial Institutions in non-IGA markets need to be aware of.

Everything You Never Wanted To Know About Block Ciphers

The IDES file transfer system uses an encryption mode of operation called Block Cipher. This is a method of encryption in which a secret key and an algorithm are applied to small blocks of data to produce encoded text. Both the person encrypting the data and the person decrypting it need a copy of the key, making it difficult for anyone that intercepts the message to decode it. Fig.1 provides a visual example of what these blocks look like.

There are many different types of Block Cipher, but in relation to IDES we need only concern ourselves with two; Electronic Codebook (ECB) and Cipher Block Chaining (CBC). ECB is the encryption methodology that has been used with IDES since its inception, which is now being replaced by CBC.

Electronic Codebook is the simplest form of Block Cipher encryption – it divides the message into blocks and encrypts each block separately (see Fig.2). ECB is considered a weak form of encryption, as repetition in the message is reflected as repetition in the encrypted text. Looking at Fig.1 again, you can clearly see the repeated pattern in the encrypted text where the word ‘institution’ is used. In practice, this makes it substantially easier to spot patterns in the data, and therefore decode the information within.

Cipher Block Chaining on the other hand uses the encryption of one block to modify the input of the next (see Fig.3). This means that each block of data is dependent on all of the blocks before it, making the message much harder to decode for anyone without the key.

At this stage you may be wondering “what does this all mean?” From a risk management perspective the answer is clear – the IRS has listened to criticism of the data security weaknesses of the IDES platform and has reacted by implementing a more robust encryption methodology. However, from an operational perspective the change in cipher mode represents a need to update systems and processes for those effected.

What Does This Mean For IDES Users?

For the FFIs in non IGA markets and HCTAs that rely on IDES, the change in encryption algorithm means a change in software. How much impact this will have on any given institution will largely depend on the data packaging software they currently use.

The IRS provides a “kit of parts” data packaging solution in the form of sample code and related assets that can be assembled within the .Net, Java or OpenSSL frameworks. The sample code has already been updated to reflect the change to CBC encryption, and is available via Github. Institutions that have employed the IRS data packaging solution to prepare and encrypt their data for IDES filing will now have to update the code to the latest version. Evidently this is a technical task that is likely beyond the scope of those responsible for dealing with IDES submissions. For institutions with plenty of IT resource, this should pose little worry.

Institutions that have decided against using the IRS data packaging solution will have either opted for an off the shelf third party product, or produced their own software in house. In either case, establishing whether the software is capable of encryption using the CBC cipher mode should be a priority.

Ultimately, whatever tools and processes are in use, effected FFIs and HCTAs need to act quickly to ensure continuity of use of IDES. As of July 11th, the IRS will reject any IDES filing that uses the old ECB cipher mode. The IRS has issued an updated information sheet regarding data preparation using Cipher Block Chaining and this should be the first port of call for anyone that is effected by the change.

One Step Forward…

The change in cipher mode will undoubtedly cause headaches for some institutions. However, the increase in data security provided by Cypher Block Chaining is significant. Against a background in which entities are intercepting and harvesting unprecedented quantities of data from the internet, this can be seen as a progressive move. However, one has to ask why a weak system was implemented in the first place and what other changes are in store for already confused IT departments. In the larger context of GATCA, the OECD also has standards for data encryption. Clearly cyber-security is a key issue for these relatively fledgling regulations. With 10,000 permutations of data exchange each year, just within the OECD ecosystem, and knowing the type of data within each packet, these data exchanges will be ultra high value targets.