PCI DSS Applicability in an EMV Environment

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!!