Security Coin: ATM Communication

A while ago, I attended a class on PIN and Key Management for Payment Networks. ANSI has laid out strict guidelines (in their ANSI X9 TG-3 standards checklist, ANSI documents X9.8 and X9.24) for how a customer's PIN should be kept secure: how they should be stored on the card (store only the difference/offset of the encrypted PIN value and the natural PIN), what the minimum encryption requirements are (Triple DES), what the specifications of the devices that encrypt/decrypt the PIN are (Tamper Resistant Security Modules), how PINs should be exchanged between various Financial Institutions (exchange keys between two FIs out-of-band AND under the principles of dual control and then encrypt the keys, how should compromised - no - even "suspect" compromised PINs and Keys that encrypt the PINs be treated (securely delete the key, recreate a new key under the principles of dual control and split knowledge and re-encrypt *every* key or PIN that has been encrypted under it! and re-issue cards containing PIN offsets for PINs encrypted under the new encryption key, if applicable) etc.

It was simply awesome. To know that the Financial Institutions do their due diligence is a huge confidence booster. The fact that these guidelines are just that - guidelines, and haven't been strictly enforced by governing bodies is not my biggest concern. Neither is the fact that there are a number of papers out there that talk about the insecurities in PIN translation.

The following, however, is:

The folks at redspin (Brian Hayes, Matt Marshall) analysed ATM traffic and wrote a paper on insecurities in ATM communications.

What you see above is the raw data message format that leaves the atm connected to a network. Cleartext communication. Notice the account number and expiration date. Totally vulnerable to man-in-the-middle attacks. The response message that is supposed to come from the FI, looks something like this: