Hi Stephen
Another mitigating design feature might have been for the EMV card to enforce PIN re-entry for every fresh cryptographic event (the POS transaction, then the CAP code).
Cards I have tested do implement this restriction – they will only respond to the GENERATE AC command twice, during each run. However that doesn't help, because the tampered terminal just stores the PIN, resets the card, and initiates a new transaction without interacting with the customer.
I guess you're showing that once the PIN is entered, the card will sit there and accept multiple cryptographic requests until it's taken out of the reader? Nuts.
Provided you do a software reset, yes. There's not much the card can do about it though, because the tampered terminal can always disconnect power to the card and reconnect it. This is a standard feature of off-the-shelf smartcard readers which implement the CCID protocol.
30 Oct 2009 13:51 Read comment
Hi Stephen,
Isn't this highly unusual behaviour for a POS Terminal? Surely a terminal only ever prompts for the PIN.
The tampered POS terminal behaves exactly like a normal POS terminal. It only prompts for the PIN from the customer. It also requests the two one-time authentication codes (login and sign) from the card, but of course the customer can't see that because the card has no display.
The crook also needs the customer's membership number, and that could be obtained either by compromising the customer's PC, or by a separate targeted social engineering attack.
The best I can think of is if the crook calls up the customer and says "Did you recently make a purchase at X? That's fine; can I please get your membership number to confirm your identity." Banks already do this, so customers shouldn't be worried.
I would have thought that a Man-in-the-Middle attack, or good old phishing attack to garner codes online would be more fruitful
CAP was designed to prevent MitM, because the Barclays card readers show the destination account number and amount for the transaction. Had Barclays not used the same card for both point of sale and online banking, this would have probably worked. However, the purpose of this demonstration was to show that it doesn't.
For the RBS/NatWest system, MitM does work fine, because when customers generate a one-time authentication code, they can't tell what it is for. Criminals are actively exploiting this, so there doesn't seem much point in doing a demonstration.
29 Oct 2009 18:17 Read comment
Thanks for your interest; I'd be happy to clarify.
The "one-time code" is intended to bypass the two-factor CAP authentication. In fact, the tampered terminal implements the disconnected card reader protocol and requests two authentication codes: an "identify" code for login, and a "sign" code to initiate a transfer.
These codes were then used on the Barclays online banking system, which requires the use of the card-reader for both logging in, and performing transfers to new accounts. Notably, Barclays (unlike NatWest/RBS), do not include a nonce in the challenge, so the one-time authentication codes remain valid indefinitely (at least until the customer logs in again).
There is also a social engineering step, where the customer ID must be solicited, either before or after the customer uses the tampered terminal. The customer ID is not a secret, and customers are encouraged to keep it with their bank card, so will be much easier to obtain than the PIN, for example. Alternatively, it could be picked up by a keylogger. In principle the tampered Chip & PIN terminal could ask for it, but I suspect that would raise the suspicions of the customer.
Does this help clarify? We have more details in the academic paper.
Steven.
28 Oct 2009 00:38 Read comment
The full programme is now on BBC iPlayer for the next 7 days, and a clip is also on YouTube.
27 Oct 2009 02:28 Read comment
The BBC have released a video clip, and online article, covering the upcoming TV programme.
26 Oct 2009 14:38 Read comment
Whatever...
Online Banking
Information Security
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.