Defending against wedge attacks in Chip & PIN

The EMV standard, which is behind Chip & PIN, is not so much a protocol, but a toolkit from which protocols can be built. One component it offers is card authentication, which allows the terminal to discover whether a card is legitimate, without having to go online and contact the bank which issued it. Since the deployment of Chip & PIN, cards issued in the UK only offer SDA (static data authentication) for card authentication. Here, the card contains a digital signature over a selection of data records (e.g. card number, expiry date, etc). This digital signature is generated by the issuing bank, and the bank’s public key is, in turn, signed by the payment scheme (e.g. Visa or MasterCard).

The transaction process for an SDA card goes roughly as follows:

Some things to note here:

• The card contains a static digital signature, which anyone can read and replay
• The response to PIN verification is not authenticated

This means that anyone who has brief access to the card, can read the digital signature to create a clone which will pass card authentication. Moreover, the fraudster doesn’t need to know the customer’s PIN in order to use the clone, because it can simply return “yes” to any PIN and the terminal will be satisfied. Such clones (so-called “yes cards”) have been produced by security consultants as a demo, and also have been found in the wild.

Yes cards can be caught at the transaction authorisation stage, because the card sends a MAC (message authentication code), which includes a nonce (so cannot be replayed) and includes whether the PIN was correct. However, the key necessary to verify this MAC is not known by the terminal: it must connect to the issuing bank in real-time. For offline transactions, the MAC therefore will not be verified, and the fraudster will walk out with the goods before the clone is detected.

The problem of the yes-card is well known, e.g. (Chip & SPIN), so to resist this vulnerability EMV includes another option for card authentication: DDA (Dynamic Data Authentication). This has been used throughout most of Europe since their Chip & PIN deployment and is now starting to be used in the UK (SDA cards used to be cheaper, but now the difference is marginal). This has allowed us to see more about how these cards are being used in practice.

For a DDA transaction, cardholder verification and transaction authorisation proceed the same as for SDA. However, card authentication involves some extra steps, because now the card has a public/private key pair:

This fixes the attack of copying the digital signature. Because the clone doesn’t have the card’s private key, it won’t be able to respond with a valid signature of the nonce.

DDA is clearly a big improvement, but it’s not perfect. Note that card authentication happens before PIN verification, and its result still remains unauthenticated. This weakness can be exploited with a “wedge”: a device which sits between the real card and terminal, which can manipulate the messages flowing between them. One attack, which tampers with the cardholder verification stage, works as follows:

Here, although the fraudster enters the wrong PIN for the card, the wedge responds that the PIN has been verified successfully. It also responds with a fake MAC, which indicates that PIN verification succeeded. In this way, someone who has stolen a card can use it for offline Chip & PIN transactions, without having to know the correct PIN. Like yes-cards, the wedge attack can be detected if the terminal goes online, because the MAC check will fail.

The existence of the wedge attack is an unfortunate protocol flaw, which I think was discovered after EMV was rolled out. I have seen a mention in Chris Mitchell’s lecture notes (p16) for the Royal Holloway MSc course, but not a full write up anywhere. Later versions of EMV include yet another variant of card authentication — CDA (Combined DDA/Application Cryptogram Generation) — which partially resolves this problem. However CDA is new, may not work with old terminals, and has some other disadvantages which make it unpopular, so as far as I know nobody uses it (at least yet).

However, it occurred to me that there might be a way to partially resolve the wedge attack, while still being compliant with DDA, and requiring minimal or no changes to the card or terminals. This is because cards can request that the terminal sends them additional information, as well as the nonce, to sign. One item available is the Cardholder Verification Method Results (CVMR), which holds the terminal’s view of whether cardholder verification succeeded, and what method was used (e.g. PIN, signature, etc.) to do so. The full protocol would then become:

If the terminal sends the CVMR to the card, the card checks that it matches its perception of reality before signing it, and the terminal verifies that the CVMR comes back properly signed, then the wedge attack will be defeated. This is because during the wedge attack against cardholder verification, the terminal thinks that PIN verification succeeded, whereas the card thinks that PIN verification was not attempted.

Doing this check of the CVMR does require the DDA card authentication to be performed after cardholder verification, so a change to the terminal may be needed. However, this is incentive-compatible, because the terminal is purchased by the merchant and it is the merchant who is being protected. Changes would probably be needed on the card, so that they request and check the CVMR. This is more tricky because the merchants do not have any direct control over issuing banks, but maybe there would still be incentive as reducing fraud would be in the interests of customers.

Whether these change are actually worthwhile depends on why DDA was rolled out in the first place. Reportedly only 10–20% of transactions are offline, so for most transactions neither the wedge nor yes-card will work reliably. But DDA has been rolled out, so could it be that there is a drive to permit more transactions to be offline? Or maybe DDA is just testing the technology before CDA is rolled out. Here, the card signs the full transaction and so preventing other variants of the wedge attack (e.g. tampering with the transaction so that the terminal thinks the card has authorised a large transaction offline, when it in fact exceeds the card’s limit).

I’d be interested in comments on the idea of including the CVMR in the DDA signature. Could this be supported by cards and terminals? There might be some compatibility issues I’m not aware of, but so far it seems to me that it is a small change which would make it a lot harder to pull off a potentially problematic class of frauds.