Steven Murdoch - University College London - London 26 October, 2009, 14:37 0 likes

The BBC have released a video clip, and online article, covering the upcoming TV programme.

Steven Murdoch - University College London - London 27 October, 2009, 02:28 0 likes

The full programme is now on BBC iPlayer for the next 7 days, and a clip is also on YouTube.

Stephen Wilson - Lockstep Group - Sydney 27 October, 2009, 20:32 0 likes

I actually don't understand the attack (perhaps some technical details were left by the BBC on the cutting room floor). 

The reporter in the video clip says that a 'one time code' is retrieved by the attacker from the compromised retail terminal, and then used together with the name and account number to log on to the victim's net banking facility.

What sort of one time code exactly?  Also, it's not clear if this attack is designed to bypass the unconnected Chip-and-PIN Card reader that might be used at home to authenticate Internet banking logon, or whether it is used against a single factor logon protocol.

Perhaps the attack involves a measure of social engineering as well, where the tampered terminal is prompting the customer to enter Internet related secrets as well as regular card-present transaction details (PIN)?

Thanks in advance for any amplification. 

Stephen Wilson, Lockstep.

Steven Murdoch - University College London - London 28 October, 2009, 00:33 0 likes

Hi Stephen,

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.

A Finextra member 28 October, 2009, 04:49 0 likes

Love your work.

Stephen Wilson - Lockstep Group - Sydney 28 October, 2009, 17:26 0 likes

Thanks Steven.

You explained that:

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.

Isn't this highly unusual behaviour for a POS Terminal?  Surely a  terminal only ever prompts for the PIN.  This is what I meant by Social Engineering: Not only must you tamper with the terminal, but you must also suck the customer into entering Internet-related data at the terminal at the store.

So I don't see this attack as being especially momentous.  Isn't it easily overcome by having the Internet authentication protocol involve a nonce to make the OTP non-replayable?  And obviously educating customers to not enter superfluous details at a retail terminal. 

For these terribly weak CAP implementations where the OTP lasts indefintely and is replayable, I would have thought that a Man-in-the-Middle attack, or good old phishing attack to garner codes online would be more fruitful than opening up terminals and re-programming the firmware (but not as much fun).

Steven Murdoch - University College London - London 29 October, 2009, 18:16 0 likes

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.

Stephen Wilson - Lockstep Group - Sydney 29 October, 2009, 19:16 0 likes

Thanks again Steven.  I see now -- the compromised terminal itself asks the card for the CAP code, under the covers, and sends it back to base. Duh! Pardon my error.

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).  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.

Steven Murdoch - University College London - London 30 October, 2009, 13:48 0 likes

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.