Slashdot Mirror
Chip & PIN terminal playing Tetris
Fearful Bank Customer writes "When British banks introduced the Chip-and-Pin smartcard-based debit and credit card system three years ago, they assured the public it was impervious to fraud. However, the EMV protocol it's based on requires customers to type their bank account pin number into store terminals in order to make any purchase. Security researchers at the University of Cambridge Computer Laboratory derided the system as insecure at the time, as it gave access to customer's bank account pin numbers to every store they bought from. Despite these objections, the system was deployed, so researchers Steven Murdoch and Saar Drimer recently modified a straight-off-e-bay chip-and-pin terminal to play Tetris, with a video on YouTube, demonstrating that devices are neither tamper-resistant nor tamper-evident, and that even students with a spare weekend can take control of them. The banks are claiming that this can be reproduced only "in the laboratory" but seem to have missed the point: if customers have to type their bank account pin into every device they see, then the bad guys can capture both critical card information *and* the pin number for the bank account, leaving customers even more vulnerable than they were under the old system."
The potential security problem here is caused by the use of the same PIN for two purposes. You know how you should never use the same password for multiple security-critical systems? Well, that's exactly what some of the UK banks did.
See, EMV security is designed around the assumption that only the card and cardholder know the card PIN. The bank doesn't know it. The merchant terminals see it, but it has no value without the card. In particular, it should be of no use with the bank machine/ATM network.
How then, do you use a bank machine? Well, ideally, you insert your card, enter your PIN to unlock the card, and then the card performs a cryptographic authentication with the bank over the ATM network to identify and authenticate you so you can proceed to perform your transaction. But that requires the ATMs and network to be updated to support the chip card and to use the new authentication protocol.
The other method, of course, is just to use an account number and a PIN, just as you always have, but that PIN *must* be known by the bank's systems, which leads to the banks' dilemma when deploying the system. Their options were:
So, the banks mostly took option 3. I think some of them allow customers to request that their card and ATM PINs be "decoupled".
In theory, this means a malicious merchant can modify their PIN pad to capture the PINs and account numbers, and can then use the information to drain the accounts through the ATM network. In practice, this form of fraud hasn't happened, and it would be fairly easy to track unless the fraudster didn't steal very much -- a pattern of fraud on accounts whose cards have all been used at a particular merchant would be pretty easy to detect.
It could happen, of course, and probably will someday. If it becomes sufficiently serious, then maybe banks will have to abandon PIN synchronization. Hopefully, by then the rest of the world will have caught up and the ATM PIN can be discarded entirely.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
...will be a modification to Tetris to make that damn straight-line block appear more often.
"FDA staff reviewers expressed concern about the number of patients who were left out of the study because they died."
But if someone can put custom electronics in what is supposed to be a tamper-proof shell, people will blindly insert their cards and type their PINs. The issue is not one of terminal software security, but of hardware integrity.
What annoyed me was the shift in liability. The old fashioned "swipe and sign" cards, if they were compromised and somebody nicked your cash then the banks could be held liable and some remittance sought. However - with the new system there is an automatic assumption that you have given your PIN away and hence its your fault and you can he held liable. So if somebody stands behind you, watches you type in your PIN and then follows you outside, mugs you and steals your card - then you can be held liable for not taking care of your PIN number. Also the system seems quite unreliable even now.
That the whole point of this is to demonstrate that if you use the merchant's hardware to enter any personal data, it is *impossible* to be tamper-proof or tamper-evident for sure.
My vision has always been a smart device with a crypto engine, that provides it's own display and entry. It would plug into POS equipment, and tell the POS equipment at first, only enough to identify itself and tell the POS which financial institution to contact.
The financial institution would receive from the merchant the account holders ID number and some info about the transaction (i.e. the amount, maybe an interval if a service, maybe a tolerance if a repeating service charge). The financial institute would look up the customer's public encryption key, and use it to encrypt all that data together with a challenge string, and send that back to merchant.
Merchant relays the encrypted package to the customer smart device. The device then (maybe using a passphrase to decode private key like a pin, but not linked to anything outside the device) uses the private key to decode the data, and display to user what the financial institution thinks the merchant is asking for with a confirmation. If user confirms details, the decrypted challenge is sent to POS and the merchant relays it to Financial institute.
Financial institute upon receipt of a correctly decoded challenge, authorizes the transaction, and gives the merchant an affirmative response with an authorization code that is *only* valid for that specific transaction.
Here, the financial institute *only* has the customer private key, so ripping off that database won't give anyone access to the account. The merchant knows they are getting the money, but isn't left with anything they *could* use to get more money than the customer authorizes directly. The only place that has the private key is the customers smart card, which should *never* allow it to be transferred out (probably should be generated by the card and only the public part uploaded when issued). If using a passphrase for storage of the private key, it even has resistance to physical theft.
For bonus points (actually, I would pretty much demand it), have it somehow able to plug into usb ports for online transactions. Of course, online, the customer and financial institute can talk directly, simplifying some of it, but the model need not be changed much for online stuff). Again, the PC would never get the private key, so you would have to use the device.
I would *pay* an upfront charge to help cover the cost of the device in exchange for such security. If it's half-assed and uses merchant display/entry, or shares the private key *ever* theoretically, I wouldn't.
XML is like violence. If it doesn't solve the problem, use more.
Sorry for the pompous post heading, but the first part is true, I wrote a large part of Tesco's system including about half of the EMV processing component. It's a customised version of what was the world's first integrated EMV system (ie card reader + PC + store level auth servers + central connection to VISAnet, LINK etc).
Whether you should listen to me or not is another matter.
The chip controls the transaction. That's how it goes. The chip decides if it can trust the terminal or the bank based on cryptographic signing operations. The terminal is verified by a process in which it concatenates various pieces of data, performs a crypto op on them and presents the result to the card. The card compares this to its own result (depending on the card it either has one precalculated and uses the same one each time (low security) or does the same calculation itself on a set of data including some session data (better security)).
PIN is encrypted as soon as it is entered and should never leave the device it's entered on in plaintext form, it is presented to the card as a cryptogram for validation.
When a transactioon is presented to the bank for authorisation it is presented with yet another cryptogram so that the bank can validate the card. The response also comes in the form of a cryptogram so that the card can validate the bank.
However, I'll agree, all this is pretty useless if someone can get inside the terminal and intercept the PIN at hardware level. Other than that and the looking-over-shoulder social security hole problem, EMV's pretty bullet proof. Your PIN doesn't ever even get to the PC that's running the transaction.
If you want to know more then the actual standards are available at EMVco, but they're the nearest thing to legalese I've ever encountered as a software Dev. I'm out of the payments game now, but my knowledge should still be pretty relevant, I hope.