By Adrian Lane
No, it’s not a Penn & Teller rip-off act – it’s a new credit card format. On August 9th Visa announced that they are going to aggressively encourage merchants to switch over to Chip and Pin (CAP) ‘smart’ credit cards. Europay-Mastercard-Visa (EMV) developed a smart credit card format standard many years ago, and the technology was adopted by many other countries over the next decade. In the US adoption has never really happened. That’s about to change, because Visa will give merchants a pass on PCI compliance if they adopt smart cards, or let them assume 100% of fraud liability if they don’t.
Why the new push? Because it helps Visa’s and Mastercard’s bottom lines. There are a couple specific reasons Visa wants this changeover, and security is not at the top of their list. The principal benefit is that CAP cards allow applications to be installed and run on the card. This opens up new revenue opportunities for card issuers, as they bolster affinity programs and provide additional card functionality. Things like card co-branding, recurring payments, coupons, discounted pricing from merchants, card-to-card gifting, and pre-paid transit tokens are all examples. Second, they feel that CAP opens up new markets and will engender broader use of the cards. The smart card industry in general is worried about loss of market share to smart phones that can provide the same features as CAP-based smart cards. In fact we see payment applications of all types popping up, many of which are (now) sponsored by credit card companies to avoid market share erosion. Finally, the card companies want to issue a single card type, standardizing cards and systems across all markets.
Don’t get me wrong – Security absolutely is a benefit of CAP. ‘Smart’ credit cards are much harder to forge, offering much better security for ‘card present’ transactions, as the point-of-sale terminal can electronically validate the card. And the card can encrypt data locally, making it much easier to support (true) end-to-end encryption so sensitive data is not exposed while processing payments. Most smart cards do not help secure Internet purchases or card-not-present transactions over the phone. What scares me about this announcement is that Visa is willing to waive PCI DSS compliance for merchants that switch 75% or more of their transaction to CAP-based smart cards! Vissa is offering this as an incentive for large merchants to make the change. The idea is that the savings on security, audit preparation, and remediation will offset the costs of the new hardware and software. Visa has not specified whether this will be limited to the POS part of the audit, or if they mean all parts of the security specification, but the press release suggests the former.
Merchants have resisted this change because the terminals are expensive! To support CAP you need to swap out terminals at a hefty per-terminal cost, upgrade supporting point-of-sale software, and alter some payment processing systems. Even small businesses – gas stations, fast food, grocery stores, etc. – will require sizable investment to support CAP. Pricing obviously varies, but tends to run about $1,000 to $1600 per terminal. Small merchants who are not subject to external auditing will not benefit from the audit waiver that can save larger merchants so much, so they are expected to continue dragging their feet on adoption.
One last nugget for thought: If EMV can enforce end-to-end encryption, from terminal to payment processor, will they eventually disallow merchants from seeing any card or payment data? Will Visa fundamentally disrupt the existing card application space?
Posted at Wednesday 10th August 2011 6:20 pm
(7) Comments •
By Adrian Lane
I was reading Martin McKeay’s blog this morning and saw his reference to Visa’s Data Field Encryption white paper. Martin’s point that Visa is the author, rather than the PCI council, is a good one. Now that I’ve read the paper, I don’t think Visa is putting it out as a sort of litmus test on behalf of the council, but instead Visa is taking a stand on what technologies they want endorsed. And if that is the case, Rich’s
feeling prediction that “Tokenization Will Become the Dominant Payment Transaction Architecture” will happen far faster than we anticipated.
A couple observations about the paper:
… data field encryption renders cardholder data useless to criminals in the event of a merchant data breach decryption.
Use robust key management solutions…
Visa has developed best practices to assist merchants in evaluating the new encryption…
Use an alternate account or transaction identifier for business processes that requires[sic] the primary account number…
The recommendations could describe tokenization or format preserving encryption, but it looks to me like they have tokenization in mind. And by tokenization I mean the PAN and other sensitive data are fully encrypted at the POS, and their response to the merchant is a token. I like the fact that their goals do not dictate technology choices, and are worded in such a way that they should not be obsolete within a year.
But the document appears to have been rushed to publication. For example, goal #4: protect the cryptographic operations within devices from physical or logical compromises. It’s the cryptographic operations you want to protect; the device should be considered expendable and not sensitive to compromise.
Similarly, goal #1 states:
Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption.
But where is the “point of encryption”? It’s one thing to be at the POS terminal, but if this is a web transaction environment, does that mean it happens at the web server? At the browser level? Somewhere else? Reading the document it seems clear that the focus is on POS and not web based transactional security, which looks likes a big mistake to me.
Martin already pointed out that the authors lumped encryption and hashing into a single domain, but that may have been deliberate, to make the document easier to read. But if clarity was the goal, who thought “Data Field Encryption” was a good term? It does not describe what is being proected. And with tokenization, encryption is only part of the picture. If you are a web application or database developer, you will see why this phrase is really inappropriate.
Make no mistake – Visa has put a stake in the ground and it will be interesting to see how the PCI Council reacts.
Posted at Tuesday 6th October 2009 4:50 pm
(0) Comments •
By Adrian Lane
I was drafting a post last week on credit card security when I read Rich’s piece on How Market Forces Can Fix PCI. Rather than looking at improving PCI-DSS from a specification-centric perspective, he presented some ideas on improving its effectiveness through incentivizing auditors differently. A few of the points he raised clarified for me why looking at market drivers such as this are the only way we are going to understand the coming security changes to this industry. It’s a good post and highly relevant given the continuing rises in notable breaches and PCI compliance costs for merchants. But more than anything else, for me the post solidified why I think we are having the wrong discussion about the advancement of payment security. We are riding a 20th century credit card processing system that was great at the dawn of the POS terminal, but is simply broken from a security perspective for ‘card not present’ and Internet electronic commerce situations.
Adrian Phillips of Visa was recently quoted as saying “… PCI-DSS has proven to be a highly effective foundation of minimum security standards when properly implemented across all systems handling cardholder data.” That phrase is laced with caveats, and it should be, because if you follow PCI-DSS closely, you hit the minimum set of requirements for basic security with significant investment. It’s not that I am against PCI-DSS per se, it’s just that we should not need PCI-DSS to begin with. We have gotten so wrapped up in the discussion on securing this credit card data and the payment system that we have somewhat forgotten that the merchant does not need this information to conduct commerce. We are attempting to secure credit card related information at a merchant site when it is unnecessary to keep it there. The payment process for merchandise should be considered two separate relationships: One between the buyer and the issuing bank, and the other between the issuing bank and the merchant. Somewhere along the way the lines were blurred and the merchant was provided with the customer’s financial information. Now the merchant is also required to keep this data around for dispute resolution, spreading the risk and cost of securing customer financial information. If I were looking for ways to make my business more efficient, I would be looking to get rid of this effort, responsibility, and expense ASAP!
Merchants must investment massively to prop up the security on a flawed system. If the pace of fraud and breaches continue, sheer economic force will push merchants for an alternative rather than suffer along with increasing expenses and risks. As Brian Krebs recently reported, there has been a 95% increase in the number of credit and debit card fraud cases, with no specific indicator showing a slowdown.
My point with this entire rant? I think we are starting to see the change happening now. Rich’s argument that market forces could improve PCI audits is entirely valid, and we could see slightly improved site security. But if market forces are going to materially alter the security situation as a whole, it will be in the slow erosion of vendors participating in the system we have today, in favor of something more efficient and cost effective. First with Internet commerce, and eventually with POS. Securing credit card data is an expensive distraction for merchants, which directly reduces profits. While many large companies offset this expense with revenue from data mining, the credit card number no longer needs to be present to successfully analyze transaction data. If I was running a commerce web site site I would certainly be looking to external payment processing service like PayPal to offload the liability and need to be party to the credit card data. And as PayPal’s fee structure is on par with more traditional credit card payment services, you get the same service with reduced liability. Looking at the number of small and mid-sized merchants I see using PayPal, I think the trend has already begun and will continue to pick up speed. I am also seeing new payment processing firms spring up with payment models more agile and appropriate to electronic commerce.
I had an email exchange with the CTO of a security vendor on this subject the other day, and the question was raised “Will there be EMV-like smart cards in our future? I doubt it. That type of security helps half of the equation: authenticating the buyer, and given current implementations, only at POS terminals. It does not stop the data breaches or resultant fraud. EMV was a very good proposal that never took off, and while it could be helpful with future efforts, a more likely authentication mechanism will be something like Verisign authorization tokens. This form of authentication (user name/password plus One Time Password) may not be perfect, but far in excess of what we have for credit card processing today, and requires very little modification for Internet transactions.
If market forces are going to drive payment processing security forward, I think this is a more plausible scenario. As always, current stakeholders will strive to maintain the status quo, but cheaper and better eventually wins out.
Posted at Tuesday 9th June 2009 7:13 am
(5) Comments •