5 ms·

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 (pu

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

StavrosK 16y ago
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.
Someone 16y ago
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.
- huhtenberg 16y ago
  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.
  - Someone 16y ago
    I reread http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf 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.
rlpb 16y ago
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/article714402.ece http://business.timesonline.co.uk/tol/business/law/article71...

StavrosK 16y ago

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.

Someone 16y ago

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.

huhtenberg 16y ago
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.
- Someone 16y ago
  I reread http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf 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.

rlpb 16y ago

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/article714402.ece http://business.timesonline.co.uk/tol/business/law/article71...