22 April 2018
Matt Scott

Matt Scott

Matt Scott - RenovITe Technologies Inc

13Posts 69,170Views 149Comments
Finextra community

Business Knowledge for IT

This community aims to provide links, resources, book suggestions, tips and insights to facilitate learning and development of IT professionals in financial services, and to develop a forum for IT professionals to exchange views on various related items.

ATM Shimming and The Death of EMV 2

31 August 2015  |  12268 views  |  3

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. 

 

ATM Shimmer TagsCardsPayments

Comments: (5)

Jason Brooks
Jason Brooks - JSec Consultancy Ltd - Northampton | 18 January, 2016, 12:28

Hello Matt, just stumbled on your article and found a few technical inaccuracies that I felt needed clarity.

You state that the iCVV and CVV use the same cryptographic key.  This is not strictly true, but at the choice of the Issuer implementing cryptography.  VISA for example support the C2K within thier environments, as do MasterCard so an issuer may choose to support seperate keys for their CVV implementation.  However I would argue that in the EMV world the iCVV is infact redundant, see my article here (http://www.thepkf.org/view2.php).

i agree that iCVV uses a different seed, but it is not a "Very Different Seed" as 90% of the data is identical (service code is the only key piece that changes).

 

If issuers enable CVV Checking, i agree they should pick up and detect it is invalid, but that is a moot point.

 

Although the seed data may vary, it does NOT GUARANTEE the CVV values to be different for CVV or iCVV, probablisticly it may be different, however operationally due to the construction of the weak algorithm you do see clashes of iCVV and CVV matching to be about 1 in 20,000 or so

The original Magnetic Strip was designed to be encoded with ASCII and hence the CFS is indeed an =, however when this is encoded by the acquirer to VISA/MasterCard for example this = automatically becomes a D (hex nibble value).

 

The rest of your article I think I feel a blog coming on :D

 

Cheers

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Matt Scott
Matt Scott - RenovITe Technologies Inc - London | 18 January, 2016, 16:47

Thank you for your comment Jason.

Whilst the possibility may exits that independent keys may be used - in my experience - generally most Issuers share the same key for CVV/iCVV Generation and Verification (based on work assingments in EMEA and Asia-Pac regions).

I do not agree that the iCVV is redundant for EMV - I think it still retains a useful function.

I look forward to reading your Blog. 

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Jason Brooks
Jason Brooks - JSec Consultancy Ltd - Northampton | 18 January, 2016, 18:05

Thanks Matt, however your article was misleading suggesting that the iCVV share the same cryptographic key and I know issuers who have segregation and those that don't.

I'm interested in your thoughts as to why iCVV serves a useful function in the EMV world?

The iCVV is a static value, it doesn't change for the lifetime of the card that is issued and can be easily read with simple hardware available on the internet and a few API calls.  In an EMV transaction the ARQC is made up of a number of elements (Note the iCVV is not one of them) and generates an 8 Byte value that is unique per transaction, making replay attacks detectable at the issuing side.

A unique eight byte value is more secure than a static set of digits that can be copied.  Equally if the card was to fallback to MagStripe then the MagStripe CVV value would be used, thus making the iCVV value redundant.

Bottom line it was 1995 technology to solve a late 1980's problem, the algorithm is weak and redundant in the EMV space in the EMV space.

Back to your point on Shims though, I have seen in the real world/operational world the shims manufactured by criminal gangs to be an effictive film that is directly overlaid on the Chip itself and almost undetectable to the average Merchant and Retailer.

Of course in the US which I believe was the initial catalyst for your article, they generally don't use off-line pin in which the Shim is predominantly responsible for but the On-Line PIN, as do ATM's (the vast majority of course use an on-line pin).

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Matt Scott
Matt Scott - RenovITe Technologies Inc - London | 19 January, 2016, 16:09

iCVV Serves a purpose - it enables an issuer to identify if someone has attempted to construct a magstripe card based on the magstripe equivalent data resident on the ICC.  In the early days of EMV implementation many Issuers opted to use the same CVV in both the magstripe and magstripe equivalent data – in these cases it was not possible to detect when a compromise of the chip magstripe equivalent data had taken place.

I agree that ARQC and ARPC are much better at mutually protecting data in the request and response respectively – however I would still argue that as long as we have a Magstripe – Magstripe Equivalent Data and iCVV still serve a useful purpose.

With regards to Shivs – in the long term I think we will see a declining trend for EMV Offline PIN towards a preference for Online PIN – or completely different authentication vectors or composite vectors.  I think there needs to be some careful consideration of the potential of MITM attacks when devices are providing authentication – perhaps with MAC’s of CAVM Results to the Issuer Host to prevent intervention and modification.

 

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
A Finextra member
A Finextra member | 27 July, 2016, 18:38

This is a EMV Skimmer that is able to collect Track 1 2 3 + Pin Direcly from the EMV Chip and it is already in use and for sale take a look at www.emvskimmer.com

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Comment on this story (membership required)

Latest posts from Matt

Demystifying the Omni-Channel confusion

03 September 2016  |  9033 views  |  0 comments | recomends Recommends 0

ATM Shimming and The Death of EMV 2

31 August 2015  |  12268 views  |  3 comments | recomends Recommends 1 TagsCardsPaymentsGroupBusiness Knowledge for IT

UK Mobile Proximity Payments 2015

10 August 2015  |  6243 views  |  1 comments | recomends Recommends 0 TagsCardsMobile & onlineGroupInnovation in Financial Services

Will Host Card Emulation save NFC?

14 August 2014  |  3669 views  |  0 comments | recomends Recommends 1 TagsCardsMobile & onlineGroupInnovation in Financial Services

Pace of Change and Innovation

01 October 2013  |  3629 views  |  1 comments | recomends Recommends 0 TagsCardsPaymentsGroupBanking Architecture

Matt's profile

job title Chief Technology Officer
location London
member since 2009
Summary profile See full profile »
Leading the development of new software platforms and services.

Matt's expertise

Member since 2009
13 posts149 comments

Who's commenting on Matt's posts