Community
Everybody these days talks about Target data breach. It is serious and damaging for such massive company reputation. On top of that there is huge financial liability on Target's shoulders right now. There might be real need for re-issuing those 70 million or so cards (Target will be covering those costs most likely), potential for (real or fake) chargebacks is huge, plus all of the potentially looming civil class lawsuits against Target (lawyers are greedy indeed) which may follow by the people who may feel their personal reputation or identity has been significantly compromised as the result of this. The final cost for Target is measured in billions of dollars most likely. That's unfortunate since it could all have been prevented. Despite all this, some still keep saying "EMV Won’t Stop Data Breaches" like this one (see http://www.raymark.com/2014/01/08/emv-wont-stop-data-breaches-will/). They are right partially (although they are clearly pushing for their product as a solution here - I do not blame them, but feel need to correct slightly ;-).
EMV as currently specified and implemented probably won't eliminate occurences like these, although I believe with its offline PIN verification capability (if enabled of course) it would have at least reduced the seriousness of this particular data breach by an order of magnitude - because in that case Target servers would not have any need to store the PIN data, even in the encrypted form. So why do I think that EMV will help eliminate these data breaches then, you are probably thinking? Well, I believe that the answer is in the 'Enhanced EMV' most likely, in combination with end to end encryption like the article from Shift4 above presents. What does 'enhanced EMV' mean in fact? Current EMV state
Current EMV standard specification is pretty comprehensive. It allows for many different deployment configurations (it is also its biggest weakness in my view since it allows too much flexibility and opportunity to cut corners - which doesn't help at all). However the main strength of the EMV standard lies generally in utilization of the computing power inside tamper proof chip embedded in the plastic card to perform several useful cryptographic operations during the execution of the EMV transaction. First, EMV card must authenticate itself either to the POS terminal (offline card DDA/CDA based on RSA Digital Signature Giving Message Recovery algorithm) OR to the Issuer Host (online card authentication via ARQC cryptogram based on 3DES algorithm). This is very useful capability since it prevents card cloning and counterfeiting, i.e. it ensures that cardholders use something that they 'have'. Second, at least for the high value payment amounts at POS (and also always at ATM when withdrawing money) cardholder must authenticate themselves either to the EMV card (offline cardholder PIN verification - which I prefer in fact) OR to the Issuer Host (online cardholder PIN verification). In all cases PIN should be encrypted - either by the EMV card RSA public key during the offline PIN verification (if card is DDA capable) OR by DES key shared between POS PINPad and Issuer Host (Acquirer also plays important role here in provisioning the key into the secure PINPad entry device). That ensures that the transaction can be completed only if the cardholders prove something 'they know'. (NOTE: Unfortunately EMV standard for some reason allows for unencrypted PIN verification - that should never be used in fact and probably eliminated from the standard) Third, at the end of the EMV transaction the EMV card produces unique per transaction digitally signed transaction record called Application Cryptogram which is based on 3DES algorithm and shared DES key between EMV card and Issuer Host. This cryptogram serves as a proof that the right card and the right card owner (if PIN verification preceded it) have participated in the EMV transaction. Basically it provides non repudiation and replay attack protection. That means that the smart card chip, unlike a magnetic stripe is extremely difficult (if not impossible) to hack; card authentication and PIN verification are performed automatically and objectively by the chip. Moreover, each transaction has a unique ‘stamp’ which prevents the transaction data from being fraudulently reused / replayed if it is stolen from a merchant’s or processor’s database. Protecting customer data must be a top priority for merchants, processors, schemes and issuers alike and despite the insistence by various technology experts that their networks are impenetrable; we’ve seen it happen a number of times, like this massive Target breach. It is true that EMV doesn't provide protection against data theft - it can't and wasn't made for that. For that you have your network experts, firewalls, de-millitarized zones, etc, etc. But the use of dynamic unique per transaction data cryptographically signed and verified between end points, as specified by EMV, ensures that data which could potentially be stolen is rendered useless in the hands of a fraudster. Improvement points to further harden the EMV standard 1. unfortunately the current EMV card application implementations simply provide PAN data in clear to the POS. EMV specification (and what more important implementations) urgently needs to be extended by mandating end to end tokenization - i.e. the EMV card application should produce and provide 'PAN token' to the POS / ATM - instead of real PAN data in clear. This 'PAN token' would look like normal PAN data - i.e. preserve BIN (to preserve Acquirer routing capability) and maybe last 4 digits of the real PAN, but everything else in between should be scrambled by a secure hash function which can only be decoded and mapped to the original PAN by the Issuer Host using the shared symmetric key. This way the merchant and processor systems do not need to change. But they would be storing useless card numbers which could not be used anywhere. PCI DSS cerification scope would be significantly reduced. 2. Processors must also standardize on using end to end encryption between POS and processors host - PCI DSS standard must mandate this as part of the certification in fact. 3. Issuers must ensure that their EMV smart cards are fully capable of the offline PIN verification. For offline PIN verification to work, the smart card chip must be true DDA capable i.e. support RSA asymetric cryptography for PIN encryption between PINPad and smart card chip. For #1 we need EMVco owners (Visa, MasterCard, Amex, Discover, JCB, etc) to stop dogmatically claiming that EMV as-is right now is fully safe and secure - it is not. They must recognize and admit that there is a flaw which needs to be fixed, then get to work and make necessary improvements to the existing EMV specs and standard along the lines of end to end tokenization. Change is not big nor disruptive by any strech of the imagination. It could probably be made fully transparent to everything in between the smart card chip and Issuer Host. For #2 companies like Shift4 can help for sure. For #3 we need card issuers to stop cutting costs on EMV implementations and standardize across the board with DDA capable cards which are capable of offline encrypted PIN verification In other words if EMV is been specified and implemented comprehensively (without cutting corners and costs), the significant fraud reduction ratios could be achieved and sustained. I would argue that if #1-3 are fully implemented as suggested - fraud can be eliminated, and even its migration to the online ecommerce could be made extremelly difficult if not impossible (since PAN tokens would be useless for online commerce) As the result of all of the suggested improvements, the Target data breach and data theft would most likely be a non-story in the end.
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Jamel Derdour CMO at Transact365 - www.transact365.io
10 February
Ben O'Brien Managing Director at Jaywing
07 February
Alex Kreger Founder & CEO at UXDA
Prakash Bhudia HOD – Product & Growth at Deriv
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.