A Finextra member 09 September, 2008, 11:52 0 likes

If you read that news article, it says that as part of the agreed settlement, the plaintiffs (VISA and Mastercard) enjoined TJX to promote chip and pin security.

I read somewhere that during the court proceedings, VISA claimed that they were doing all they can to secure cards. This perhaps led to the massive payout settlement of $40.9 million to VISA and $24 million to Mastercard for the 41 million card numbers that got compromised.

How would EMV secure card numbers? From what I read, the TJX breach was related to 41 million card NUMBERS. Without such a breach, one can use a simple program to generate valid card numbers. Carders even have a comprehensive list of issuing banks first 4 digits as well as ranges of numbers for high end accounts.

There are other security solutions that will render such a security breach of no value. VISA and Mastercard have started to trial such solutions over the past few months and these solutions have nothing to do with chip and pin.

Too bad that TJX had to pay such a massive settlement for a security breach that could have been of no value if issuing card companies truly did all they can to secure their issued cards.

Jonathan Rosenne - QSM Programming Ltd. - Tel Aviv 09 September, 2008, 13:10 0 likes

With EMV you do not need to protect card numbers for card present transactions, and for card not present anyhow the bank and the cardholder have limited liability.

The need to protect card number, and the cost involved, could be saved with EMV.

A Finextra member 09 September, 2008, 13:34 0 likes

Jonathan said "card not present anyhow the bank and the cardholder have limited liability"

EMV does not protect against card not present fraud regardless of limited liability.

My point is that when a card number gets compromised, how is a non-emv card less secure than an emv?

Jonathan Rosenne - QSM Programming Ltd. - Tel Aviv 09 September, 2008, 14:04 0 likes

With an EMV card, the card number is not enough. You need to obtain a cryptographic signature from the card to get an approval.

A Finextra member 09 September, 2008, 14:33 0 likes

My question : "when a card number gets compromised, how is a non-emv card less secure than an emv?" was rhetorical.

With a non-emv card, the card number is also not enough (unless you know something I don't).  A non-emv card actually requires online authorisation more so than an emv card.

Hubert O'Donoghue - O-C Group - Dublin 09 September, 2008, 15:58 0 likes

In the TJX case the breach involved the theft of credit card files from servers within the TJX network which were compromised due an insecure wireless implementation. Even if these transactions had been conducted under EMV standard they would have contained card number and expiry date and there are still plenty of CNP sites (regrettably) where that is enough. Cant see how EMV would have helped here

Stephen Wilson - Lockstep Consulting - Sydney 10 September, 2008, 02:08 0 likes

It was asked "How would EMV secure card numbers? ... The TJX breach was related to 41 million card NUMBERS".

Excellent point. One of the most acute problems is that numerical personal data -- the stuff of Card Not Present payments and so many other transactions -- has no innate pedigree.  Credit card numbers can be stolen or simply made up, and e-merchants cannot tell genuine numbers from stolen ones or fakes.  In a vain effort to detect fraud, merchants gather more and more personal data and forward it to clearing houses and third party processors ... only to have it stolen, traded and replayed.  Fighting CNP fraud by checking more personal details is like putting out fire with gasoline.

It is true that the EMV scheme in and of itself wouldn't prevent the TJX breach, nor defuse all forms of ID theft, because the scheme is concerned with terminal transactions.  But better use of the cryptographic capacity sitting within many EMV cards (or equally, SIM cards) can be co-opted to authenticate credit card numbers and other personal data when presented by a cardholder online.  That is, when a number is presented online, the receiver can tell that the number is genuine and has been presented with its owner's consent.  

See Lockstep Technologies' research & development into identifier safety.

It is often said that 'EMV has nothing to do with the CNP problem' and as far as the scheme is concerned that's true.  But I urge smarter use of the chips that EMV has delivered to hundreds of millions of online shoppers, so that alongside EMV, the chips can be used to enhance "safety in numbers".

Cheers,

Stephen Wilson

Lockstep Technologies.

A Finextra member 10 September, 2008, 09:04 0 likes

The information stolen was gathered  by TJX.

They collected it either for marketing or through a lack of trust in the card system. The data is valuable to identity thieves, with or without EMV.

EMV does not protect the counterparty to a transaction unless an EMV reader is used.

Until everyone has an EMV reader there will be a problem with this method. Do we actually expect everyone to have a reader?

At least I can comfortably say that the TJX incident would not have happened nor would TJX or their customers have been at any risk even if all of TJX's transaction data was breached, if they had been using our mobile transaction system.

Hubert O'Donoghue - O-C Group - Dublin 10 September, 2008, 16:32 0 likes

It's so obvious that tokenisation is the answer. If we stop using static card numbers the problem is solved. Simple and perfectly feasible but unfortunately legacy within the banks and the card schemes (not to mention cost) means it wont happen. What extent of fraud will the industry sustain before we bite the bullet ?

A Finextra member 11 September, 2008, 05:23 0 likes

Perhaps there is a solution to the dilemma which fits in perfectly with what the banks generally have now?

Would a neutral third party transaction processing system which easily plugs into any bank's existing infrastructure solve the problem? No EFTPOS infrastructure to pay for or deploy, simply recieve settlement messages that only mean anything to the two banks in the transaction - the merchant's and the customer's.

Not even account numbers anywhere, except inside the bank.

Customers and merchants authenticated in store, and online during the transaction. Both recieve real-time notification of every transaction on their account.

The banks would be free to pursue their own arrangements for settlement, and always know their risk.

The alternative is that someone does it for your customers and you just see the debits or credits on their accounts ...for a while at least - then what?

A Finextra member 11 September, 2008, 09:36 0 likes

"10/09/2008 16:32:26 Hubert O'Donoghue added:

What extent of fraud will the industry sustain before we bite the bullet ?"

WE - who is WE? Defining "WE" in this context is an important step into solving the problem.

A Finextra member 11 September, 2008, 12:16 0 likes

"In one of the first interviews by a top TJX executive following a record security breach, vice chairman Donald G. Campbell told the Globe that the US payment system should follow countries in Europe and Asia that have rolled out credit and debit cards embedded with computer chips. If the cards were in use worldwide, he said, the technology would have ruined a scheme in which thieves stole as many as 100 million account numbers from TJX since 2005, by making the numbers harder to reuse"

Well, with all due respect, TJX should have hired experts in the payment industry to defend their interest in that lawsuit brought against them by VISA and Mastercard. $41 million and $24 million to settle is a steep price to pay for a fault that could be easily fixed by these card schemes. TJX is not responsible for the vulnerability of a card number.

EMV is not the silver bullet that can kill card fraud. Nor can it resolve the vulnerability of a card number.

Stephen Wilson - Lockstep Consulting - Sydney 11 September, 2008, 22:21 0 likes

Dean Procter speculated: "Would a neutral third party transaction processing system which easily plugs into any bank's existing infrastructure solve the problem?"

But why introduce yet another third party scheme, with all the attendant novelty, business risk, fresh complexity in the chain of trust, and costs? 

Our research has led to a far simpler proposition that cuts back on extraneous authentication servers and services, and instead makes use of the cryptographic capacity of chip cards to convey credit card numbers.  The validity of a number can be checked by the merchant server internally, withut having to revert to a third party scheme.  In effect, the merchant server talks direct to the chip.  We've proven such a system using bog standard browser, merchant server and smartcard readers.

Cheers,

Stephen Wilson

Lockstep Technologies

A Finextra member 12 September, 2008, 14:29 0 likes

Why a new one? There isn't any other choice, not for all but a few of the larger banks.  Any other solution makes the (smaller) banks the poor cousin in the transaction and the customer relationship, and touchpoints are almost non-existent if you aren't in the transaction.

The main reason to look for something new is that the old model doesn't work in this century and banks still want customers and to make profits.

As for a 'chain of trust', I think the current 'chain' appears to be missing a few vital links in case you hadn't noticed, particularly the trust bit.

Extraneous servers - in fact there are considerably less servers required, like all the ones used in the EFTPOS and card networks, and Visa and Mastercard may even save on a few indirectly.

Keyword above - required. The object of the exercise is a secure, easy to use and robust system with improved efficiency - but not neglecting that essential link in the chain of trust - the authentication server.

Too long we've had machines verifying that it's the card, not the cardholder - therein lies the problem for any card based solution.

A Finextra member 12 September, 2008, 17:16 0 likes

Dean Procter said : "No EFTPOS infrastructure to pay for or deploy, simply recieve settlement messages that only mean anything to the two banks in the transaction - the merchant's and the customer's.

Not even account numbers anywhere, except inside the bank.

As for a 'chain of trust', I think the current 'chain' appears to be missing a few vital links in case you hadn't noticed, particularly the trust bit.

Too long we've had machines verifying that it's the card, not the cardholder - therein lies the problem for any card based solution."

Payments, whether done with a card or check need to be approved first before they get settled. The breach is in the authorisation phase. I don't see how we can get rid of account numbers in a payment scheme that does not entail the usage of cash.

Regardless of where the authentication server sits, authorisation needs to take place to see if there is money in a debit account or if the credit card account has not passed its open to buy limit, for example.

Well we all agree that there is something missing in the chain of trust. Just look at a simple card payment flow. Consumer uses card, gives the card details to merchant, merchant passes it on to a merchant (acquiring) bank, this bank passes it to the issuing bank to get an authorisation, issuing responds to acquiring bank, acquiring bank responds to merchant. WHERE is the link between the cardholder and the issuing bank? It was never there ! This is that missing link that our system - CARDSWITCH provides. The system authenticates the cardholder and enables the cardholder to set his own user limits, signalling to the Issuing Bank to 'allow' the Issuing Bank to authorise subsequent authorisation request/s. This system therefore enables a cardholder to positively present himself to his issuing bank. 

Because the link we provide between the cardholder and the issuing bank covers this missing link, the effect of cardswitch is universal. Merchants do not even have to participate to make the system work!

Stephen Wilson said "In effect, the merchant server talks direct to the chip. "

That seems to be a strong authentication tool and there are others such as the token based tools - OTP, etc. The problem with any of these solutions is that they do not have a universal effect which then makes the take-up quite a challenge. Merchants might consider your solution only if there are enough smart card readers distributed to consumers. Consumers might consider using this if there are enough merchants....

Marite Ferrero

www.cardswitchtechnology.com

Stephen Wilson - Lockstep Consulting - Sydney 13 September, 2008, 04:00 0 likes

Dean Procter argues for a new model, and that's true of course, but I don't believe we need any new third party scheme.  Existing schemes - CNP payments processing in particular - are not fundamentally broken in my view, but they are tremendously vulnerable to replay attack because they were not built in anticipation of the ID theft vectors that plague the Internet (as opposed to the mail order / telephone order channel that was the archetype for these systems). 

So instead of abandoning CNP processing and replacing it with something new, unfamiliar and complicated by extra third parties, why not extend the longevity of CNP processing by fixing the vulnerabilitiy of credit card numbers to replay attack? 

Lockstep's approach is to leverage current technlogies, notably EMV chips (and also SIMs), so that the pedigree of numbers presented online can be assured and recognised by merchant server software.  This means there is no change at all to CNP rules and card scheme arrangements.  It also means that stolen numbers (as in the TJX case) would be worthless.

I've been in authentication and PKI for 13 years, and over and over I've seen that the kiss of death for a new scheme is not necessarily technical complexity, but rather it is legal complexity or even sheer legal novelty.  It takes years to establish legal confidence in payments schemes; changing schemes, including introducing new 'independent' or 'neutral' players is a really big deal simply because they are new.  How long will it take lawyers to understand, analyse and sign off on the contracts involved in any fundamentally new payments scheme with new backend players (especially if those players are little known startups)??

As Marite observed, Lockstep's proposals involve connected smartcard readers and of course these have been problematic.  But they are coming.  The new Dell E series latitudes even have a contactless reader built in.  I take a long view.  Remember when CDs were first used for read-only storage?  We had a single CD ROM burner at the place where I worked in 1990; it was controlled by the IT Department, you had to book time on it and fork out $50 for a blank disk.  10 years later and CD ROM burners had become completely standard in laptops.  I see smartcard readers going the same way, driven by EMV, national health card and ID schemes, FIPS 201, and by Microsoft who have built smartcard compatibility into multiple layers of their platform.  There are close to a billion EMV smartcards and at least 200 million health cards on issue; 2 billion more will come in India and China.  The plastic card form factor is natural and totally habitualised.  It will not disappear overnight. 

Unlike others in this community, I don't have strident views about whether mobiles are better or worse than cards.  I am quite pragmatic: several billion EMV smartcards will be with us for a long time, and they happen to provide cryptographic capabilities that can be pressed into service to protect personal numbers on line.  If we leverage these resources, then we can extend the longevity of CNP payments processing without any new business models or legal arrangements.  We can simplify the online payments architectures to return to the four cornered model at the core of the payments business model.  No extra authentication servers or extraneous profit making players.

Cheers,

Stephen Wilson, Lockstep.

A Finextra member 18 September, 2008, 01:42 0 likes

Spending years signing off on new schemes hasn't really helped all that much so far.

I'd be the last to suggest anyone adopt scheme where the risks couldn't be ascertained nor calculated, apparently unlike other vendors.

I don't know what the lawyers have been signing off on but it is apparent they either didn't really understand it, or were prepared to accept far greater levels of risk than I might consider.

I don't think it's because I don't have any shares in NFC equipment that I thinks it's an impossibility to deploy an NFC solution which will be effective for everyone or even nearly everyone, at least not before it's compromised and you have to start all over again.

The only people plugging NFC are NFC salesmen. Some of the supposedly smartest companies are fully onto the mobile as the answer and they don't see it as being NFC. Sure - one day it might be another factor in the security equation but alone it won't ever quite be up to the task.

The final secure communications scheme will use whatever is available as an extra factor - so long as it is cost effective. i.e. it increases profits more than it costs (at a lower cost than competitor's methods).

I surveyed merchants regarding the Commbank's NFC trial and nobody was excited about it, especially considering the limit on transactions wasn't even enough to buy a pack of non-premium beer or a couple of bottles of half decent wine, let alone half fill the petrol tank. Imagine getting stuck at the petrol station because you put a couple of dollars over the limit. Sure do two transactions and defeat the purpose of the limit.

Why was the limit so low? Because the risk is so high. Any higher limit will take us back to mobile kleptomania days and consumers wouldn't like it.

I  just don't recommend adopting NFC for low value transactions and make the consumer do something different for high value ones.

Go ahead and knock yourselves out, it'll be a nice novelty for a while and just soften the consumer up for the real thing. It was only a short time ago that banks thought anyone who said 'mobile transaction' was a loony. The first conversation I had with Chris Skinner about it was like talking Martian to a Venusian. How things change.

How long has PKI been around - 13 years? Has it really helped? How many people know what it means?

As for extraneous players - I could argue that everyone from the EFTPOS guy, the card networks - Visa, Mastercard etc, and reader-manufacturers through to the recycled smart-card crusher could be out of work (and out of the transaction) with my scheme. We could make use of Swift though.

 Consumer Bank Merchant - cosy?

It would certainly be a big win for the banks participating - the biggest opportunity they're likely to see this century. One thing is for sure, a little patience will only mean there are far fewer left to deal with.

Easy money. That's my motto. Do it smart  do it easy.

Cheers.

Stephen Wilson - Lockstep Consulting - Sydney 18 September, 2008, 12:03 0 likes

Hi Dean.

I'm afraid I couldn't follow much of your last post.  What's NFC got to do with anything? 

All we know about your proposal, the only things you've ever revealed about it publicly, is that it's phone based, and that it's some sort of new "neutral third party transaction processing system".  My point is that new transaction processing models entail so much legal novelty that regardless of their technical goodness, they scare the daylights out of people. 

To redress online ID theft, I advocate a minimal security model that preserves the underlying payments business model (i.e. four cornered CNP processing) and therefore minimises legal perturbations.  We would get an immense breakthough if we used chips to vouchsafe the pedigree of credit card numbers and other personal ID data, allowing merchant servers to trust presented numbers, 'on their face', and then proceed to process the transaction via orthodox CNP arrangements. That is, no change whatsoever to the backend interfaces between merchants, acquirers and issuers.

Let's concentrate on a minimal problem: restoring confidence in IDs (credit card numbers) online.  For PC browsers, an elegant and increasingly practical solution involves smartcards in connected readers.  For smartphone browsers, let's use the SIM or other on-board crypto processor.  But let's not introduce any new third party processors. 

Cheers,

Stephen Wilson, Lockstep.