Visa's Retail Token Advice Of Token Value

Visa on Monday (Oct. 5) issued a document to ostensibly help retailers figure out how best to navigate the new encryption and tokenization landscape. But as a practical matter, the document did little beyond rehash conventional wisdom and long-standing Visa and PCI best practices. It felt more like a quintessential psychologist's advice session: "Dr. Visa, what should we do about tokenization?" "That's an excellent question, Mr. CIO. What do you think you should do?"

The document danced around the key issues about which retailers would truly love strong guidance from Visa, ranging from whether tokens could ever conceivably be considered out of PCI scope to whether retailers are actually encouraged to retain such tokens on their own servers.

The only explicit advice that Visa's document gave spoke to issues that have, for all practical purposes, already been decided. For example, the document touched on the encryption technique that many vendors are inaccurately calling end-to-end encryption. Visa has chosen to call that approach—where the card data is encrypted or turned into a token a split second after the card is swiped—Data Field Encryption. (It's not the catchiest term, but let's give points to Visa for refusing to use the inaccurate end-to-end name. At least Data Field Encryption is descriptive and accurate.)

It took the position that Data Field Encryption is viable and worthy of evaluation. That would have been helpful a year or two ago, but it's such a foregone conclusion today as to be of little strategic help.

"While no single technology will completely solve for fraud, Data Field Encryption can be an effective security layer to render cardholder data useless to criminals in the event of a merchant data breach," said Eduardo Perez, global head of data security at Visa Inc. "Using encryption as one component of a comprehensive data security program can enhance a merchant's security by eliminating any clear text data either in storage or in flight." A true statement, but it's hardly one that will prove especially enlightening for retail chain IT execs. Their questions are mostly "which approach" and "how should it be deployed." Alas, advice there was not offered.

One of Visa's leaders on the encryption and tokenization debate is Jennifer Fischer, a Visa senior business leader. Fischer said scope issues eventually would be worked out. But she cautioned against retailers putting too much faith into, well, anything. "We don't want encryption to be viewed as a silver bullet. Both encryption and tokenization may enable a merchant to reduce their scope." A journalism professor once drilled into my head to never use a phrase containing the verb "may" if it could just as accurately be changed to "may not."

(Related story: PCI Columnist David Taylor offers his own take on the Visa report. Is it a tacit endorsement?)

In another nod to the psychologist analogy, the Visa document tried to sound sympathetic to the plight of retailers while avoiding offering any concrete guidance. "The implementation of any Data Field Encryption must be done in a strong and secure way to prevent the compromise of card data." (As Harvard Law Professor Arthur Miller once quipped when presented with a similar truism: "Do you actually get paid for giving answers like that?") The sympathy came in the next line: "With industry standards still in the development phase, that goal can be particularly challenging."

One of the key issues behind tokenization is the optimistic claim that tokens—properly maintained—might be considered out of PCI scope. Although the Visa document didn't explicitly say whether tokens could ever be out of scope, it hinted that this possibility is unlikely. "No single technology can completely solve for fraud. Accordingly, Visa views Data Field Encryption as a complement to, rather than a substitute for, PCI DSS compliance requirements."

It's hard to see how tokens—as currently envisioned—could ever be considered out of scope given the fact that they start out as card numbers and can—at whim—be converted back into card numbers. Most tokens can't be unencrypted or reverse-engineered per se, but lists are maintained to permit the token to be re-associated with the original card data. So if it starts out as having all of the data and can again have all of the data at the whim of the retailer, it seems difficult to envision how tokens could be beyond Visa's or PCI's jurisdiction.

George Peabody, the director of the emerging technology advisory service at Mercator Advisory Group, pointed out another concern associated with tokenization. Although much of the debate today is focused on whether tokens should be maintained by the retailers directly or sent away where a third-party vendor can handle the protection, the token approach can handle a lot more data than simply payment codes. For convenience, such tokens could also store and protect "all of the metadata surrounding the payment," including SKUs, time of purchase, shopping history, what coupons or discounts were used and many other CRM details, Peabody said.

"Enterprise security people need to be thinking about what's adequate when they're judging tokenization vendors. They better be looking at what is convenient and what isn't," Peabody said. Presumably, a retailer that is using a vendor to store and protect the tokens outside of the retailer's network would want to keep nothing in the token beyond the critical payment details, making sure that SKU and other information is not there. But if the chain is handling such tokens internally, it could be very efficient to use the token techniques to consolidate lots of helpful details.

But here's the danger with such a scenario. If a retailer chooses initially to store the tokens itself and then, perhaps a year or two down the road, opts to outsource, will the team remember to go back and strip away all of the non-payment data? Will anyone bother? It's a huge risk, because the tokenization vendors are also likely working for some of that chain's largest rivals and those retailers also have the ability to access that data. Is that not a huge temptation? How much would an unscrupulous Rite Aid manager pay for access to that kind of CRM data about Walgreen's customers? It only takes one debt-ridden employee of that token vendor to enable such a nightmare scenario.Peabody's overall take on the Visa report is that while the document was not especially informative, it was at least a start, albeit a very tentative and vague start.

"The only thing that is significant is that this is the first step by the issuing team to weigh in on encryption at all," Peabody said. "That team has been utterly silent throughout."

Avivah Litan, one of Gartner's top security analysts, said she found the document's significance to be "in what it doesn't say. It doesn't say anything [specific] about encryption. It does say 'use industry standards.' That's what's so significant: It doesn't say anything."

The emphasis on supporting industry standards could be seen as a criticism of some of the proprietary approaches. But that's a hard argument to make given that all of the vendor approaches will have to add on their own value-add, which by definition means there will be some proprietary elements involved.

"The Verifone approach is proprietary and Voltage is not a standard yet, so that is significant," Litan said, adding that none of the vendor approaches has been "blessed by any standards body yet. [Visa] is not giving its blessing. It's 'use at your own risk.'"

One footnote in the report, although not providing any new information, did detail a concrete Visa guideline that is not especially well known: "Two key TDES (112-bits) should not process more than 1 million transactions. In cases where the number of transactions potentially processed through the system using a single 112-bits TDES key greatly exceeds 1 million, three key TDES (168-bits) or AES should be used. Note that key management schemes that greatly limit the number of transactions processed by a single key, such as Derived Unique Key Per Transaction (DUKPT) can be used to ensure that any individual key is used only a limited number of times."