Blog article
See all stories »

Target data breach and EMV

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


Comments: (5)

A Finextra member
A Finextra member 13 January, 2014, 11:52Be the first to give this comment the thumbs up 0 likes

Good thoughts, Milos.

Tokenization per se, the way it is proposed by the scheme, is nonsence: it represent bad user experience and is still open to MITM attacks.

Better way forward: a generic ID, e.g. email address (PayPal style), followed by the user authentication via a smartphone. If smartphone IS part of the equation (that's how the tokens are proposed to be generated), why not use it for more than just a "better mousetrap"?

As for the offline PIN: using smartphones for online out-of-bound (!) PIN entry is a better way forward as the same principle can be extended to e-commerce too...

A Finextra member
A Finextra member 13 January, 2014, 13:00Be the first to give this comment the thumbs up 0 likes

Alex, thanks for your insight. It does seem that you may have not fully understood the proposed tokenization method in my blog. If implemented as suggested there should be absolutely no any impact on 'user experience' ... that's the whole point.




A Finextra member
A Finextra member 13 January, 2014, 13:37Be the first to give this comment the thumbs up 0 likes

Milos, your token idea was clear to me (I think...) - card networks are toying with a similar concept. Entering ever-changing 16-digit token is not what consumers want (or need, for that matter). IMHO.

There are more elegant ways to keep the existing rails and transaction flow, and to prevent more "Targets". That's as far as e-commerce is concerned.

As for physical retail, existing EMV works fine, as long as the same card details - or same details without dynamic authorization - cannot be used for online purchases.

A Finextra member
A Finextra member 13 January, 2014, 18:40Be the first to give this comment the thumbs up 0 likes


I am not familiar with the details of the payment scheme proposed end to end tokenization method, so I can't comment much on its convenience and quality. What I proposed should be used in proximity payments (at POS). POS will get token right from the start from the EMV card. That token will have the identical BIN/IIN value and last 4 digits of the real PAN with everything in between (in fact the consumer account number) dynamically generated (based on current card ATC value, etc).

Now when I think even deeper this may not even require changes to the existing EMV standard - this is an implementation detail of how specific READ DATA APDU is implemented for a specific TAG value. Merchant POS and Acquirer system should not even be aware that they were not given the real PAN value by the EMV chip - because the value they will get will look, feel like real PAN - it would just be useless to be stollen and re-used in online world.

That way Acquirer is able to route the provided 'tokenized PAN' normally to payment scheme and then to the issuer. Only issuer will know how to decode the provided BIN+dynamic_token+last 4 PAN digits into the real PAN and authorize the payment.

What I have proposed is aiming at protecting the physical payment channel from vulnerabilities like the one happened with Target and others as well. Unfortunately as I have stated in the article EMV is not fail-safe since it still provides to the merchant, Acquirer full PAN data 'in clear'.

For online purchases consumers can still use the combination of the real PAN, CVV/CVC and 3-D Secure (or something similar that you have proposed using their mobile phones, etc) ... that would protect from most of the fraud out there.



BTW - Happy New Year ! All the best

A Finextra member
A Finextra member 14 January, 2014, 03:27Be the first to give this comment the thumbs up 0 likes

Offline cleartext PIN or PAN does not matter with EMV. As long as card track data is protected with CVV/CVC (unique value for each of signature panel, mag and chip)  what is someone going to do with this information without your physical card?

Now hiring