Improve the resilience of EMV against relay attacks

December 17, 2009

After a brief email discussion with Steven Murdoch and Saar Drimer of the University of Cambridge, it seems EMV contains a weakness that makes it less resilient to relay attacks than it could have been.

In such a relay attack the attacker prepares a rogue terminal that is connected to a specially prepared smart card shaped device. This device is inserted in a real payment terminal, at which the attacker wants to pay. The payment starts as soon as a victim inserts her card in the rogue terminal. By the relay attack, the card of the victim will pay for the goods bought by the attacker.

The problem lies in the way encrypted PIN is implemented. According to the standard, the PIN is encrypted against a public key that is retrieved from the chip card, together with a random challenge that also is obtained from the card. This is sent back to the card for verification using the VERIFY command. The problem is that this message is not related to other messages exchanged between card and terminal in a payment protocol run. This means the encrypted PIN can be obtained from the rogue terminal, which means the attacker does not have to type in the victim PIN on the real terminal himself.

There is a solution to this. EMV should set up a real session between a payment card and a payment terminal. Such a session ensures that no messages can changed or inserted in the message stream between terminal and card during a payment protocol run. This could be achieved by running a key agreement protocol between the card and the terminal. This key agreement should be authenticated to ensure that the man in the middle cannot cut into the session. A public key from the card could be used to achieve this. This way the real terminal and the victim's card share a session key that the relaying attacker does not know. The attacker can now truly only relay messages between the genuine terminal (that he doesn't control) and the victim's card. This implies he has to enter the victim's PIN on the genuine terminal.

This adds a little barrier to relay attacks as the attacker has to obtain the PIN from the victim. He could easily do so using the rogue terminal he controls, letting the rogue terminal send the PIN to his wristwatch, say. We could make the attack a bit harder even if we would extend the PIN entry protocol with a user-specific welcome message. Users should only enter their PIN if they see their own personal welcome message. Because this message is also transmitted to the terminal through the session that has been set up, the only way the attacker could get the message to display on the rogue terminal is either to guess it, or to very quickly type it once it appears on the real terminal and send it to the rogue terminal.

In case you spot any errors on this page, please notify me!
Or, leave a comment.