The Yin-Yang Of Tokenization, Vendors Now Splitting Into Two Camps
Written by Evan SchumanSeptember 23rd, 2009
In recent months, an encrypted laundry list of vendors has announced products in the so-called end-to-end encryption space and/or the tokenization arena. But this week added two key announcements into the mix, from Voltage Security and a combo rollout from First Data and RSA Security. The reason they’re key is that, for the first time, two of the largest players are offering true differences, ones that speak more to retail security philosophy than anything else.
These two rollouts—from very competitive interests—also happen to agree on something that signifies a maturation of the retail security space. They agree that PCI is likely to insist that retailers deploy some combination of some form of encryption and tokenization, a position that should end months of bickering between the end-to-end vendors and the tokenization vendors.
The philosophical differences come down to how retailers want to—or, more precisely, decide that they need to—interact with payment card data. For the last couple of years, the retail rallying cry has been that the card brands and/or acquiring banks are in a much better position to hold that cyberthief-attracting data than retailers. Getting rid of the card data, in theory, would make retailers less attractive to data thieves, might get them out of all of that nasty PCI paperwork and assessor arguments, and allow them to focus on selling stuff.
The approach from First Data and RSA is a service that takes the card payment information and converts it into a token and then stores the sensitive data in its system. The First Data argument is that this leaves the retailer with no sensitive card data and, therefore, far fewer associated risks and hassles. The position is that the burden of protecting that data is now lifted entirely from the retailer.
The Voltage approach is more of a software package (they like to call it a framework) that lets the retailer control how the data is tokenized, but it’s the retailer that stores and controls that data. The rationale here is that the retailer is the business that accepted the card, so the liability stays with the retailer. As long as the merchant is going to be held responsible, that chain might as well call the shots as to how that data is protected and controlled.
“What happens to the tokens if the provider goes bankrupt or gets acquired?” asked Wasim Ahmad, Voltage’s Vice President, Marketing. “They’re doing it as a service, which means that [that retailer's payment] data will be off in a cloud somewhere. Putting all of the numbers in a vault paints a big target on them.”
Looming behind these philosophical debates is the PCI Council, which is expected to unveil its next version of the PCI guidelines in about a year. This version is almost certain to include guidance about how the council wants retailers to deal with encryption and tokenization. The key issue at play: Will the PCI Council consider a token to be within the scope of PCI? Is it payment card data that is merely masked? Is the fact that these tokens are made from real card numbers—and can easily be converted back into real card numbers at the retailer’s whim—going to be used to justify keeping tokens within scope? And, as a result, will retailers be forced to continue just as much of the paperwork as before?
Although the tokenization methods vary slightly from vendor to vendor, the tokens can’t be converted back through a key or an algorithm. But the software has a way of matching each token to the actual card number, for chargeback and other purposes. The vendors will argue that tokens should be out of scope. But that’s not likely to be an argument that the card brands or the PCI Council will find persuasive.
Let’s look at each offering a little closer.
Pages: 1 2
-J- R
September 24th, 2009 at 9:35 am
The only question about tokenization is “Why did it take so long?” The greatest vulnerability to customer card data occurs when it is in “clear text” format. The sooner it is encrypted, hopefully before it is first recorded, the more difficult it will be to steal. Tokenization based on a private encryption key that is unique for each retailer will reduce the vulnerability of data. Even if some programmer in a particular retailer figures out how to decrypt the data stored in their files they will not have the private keys of other retailers and be able to use customer cards anywhere but their own stores.
But both the approaches discussed here have their merits. While card data needs to be encrypted as soon as possible, the retailer has the need to encrypt other customer data they carry in their databases. Should every programmer be able to read customer names and addresses in their frequent shopper databases? A tool (or framework) that simplifies the management of public and private keys to support encrypting of various data elements would be helpful for everyone.
September 24th, 2009 at 11:56 am
There are many trade-offs between end to end (E2E) and tokenization (TOK).
As this article points out, even within the TOK world, there is a difference between a hosted and an on-premise solution. Like all cloud computing, the sticking point always comes down to security, privacy, and liability. FDR [Editor's Note: We assume this is a reference to First Data and RSA Security] certainly has the ability to provide as strong a security for the token server as anyone, but what will they offer in a contract?
The key concern about TOK is the security of the token server and performance. The security issue is obvious, since it would be the motherlode of card data. The performance issue comes into play any time a client system needs to convert to or from a token. This would be similar to the performance characteristics of going to an external HSM for PIN processing, except the I/O path to token server might be much longer. It would all depend on how often the conversion was needed.
The key concern about E2E is the strength of the card data encryption algorithm. Typically, this is format preserving encryption (FPE) that uses a crypto algorithm like AES in a new mode. Several have been submitted to NIST (http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html) but none are yet approved, either by NIST or ASC X9. It would be terrible to widely deploy an E2E solution, only to find that the bad guys can crack it.
And finally, as the Smart Card Alliance pointed out, why spend a ton of money as a nation on new terminals and systems, when contactless EMV makes the card number worthless? And the main answer is that E2E or TOK can be done on a piecemeal basis, whereas EMV requires adoption by issuers, consumers, merchants, processors, acquiring banks, and the brands. Unless someone finds a value prop that pulls all those entities together, soon, E2E and TOK make the most commercial sense.
September 24th, 2009 at 7:02 pm
There are two big hurdles that the Voltage will need to overcome — price point and PCI scope. This article was the first I saw the $65K price tag and if this is the case, it will make their solution only financially feasible for level 1 & possibly level 2 merchants. PCI scoping wise, a merchant hosted solution, in most cases, does not reduce the risk profile for the merchant since the cardholder data still resides at the merchant’s location. It may help some with specific applications, but overall it’s just moving the risk around within the merchant location.
To me, the First Data/RSA approach has a much broader marketplace because it’s financially feasible for level 1-4 merchants and offloads much of the risk. Shift4 has been in the tokenization arena since the inception of the phrase so we have first hand knowledge of the hurdles that will need to be overcome for any company just stepping into the arena.