Yesterday, the Dutch TV programme “Goudzoekers” featured Saar Drimer and me demonstrating a relay attack against the recently introduced Chip and PIN system in The Netherlands. The video can be found online, in both Windows Media or Silverlight formats as well as Flash below. The production team have published a synopsis (translated version) on their blog, and today there have been some follow-ups in the press, for example De Telegraaf (translated version).
The Dutch card we used in the demonstration had a number of extra security features, compared to UK cards:
- Dynamic data authentication (DDA): Static data authentication (SDA) cards common in the UK, can have their chip cloned and used in offline transactions. DDA resists this vulnerability, at the cost of making cards slightly more expensive.
- Encrypted PIN: With UK cards, the PIN entered by the customer is unencrypted as it is sent to the card, leaving it open to being eavesdropped by a tampered terminal. The encrypted PIN feature prevents some types of terminal tampering attacks.
- iCVV: Until recently, UK cards contained a full copy of the magnetic strip on the chip, which meant that someone eavesdropping on communications could create a cloned magnetic strip card. The Dutch card contained some of the magnetic strip details on the chip, but not all of it (a feature known as iCVV).
However, despite these enhancements the relay attack still works, just as it did in our previous demonstration for BBC Watchdog in 2007. This demonstrates that one of the common misconceptions about the relay attack — that DDA cards will prevent it — is not true. The only feasible defence is distance bounding, which we described in our academic paper, but which no smart cards currently support. The relay attack also does not depend on magnetic strip transactions still being supported, nor does encrypted PIN prevent the attack.
For these reasons we were fairly confident that we could perform the demonstration, and left for The Netherlands last week with our equipment in tow. However, things did not go as smoothly as we hoped because the terminal behaved slightly differently to the UK ones we experimented with, and some of our hardware also developed problems during the testing process. The hardest to fix was that the terminal was very sensitive to latency introduced by interference on the wireless link. We couldn’t get our demonstration working by the end of the first day, but thought we could resolve the problem in software, and the production team decided to go ahead with the filming as planned the following day, and hope that our fix worked.
One change we were considering making was to allow the “criminal” using the fake card to enter in the wrong PIN. This would avoid the inconvenience of having to send the PIN entered by the “victim” to the earpiece. It is possible to do this because the genuine terminal sends the PIN to the card, not to the bank, so the fake terminal can just substitute in the correct PIN as entered by the victim. We implemented this, but only for unencrypted PIN, because we didn’t realise encrypted PIN was in use (the UK is still considering it). Implementing it for encrypted PIN is more complicated, because it requires replacing the incorrect PIN with the correct one encrypted to the card’s public key which we capture (along with the random challenge) during the beginning of the transaction.
In the end we decided not to do this, because the other problems had meant we spent the whole day trying to debug the problems we encountered, and had to spend the evening designing the work-around for the timing issue. Having been awake since 5am, by the time we were finished the the fixes, we didn’t feel confident enough to correctly deal with the subtleties of proprietary RSA padding modes necessary to perform encrypted PIN. We were also conscious of the fact that if we got it wrong three times in a row, we’d lock the only card we had available for testing.
Fortunately, the work-around for the timing issue fixed the problem, so we could go along with the filming, but we still had to send the PIN via the earpiece. This might have been one of the reasons that the Dutch Banking Association (NVB) said the attack was “complex and cumbersome”, in their press release (translated version). It should be noted however that criminals who aren’t working on such a tight schedule could take the time to implement the PIN-substitution feature for Dutch cards too, making the attack more feasible.
Update (2009-12-19): Jeremy Kirk from IDG News Service has published an article “Upgraded Dutch Payment Card Still Vulnerable to Relay Attack” related to our demonstration.
Well done chaps, looks like it was challenging to do all that working against the clock, and interesting to read this technical summary of the issues you encountered.
It brings rather vividly to mind that when we were first considering relay attacks in 2006 that a chap from a POS vendor contacted us and told us we were talking nonsense and technically wrong… that the timing constraints were so tight that a relay attack that might sound good in theory just would be near impossible to pull off in practice without a really expensive custom radio link etc.
At the time I just poo-pooed his private advice, and indeed a year or so later the demo was up and running and really did work. But maybe he knew something we didnt at the time… that some terminals were pretty sensitive to timing. His conclusion was still ultimately wrong, but this at least explains in my head why this chap so earnestly believed that it wouldnt work.
Anyhow, thanks for posting the synopsis.
Mike