3 ms·
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 w
by 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 agoI 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.