Comment by randomwalker | Hacker News Reader

Comment by randomwalker | Hacker News Reader

Some background information.

The fundamental reason why this is a big deal is that in the UK, the repercussions of fraud are skewed towards customers rather than the banks. The relevant legal standard is that customers must exercise "reasonable care" with their PIN if the bank is to bear the cost of fraud. Of course, banks always insist that their systems are secure, and that it was the customer's fault. http://www.timesonline.co.uk/tol/money/consumer_affairs/arti...

The Cambridge team has been investigating vulnerabilities in the EMV standard underlying Chip and PIN (ubiquitous in the UK) for a long time.

From 2006: http://www.lightbluetouchpaper.org/2006/03/15/chip-and-skim/

If I understand correctly they first started to find serious vulnerabilities in 2009.

Blog post: http://www.lightbluetouchpaper.org/2009/08/25/defending-agai...

Paper: "Optimised to Fail: Card Readers for Online Banking" http://www.cl.cam.ac.uk/~sd410/papers/optimised_fail.pdf

Media: http://www.youtube.com/watch?v=U1QAnb-wnTs

They escalated that attack in 2010. http://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-i...

Paper: http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.p...

Media: http://www.youtube.com/watch?v=1pMuV2o4Lrw

I don't really understand the logic behind chip and pin cards. Do you really want me to disclose my card and my PIN to a completely untrusted machine a stranger hands to me? How do I know the vendor won't just record both and replay them, charging me for things I didn't pay?

I guess the idea is that recording and copying the PIN is harder than recording and copying a signature.

I am quite certain that the EMV chip, which is the chip on your card, must authenticate the POS machines it talks to. The authentication is done using public key cryptography.

So it's not sufficient just to host a fake machine and expect it to be accepted within the EMV infrastructure (cards, POC machines and backend processors).

Of course, extracting the entered PIN is trivial to do with a covertly modified terminal. (skimming) Short of the card being stolen, that shouldn't let anyone access your account, assuming the crypto implementation is sound. Likewise, the card without the PIN is designed to be equally useless, though support for legacy payment systems partially undermines all of this. I suspect a modified terminal which records entered PINs and clones the magnetic strips would let you withdraw cash from the victim's account via Cirrus/Visa Plus.

Chip cards cannot be "replayed" or cloned, that's why there's a chip in the first place. The chip stores card's private key that is used to digitally sign a (purchase) transaction. Each transaction is a multi-message exchange in real-time between the terminal and the bank and it includes an unique ID generated by the bank, which is covered by the signature. This effectively prevents a replay.

The private key cannot be read from the chip without the use of a tunneling microscope or other hardware exotics. In fact it is not untypical for a chip to have a built-in protection against key retrieval that is set to physically fry the chip. The PIN is used to tell the chip to do the digital signing. No PIN = no signing.

That's how it works in general. This application of the smartcard technology is almost 20 years old, so while there are some variations one could still call it sufficiently mature :grin

Ah, good, I didn't know that the chip could process information. I thought it was just storage. I'm glad to find out it's more secure than I thought, thanks.

Each transaction is a multi-message exchange in real-time between the terminal and the bank and it includes an unique ID generated by the bank

That may or may not be case (there is no way for customers to check that), but the problem is that this encrypted communication is between some third party's terminal and my bank, not between my chip and my bank. IIRC correctly, the protocol in the end boils down to:

- bank asks terminal 'Can you verify that the customer is who he claims to be?'

- terminal asks user for PIN

- terminal asks chip: is this PIN correct?

- chip replies: yes.

So, I have to trust that the terminal will not e.g. put my PIN on Twitter.

Worse, that terminal-chip communication is not encrypted. Hence, it is vulnerable to a man-in-the-middle attack. That is what 'chip and PIN is broken' demonstrated.

Actually, no, that's not how it worked when I last looked at it. At the high-level it was:

- bank asks terminal "Here's a random token, have the chip sign it with its private key"

- terminal asks the customer for the PIN

- terminal feeds PIN into the chip, and this enables signing function

- terminal feeds bank's token into the chip, gets the signature back and forwards it to the bank

What you described looks like something designed by a layman with very basic understanding of the cryptography. I will not be shocked if this was in fact deployed, but I still find it very unlikely.

I reread http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.p..., and things are indeed similar to what you describe. If I understand things correctly, the difference is that the "and this enables signing function" part isn't there. It is enabled by default, and gets disabled only when PIN check fails. That is 'necessary' because the terminal can skip this step if it wants to do a transaction without PIN check.

A man in the middle can hide the "check this PIN" request that the terminal sends from the chip and send a "PIN is OK" reply to the terminal. That way, the terminal thinks PIN check succeeded, and the chip thinks it is doing a payment without PIN check.

Sure, an attacker can't easily sign a fake transaction, but he can compromise the terminal and get hold of the PIN, and then use the PIN somewhere else where a signed transaction isn't required.

This has actually happened: http://business.timesonline.co.uk/tol/business/law/article71...

For the original complaint, see this PDF (via Light Blue Touch): http://www.cl.cam.ac.uk/~rja14/Papers/20101221110342233.pdf

Reply on news.ycombinator.com