20 April 2014

Payment Monkey

David Griffiths - gryffle

11 | posts 46,541 | views 123 | comments

PCI DSS Applicability in an EMV Environment

05 October 2010  |  4980 views  |  3

 

Today we have seen the release of the PCI DSS take on PCI DSS Applicability in an EMV Environment: A Guidance Document.

Today, we see my take on it …

This document makes sense, provided one believes all of the nonsense upon which it is founded.  If the foundations are weak the structure will tumble - stand back!

This document refers throughout to "sensitive authentication data and/or cardholder data", but at no point explains why they are sensitive.  There are a few references to potential scams, but they are not particularly sound.  The general flow of the document appears to be accepting of the fact that EMV is safe, but makes the point that it's the CNP, magstripe and PAN Key Entry transactions that are potentially risky.  

The document states that the role of the PCI DSS is not to focus on a particular category of fraud, but only to seek to protect cardholder and sensitive authentication data (and we are expected to accept that the data given is sensitive - the weak foundation referred to earlier) thus limiting the availability of this data to fraudsters.  We have shown on many occasions that if this is EMV data, then it has no value to fraudsters, and it looks like the PCI is taking this on board.  It also reminds the reader that the role of the PCI SSC is to "generate security standards", and that's about where it stops.

You would think then that a PCI DSS document would be strong on security and accuracy.  After all, if the accuracy is poor, surely it would draw into question the basis of the security.  

So …

There is a section on the data elements involved in an EMV transaction, and how this may be used in a fraudulent manner.  This section should be good, but displays a clear and absolute lack of understanding of the EMV landscape.  There are a couple of space-filling tables that contain accurate but irrelevant information alongside information that is clearly incorrect: the expiry date does not come from the Track 2 Equivalent Data and there is no Track 1 Equivalent Data (though Track 1 data is present in discrete fields).

Apparently, captured mag-stripe data, from the card or the transaction data flow, can be used to create counterfeit magstripe cards for use in ATMs.  Woah!  Don't you need a PIN for that?  Psychic fraud perhaps?  

There is a section on fallback (called Technical Fallback here) where the magstripe is used in the event of a chip failure to avoid the risk of the merchant loosing the sale, which in my opinion is entirely acceptable.  The acquiring banks monitor the fallback rates, and the card issuers are also on the lookout for unusual patterns.  No real risk, and a small one to take to mitigate the risk of the loss of the sale.  What is the conclusion here?  Fallback does not present a risk in EMV environments.

The section on PAN Key Entry states that this can occur if a chip is faulty.  In my experience, only one level of fallback is allowed: a magstripe may fallback to PAN Key Entry, but a chip card can only fallback to magstripe.  What is the conclusion here?  PAN Key Entry does not present a risk in EMV environments.

Apparently, some merchants use their EMV terminals to accept remote MOTO transactions, but it isn't clear as to whether this is considered a risk, or not.  

Then there is a section on EMV transaction data that is valuable to a fraudster, and the first candidate is the CVV/CVC, where the CVV/CVC on the chip is the same as that on the magstripe.  The use of the iCVV was mandated from 1st January 2008, which means that as of now, most of the risky cards will have been replaced.  So that's not true.

Deep dip reading comes next: apparently some terminals and ATMs are capable of reading the magstripe whilst the chip card is being inserted into (or pulled from) the slot.  This is absolutely true, but has got absolutely nothing to do with PCI DSS.  What's even more odd is that the obvious solution would be to adopt EMV, in which case the magstripe data would be of limited value (POS devices would demand the use of the chip, and most ATMs would refuse to process the transaction).  So, it might be true, but it has no relevance.

PAN and Expiry data exposure: it is possible for transactions to be authorised only on PAN and Expiry Date.  This is true (especially the "possibly" part).  However, it's only true for Continuous Authority transactions (like insurance) where the first transaction has been authorised properly.  So this is a bit more mis-direction.  

EMV does not protect the confidentiality, nor prevent the compromise of certain transaction elements, which is true, but there is no indication of how this data could be used.  The answer is that it can't, so no score there!   

The section concludes that the rationale for protection is the fact that the data is included in the data that PCI seeks to protect: brilliant! 

The PCI conclusions state that and EMV environment does not automatically fulfil PCI DSS requirements, as though this is the de facto security benchmark.  They go on to say that the PCI DSS does not distinguish between underlying transaction security mechanisms, but seeks instead to protect the PAN and other sensitive authentication data as a goal in and of itself without examining the underlying fraud risk.  They mis-direct the discussion by referring to CNP transactions, which are accepted as a risk, but they make nothing of the fact that there are alternatives to PCI that could very easily be adopted that would severely limit the CNP fraud potential.  A compromise is given, in that whilst EMV is accepted as a significant fraud limiter, it must be implemented with PCI and not instead of it, which seems very much like a vested interest argument rather than one of a payment pragmatist.   

The overall conclusion appears to be that PCI DSS is necessary for non-EMV transactions, and since everyone currently accepts non-EMV transactions, everyone must implement PCI.  However, since it is clearly accepted that it isn't necessary in an EMV environment, surely the sensible approach would be to adopt EMV.  Then it wouldn't matter that I can still clone cards!!

 

TagsCardsPayments

Comments: (3)

Nick Collin - Collin Consulting Ltd - London | 06 October, 2010, 11:00

Nice blog David.

I must say I'm becoming increasingly dubious about the whole PCI DSS bandwagon.  At a very simplistic level, if the US embraces EMV soon, which I believe is inevitable, and the whole world moves to chip and PIN, then I can't see the point in spending gazillions to protect data like the PAN, which is, after all, embossed on the front of my card for all the world to see!

Stephen Wilson - Lockstep Group - Sydney | 06 October, 2010, 11:57

I totally agree.  To treat the PAN as some kinda secret is a fool's erand.  Equally, to put all of one's effort into security policies and promises and audits that essentially seek to hide the PANs -- but still do nothing at all to make systems immune to stolen PANs -- is nuts.  A secure payments system would be designed around an assumption that PANs and personal data will still be stolen. 

The proper pathway to improvement is to protect merchant systems against the replay of stolen or illegitimate PANs.  The solution is technically very straightforward: asymmetric cryptography and chip cards.  A PAN presented from a chip card can be differentiated from a PAN presented by other means, such as by a replay attacker. 

PCI-DSS offers some protection against accidental breaches and against amateur attacks.  But it does little to deter organised criminals, or corrupt insiders, from stealing and abusing account data.

Keith Appleyard - available for hire - Bromley | 06 October, 2010, 13:04

David : thanks you very much for this review.

At first pass through I thought you might be being unfair re definition of "sensitive authentication data and/or cardholder data", but what they should have done for new readers is refer them to page 5 of the PCI DSS.

I then read the (12 page) document for myself, and I agree with all your other points.

I've always been disappointed by the PCI Glossary. In this instance, it isn't even in alphabetic sequence, someone started out that way, then added some as an afterthought. Not every acronym used in the text is explained. A meaningful Glossary does not just expand the 3 letter acronym, but actually explains what it is. Usually means the author doesn't know and can't be bothered to find out.

In turn, as I've often seen with lazy people where I've been employed, so PCI is no different, there are Acronyms in the Glossary which simply do not appear anywhere else in the document, so why introduce them - eg SEPA?

Sloppy sloppy sloppy.

Comment on this story (membership required)
Log in to receive notifications when someone posts a comment

Latest posts from David

Rationalising the Irrational

25 October 2010  |  3704 views  |  2  |  Recommends 0 TagsCardsSecurity

PCI DSS Applicability in an EMV Environment

05 October 2010  |  4980 views  |  3  |  Recommends 0 TagsCardsPayments

Every Little Helps. The Tesco approach to over-limit Fees.

22 December 2009  |  7559 views  |  1  |  Recommends 1 TagsCardsPayments

Niche market for cheques.

16 December 2009  |  3676 views  |  3  |  Recommends 0 TagsPayments

You can't push shit uphill!

11 February 2009  |  4346 views  |  3  |  Recommends 2 TagsPaymentsRetail banking
name

David Griffiths

job title

Payments Consultant

company name

gryffle

member since

2008

location

Hertford

Summary profile See full profile »

David's expertise

What David reads
Payment Monkey

Who is commenting on David's posts