Defending against wedge attacks in Chip & PIN

August 25th, 2009 at 13:00 UTC by Steven J. Murdoch

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:

Card auth. Card → Terminal: records, sigBANK{records}
Cardholder verif. Terminal → Card: PIN entered
Card → Terminal: PIN OK
Transaction auth. Terminal → Card: transaction, nonce
Card → Terminal: MAC{transaction, nonce, PIN OK}

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:

Card auth. Card → Terminal: records, pubkeyCARD, sigBANK{records, pubkeyCARD}
Terminal → Card: nonce
Card → Terminal: sigCARD{card nonce, terminal nonce}

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:

Card auth. Card → Terminal: records, pubkeyCARD, sigBANK{records, pubkeyCARD}
Terminal → Card: nonce
Card → Terminal: sigCARD{card nonce, terminal nonce}
Cardholder verif. Terminal → Wedge: Wrong PIN entered
Wedge → Terminal: PIN OK
Transaction auth. Terminal → Wedge: transaction, nonce
Wedge → Terminal: Fake MAC

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:

Card auth. 1 records, pubkeyCARD, sigBANK{records, pubkeyCARD}
Cardholder verif. Terminal → Card: PIN entered
Card → Terminal: PIN OK
Card auth. 2 Terminal → Card: nonce, CVMR
Card → Terminal: sigCARD{card nonce, terminal nonce, CVMR}
Transaction auth. Terminal → Card: transaction, nonce
Card → Terminal: MAC{transaction, nonce, PIN OK}

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.

Entry filed under: Banking security, Cryptology

6 comments Add your own

  • 1. Hamish  |  August 25th, 2009 at 21:47 UTC

    There are some errors in the protocol as currently done.

    In your final protocol, Card Auth 1 has the SDA data, not the DDA data.

    It’s also confusing to read it with ‘PIN OK?’ having multiple meanings. Maybe if you restrict it to the yes/no reply from the card and have another field called ‘CMVR’. So the last transaction would then be


    card auth 1: Card → Terminal: records, pubkeyCARD, sigBANK{records, pubkeyCARD}

    Cardholder verif. Terminal → Card: PIN entered
    Card → Terminal: PIN OK? (yes/no)

    Card auth. 2 Terminal → Card: nonce, CMVR
    Card → Terminal: sigCARD{card nonce, terminal nonce, CMVR}

    Transaction auth. Terminal → Card: transaction, nonce
    Card → Terminal: MAC{transaction, nonce, PIN OK?}

    Is that what you meant or have I misunderstood?

    Either way, as to having this implemented in terminals and cards, there would be a huge lead time from my knowledge of the industry. This would involve changes to the DDA spec, which would take ages, then the certification people have to get up to speed, then the software for terminals and cards would have to be modified and certified. Each stage would probably take months if not years. So I can’t see it being a short term fix. I expect CDA would be quicker to deploy than a new proposed change to DDA.

    But fun to play with protocol ideas anyway :)

  • 2. Steven J. Murdoch  |  August 26th, 2009 at 00:24 UTC

    @Hamish

    In your final protocol, Card Auth 1 has the SDA data, not the DDA data.

    Thanks for pointing it out. I’ve fixed this now.


    Is that what you meant or have I misunderstood?

    Yes, that’s what I meant. I’ve tried to clarify the protocol. I was trying to simplify things, but maybe went too far.

    In fact all three “PIN OK” messages are different. The one in cardholder verification is the response to VERIFY, the one in DDA card authentication is the CVMR, and the one in the MAC is the IAD (issuer application data).

    Either way, as to having this implemented in terminals and cards, there would be a huge lead time from my knowledge of the industry. This would involve changes to the DDA spec, which would take ages…

    From my reading, the modification I’m proposing is already permitted by the EMV specification. Cards which ask for the CVMR to be included in the DDA signature should work in existing terminals. The EMV specification also explicitly states that DDA card authentication can take place after cardholder verification, so existing cards should work fine too.

    So I don’t think the specification would need to be changed nor would the certification people would need to get involved (I agree that would take ages).

    Card software wouldn’t need to be upgraded (requesting the CVMR would just need an extra entry in one record — the DDOL).

    Terminal software probably will have to be changed, but only ones which operate offline, because the modification is both backwards and forwards compatible. Merchants who were worried about this type of fraud could roll out firmware upgrades quite quickly, without having to co-ordinate with anyone else.

    It does of course have to wait for the card re-issue cycle, which is long, but this idea at least skips a specification change.

    That said, maybe this change will tickle some bug in cards and/or terminals. In which case this idea won’t get past the interoperability testing stage.

  • 3. Clive Robinson  |  August 26th, 2009 at 22:36 UTC

    With protocol errors like these aren’t you glad Chip-n-Pin is not con tactless (ie readable in your pocket).

  • 4. Mike Bond  |  September 2nd, 2009 at 16:12 UTC

    Don’t worry clive, contactless DDA is coming real soon now, it’s already being trialled AFAIK.

    Mike.

  • 5. sudha  |  September 16th, 2009 at 14:09 UTC

    Hi,
    We are trying to implement DDA. Is this possible on the early data option ( EDO-in vVsa terms) of the card?

  • 6. Steven J. Murdoch  |  September 17th, 2009 at 11:04 UTC

    @sudha

    I don’t have any direct experience with EDO but, as far as I know, this is an issuer/acquirer consideration. DDA card authentication is performed entirely by the terminal, so should not be affected by whether EDO or FDO are used by the acquirer.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

August 2009
M T W T F S S
« Jul   Sep »
 12
3456789
10111213141516
17181920212223
24252627282930
31