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.
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 🙂
@Hamish
Thanks for pointing it out. I’ve fixed this now.
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).
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.
With protocol errors like these aren’t you glad Chip-n-Pin is not con tactless (ie readable in your pocket).
Don’t worry clive, contactless DDA is coming real soon now, it’s already being trialled AFAIK.
Mike.
Hi,
We are trying to implement DDA. Is this possible on the early data option ( EDO-in vVsa terms) of the card?
@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.
There is an error in how you explained transaction authorisation by DDA cards. DDA cards does not use MAC to authorise a transaction. DDA uses digital signature so that the terminal can locally verify the transaction.
The terminal issues INTERNAL AUTHENTICATE command (including the concatenation of the data elements specified by the DDOL according to the rules specified in section 5.4 of Book 3) to the DDA card which returns digitally signed transaction data as response and not a MAC.
As this digital signature can be verified locally using the card public key, wedge attack on DDA card will not work.
The author is right . INTERNAL AUTHENTICATE is only used to verify the authenticity of the card The transaction authorisation is done by applying MAC over the transaction which can be faked by a fraudulent card performing MITM if the transaction is taking place offline.
Faking offline transactions with DDA cards:
With a genuine DDA card, a terminal can still be fooled into accepting a fake offline transaction.
Again, the root cause that makes this attack possible is that the terminal does not have the
shared key used to compute the MAC in the cryptogram. It was clearly a flaw in the design
of DDA: if the card can do asymmetric crypto and has a private key with an associated
certificate, then there is no good reason why should not use this key to sign transactions.
How does CDA partially solve this problem?
CDA happens later on in the transaction flow and so more information is available. Specifically, the CDA digital signature can include the card’s results of PIN verification and so allow the terminal to detect if its view of the PIN verification status matches that of the card. Of course, whether this defence works depends on whether the results of cardholder verification are present in the data signed by the card, and whether the terminal does anything with them. We know from the No-PIN attack research, subsequent to this blog post, that not all security checks are done properly.