Sequels are never as good as the original. For the second time in ten years I am drawn to yet another media frenzy concerning the apparent premature death of EMV. Really?
The story surrounds a hardware attack in Mexico where the insertion of a “Chip Skimmer”, or “Shimmer” as they are now being coined, fitted between the ICC smartcard reader and the consumers EMV card inside the ATM’s mechanised card reader. The device then
captures the request/response communication conversations (C-APDU and R-APDU) between the ATM Terminal’s EMV kernel and the consumers EMV smartcard. This “shimmer” can be coupled with a pinhole camera – in the hope that lax consumers may not shield their
PIN entry – therefore further exposing the potential misuse of captured card data.
As part of the information exchange between the card and the terminal there are several data fields that are of particular interest to a fraudster – most notably Tag 57 (Track 2 Equivalent data). Contrary to popular opinion this data is not an exact copy
of the magnetic stripe track 2 data. For example in the genuine magnetic stripe an equals sign (=) is used as a field separator but in the Tag 57 Track 2 equivalent data this is replaced with an alpha character (D). Additionally in the genuine magnetic stripe
there is a Card Verification Value (CVV) encoded in the Issuer Discretionary Data – in the Tag 57 equivalent this is replaced with an Integrated Circuit Card Verification Value (iCVV). Although the CVV and iCVV share the same Cryptographic Key – they use
very different seed data which guarantees them to be generated as different values. If implemented correctly an Issuer Authorisation host ‘should’ detect if someone has skimmed Tag 57 data and constructed a fake Magnetic Stripe with the iCVV instead of the
CVV (they might be smart enough the change the D to an = but unless they have copied the magstripe they will have the wrong cryptographic check value). In cases where this is detected by the Issuer Authorisation host it is recommended that you suspend/block
the card and contact the genuine cardholder to arrange card replacement as it is suspected their card has been compromised.
In the original initial phases of EMV rollout (early 2000’s) in the United Kingdom Issuers did share the same CVV on the magstripe and Tag 57 – when this type of fraud was detected the iCVV was introduced as a measure to prevent this. As a consequence –
valid magnetic stripe data cannot be reconstructed from captured EMV chip dialog between terminal and card.
It should be noted that the use of a shim does not: (i.) expose PIN data (use of plain-text PIN’s for offline-PIN verification at POS is now forbidden); (ii.) expose cryptographic keys; (iii.) expose data that can generate a valid magnetic stripe card; (iv.)
enable fraudsters to clone an EMV card.
This isn’t a story about the Death of EMV – it is more focused on poor implementation of EMV and not learning and evolving from previous mistakes. Focus on best practices around the data parameters used in the personalisation of EMV cards and the business
logic in issuer authorisation hosts or card management systems.
As a final closing remark – there was also a media scare surrounding the fact that some reporters had managed to capture card data using a “contactless skimmer” and apparently conducted e-commerce transactions with the captured card data (the CVV2 cannot
be compromised via contact or contactless EMV interfaces – as it is physically printed on the rear or face or the card). Basically some e-commerce merchants were apparently accepting transactions without CVV2 Card Verification, AVS Address Verification or
3DSecure Verification. Whilst the e-commerce merchant may have let this through – and the Issuer Authorised it – the only person exposed in this is in fact the merchant. By accepting a transaction with no verification of card, cardholder or billing address
they are exposing themselves to the high likelihood of a chargeback/dispute – whereby a consumer will be refunded for any fraudulent transactions. In theory – neither the e-commerce merchant, acquirer or issuer should have allowed this to occur – but again
– it does not demonstrate that EMV is broken – just that implementations are weaker than others and if best practices are followed these incidents will not occur.