Data Security Slugfest: Tokenization Vs End-to-End Encryption

GuestView Columnist David Taylor is the Founder of the PCI Knowledge Base, Research Director of the PCI Alliance and a former E-Commerce and Security analyst with Gartner.

In a land "Beyond PCI," there's trouble brewing. Issues involving everything from tokenization to end-to-end encryption are being debated and the PCI SSC is hiring a consulting firm to look into the implications of these (and other) technologies and processes.

This all raises the issue of "should retailers wait for the PCI SSC to 'bless' or integrate so called 'beyond PCI' technologies into the standards?" My answer is a profound "no." There are too many changes in IT happening too quickly for an organization to wait for a standards committee to issue a clear pronouncement on each of them. Rather, I would suggest that retailers begin now to investigate the value of these technologies, especially tokenization and end-to-end encryption, to determine where one or the other, or both of them, can be used to protect confidential data and business risk and compliance costs.

  • Why many current encryption implementations are insufficient
    Encryption is too easy and also too hard. For many companies, encryption is not centrally managed. It is a feature that is easily added to applications, it's built into operating systems, databases, POS devices, etc. Even within the cardholder environment (such as it is), it's not uncommon to find a half-dozen different implementations of encryption and multiple key management systems. In this situation, card data may have to pass through multiple systems internally, and on the way to the acquiring bank or processor. The result is the dreaded "encrypt, decrypt, re-encrypt" scenario which opens up holes to external hackers and unauthorized insiders. A recent report suggests that hackers are using new techniques to decrypt encrypted PIN blocks, which would suggest that the myriad different encryption techniques and ciphers in use today must be "beefed up" to, say AES 256 or TDES, and centrally managed.

    Our research suggests there are far too many people who believe that encryption, by itself, is sufficient to prevent breaches or fraud — in fact, many of the 44 US state breach laws provide for an exemption from reporting breaches if the data is encrypted, with the quality of that encryption often poorly defined. Our take on current "tactical" implementations of encryption is that they have many problems and gaps (e.g., failure to encrypt confidential data in transit over private networks) that can be exploited by both internal and external sources. End-to-end encryption can be a major improvement.

  • End-to-End Encryption — Where's the End?
    The value proposition behind end-to-end encryption is that a company encrypts the data immediately at the entry point (the POS, the E-Commerce payment software and the call center software) and then the data remains encrypted throughout the process of passing it to the acquirer, and PAN data is never stored unencrypted by the merchant. Several products are available for the POS channel and numerous products are available for the E-commerce channel, but any of these products can be rendered ineffective if a company insists on storing and using the data for other applications.

    The other key point with end-to-end is that some companies are focused on an "enterprise view" of end to end, rather than defining one of the end points as the acquirer. In addition, the policies for and the processing of chargebacks in some companies tends to mess up the end-to-end scenario. The main thing to remember regarding encryption is that it is but one of 12 major PCI-mandated controls, even when it is end-to-end. I think the PCI study will likely conclude that other controls are still needed even if encryption is end-to-end.

  • Encryption vs Tokenization
    Speaking of things that are no longer needed, there is a lot of discussion in the industry that all a company has to do is implement tokenization and they will no longer need to encrypt data. In an ideal world, that may well be true. However, in "beyond PCI" land, we haven't found any Level 1 or Level 2 merchant that was able to actually get rid of all their card data even though they implemented tokenization. Some of the reasons include business requirements, the cost to change their production applications, and the difficulty of actually finding and purging all their card data.

    On the other hand, some smaller organizations that are single-channel and have a highly centralized data architecture, those smaller businesses have been most successful at handing off the data and compliance headaches to tokenization companies. Our point is simple: end-to-end encryption and tokenization will likely exist side-by-side in nearly all large and most midsize businesses for the next 2-3 years, so suggesting that one can take the place of the other for such organizations does not take into account the reality of the large, multi-channel merchant or service provider.

  • The Bottom Line
    Althoughy I like to see a fight to the death as much as the next guy, I think the winning strategy for 2009 and 2010 will require being able to demonstrate how tokenization and end-to-end encryption can co-exist within large and midsize enterprises, rather than for purveyors of one control to suggest the other control is irrelevant or unnecessary. The whole point of PCI DSS is "defense in depth" and in that spirit, we counsel "peaceful coexistence," at least for now. If you would care comment, and are willing forego weapons of mass destruction in favor of constructive dialog, please visit us at the PCI Knowledge Base or send an E-mail to [email protected].
  • Suggested Articles

    Costco changes up its menu items, and Alibaba and Guess partner for a physical store.

    Janey Whiteside, Walmart's new chief customer officer, is well acquainted with the importance of customer service in modern retail.

    Whole Foods will offer deals on Amazon's Prime Day, and tariffs against China are causing pricing hikes.