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.

Mike.

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.

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}

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