Tokenization: Someone Else Gets It

Apparently I'm not in fact insane, but do in fact know a little something about things that don't make much sense. One of those things is the mythical tokenization that has been heralded in marketing hype as the next greatest hope for compliance (see my previous posts on tokenization here and here). Tokenization is, at best, a kludge to fill the gap until proper controls can be implemented. While it has marginal utility in larger organizations that need to support legacy billing platforms, that utility should diminish with time.

The latest epitaph in this thread comes courtesy David Taylor, founder of PCI Knowledge Base, in his article "Tokenization vs. end-to-end encryption" over on Computer World. Following are some choice quotes from the article with my comments interjected.

"With E2E encryption a company encrypts the data at the entry point (the point of sale [POS], the e-commerce payment software and the call center software) and the data remains encrypted throughout the process of passing it to the acquirer. The card number is never stored unencrypted by the merchant."

This statement strikes me as being a bit odd. PCI DSS requires the data to be encrypted in storage. Tokenization solutions maybe address this a little bit, as does this so-called "end-to-end encryption" - but let's me honest here, this is what orgs are required to do, encrypt data at rest. I'm never quite sure what to make of statements like this, really. Is there confusion about encrypting data?

"The other key point of E2E is that some companies are focused on an enterprise view of end-to-end, rather than defining one of the endpoints as the acquirer."

I've been somewhat bemused by all this talk of "end-to-end encryption" because it seems to mostly be hot air and pure BS. This comment just further solidifies my thinking. It may be end-to-end within the enterprise, but it's not truly end-to-end, because the data would need to be encrypted at the end-points. In true E2E the merchant would never be able to see the cardholder data because it would be encrypted to a value that could not be retrieved. Of course, implementing this in the real world may be challenging, but that's a whole different line of thought...

"However, in our research, we haven't found any large companies that have been able to completely eliminate or outsource card data even though they implemented tokenization."

I like this quote because it basically says "tokenization is a weak kludge that isn't even particularly feasible." For whom the bell tolls...

"Bottom line: Our research suggests that end-to-end encryption and tokenization will likely exist side-by-side in nearly all large and most midsize businesses for the next two to three years. Suggesting that one can take the place of the other does not take into account the reality of the large, multi-channel merchant or service provider."

This comment begs the question, why spend any money on tokenization? As far as I can tell, the only answer is to centralize sensitive data as an interim step while bringing legacy billing systems into conformance with applicable standards like PCI DSS. This is, however, a kludge at best and not an end-goal solution.

Overall, I found the honesty in this article refreshing. Perhaps we will see a return to saner thinking soon. At least until the next version of the PCI DSS comes out in 2010. :)

About this Entry

This page contains a single entry by Ben Tomhave published on August 17, 2009 12:49 PM.

Black Hat / Security B-Sides / Defcon Thoughts (finally) was the previous entry in this blog.

Defensibility and Recoverability is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives

Pages

  • about
Powered by Movable Type 6.3.7