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

Written by David Taylor
April 15th, 2009

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.

  • advertisement

    5 Comments | Read Data Security Slugfest: Tokenization Vs End-to-End Encryption

    1. Chris Miller Says:

      What are you thoughts about efforts that some retailers are taking to get their POS systems out of PCI scope altogether by moving card processing off to a seperate device (that only communicates the most basic transaction information – not card data – back to POS). Regis Salon has implemented this. We are loking at it very seriously. Seems like McDonalds is doing the same. For smaller speciality stores, this appears to be a long term cost saving option and would make maintaining compliance much easier. I’m interested in your thoughts.

    2. Mark Bower Says:

      With respect to “The result is the dreaded “encrypt, decrypt, re-encrypt” scenario which opens up holes to external hackers and unauthorized insiders”

      Any legacy approach will suffer this exact problem – but that is now a completely solved problem. As I’ve mentioned here before, an entirely practical solution here is FFSEM Mode AES aka FPE, or Format Preserving Encryption (see it on the NIST AES modes site if you want to learn more about the method). FPE can do this:

      • Encrypt 12/15/16 digit credit card numbers to a 12/15/16 Digit credit card numbers that’s useless to anyone except the trusted entities but still works in POS systems, or,
      • Encrypt first 12 say only, encrypt internal account # digits, leave routing/BIN etc in clear, maintain Luhn etc. whatever combination is needed to suit the business purpose. Separate sub fields can be independently encrypted so different systems can use them independently – separating access right down at a sub field level – think firewalls around the data itself.
      • FPE can be applied to not only cards, but SSN and other data- names, address, customer field notes – whatever.
      • FPE can encrypt columns that are indexes or have primary and foreign key relationships – it does not matter- referential integrity is preserved
      • Any data encrypted with FPE can also be used immediately in a QA system as masked QA/Test Data – no need to regenerate DB test data.
      • Use IBE (Identity Based Encryption, RFC 5091) and FPE for Stateless Key Management – solve the complexity of key management to almost no management overhead and one way encryption at capture.

      Therefore, with respect to the lifecycle of the data from capture storage, there is no need to open up the data -the data can be used in its encrypted form – as is, no decrypt, no risk, no keys present, no PCI scope.

      Tokenization systems on the other hand simply shift the problem and put the burden of managing a massive amount of additional state information (token/card mapping data) to the operator of the token scheme – hence the often quoted transaction or service subscription costs. Tokenization approaches essentially create a parallel universe of cardholder data to manage. This has obvious scale limits and hence why tokens must expire – and hence destroy any business intelligence processes a business may require when operating e.g. a data warehouse, data mining etc. Tokenization systems also require a call to the token generator per transaction, thus must be online at all times. This results in incremental overheads per transaction, don’t solve offline processing, and creates addition network hops and attack vectors as the clear data is now traversing a potentially large path to the token provider. The tokenization vendors seem to forget to mention that encryption is required – “end to end encryption” ideally – from the capture point to the token generator, and vice versa at the point where the data is required in clear form for eventual clearing.

      FPE solves that problem in situ and stops those who deploy it from having to worry about that parallel universe of card data.

      VP Product Management
      Voltage Security

      Full disclosure: I work for a firm who creates products for privacy and payments systems using FPE technology.

    3. Steve Sommers Says:

      Mark, You are incorrect in your blanket statement – Shift4 is a tokenization vendor and we do detail this. We always mention that end-to-end encryption is required and we provide the means as well that offloads the key management and in most cases is transparent to the POS – state of the art or legacy. The biggest difference in FPE vs. tokenization is that encrypted card holder data is still card holder data whereas a token is not. You’ll get different opinions among QSA’s as to whether or not FPE removes applications from PCI scope whereas most QSA’s agree that our end-to-end encryption/tokenization model does (just for clarification: can remove applications from scope, not merchants).

      Both solutions have their pro’s and con’s. I give more pro’s to a properly implemented tokenization solution that includes end-to-end encryption (bypassing the POS). I’m guessing that you give more pro’s to FPE. To me, either solution is much more secure than the POS receiving unencrypted card holder data and trusting the POS provider to properly secure this data within the application and the merchant’s network, and with adequate key management controls.

      In the not so distant future, the ultimate solution might be the combining of technologies.

      Steve Sommers
      Sr. VP Applications Development
      Shift4 Corporation

    4. Kim Singletary Says:

      A healthy debate going on – but both scenarios require attention to the configuration and management of either the encryption or tokenization solution. Doing anyone of these tactics still requires additional PCI controls to ensure compliance – however many are positioning these investments as the silver bullet. As David refers to in his last point these will be another means to defend this data and mitigate risk. But my concern is today’s and tomorrows systems (here and now) – how fast and at what cost can the individual Merchant of any size and with limited spend go beyond PCI compliance. Runtime control with dynamic whitelisting and memory protection is another means to provide for secure systems today without code or database changes. The technology whitelists known good systems taking inventory of all executable code (.exe, scripts, java, and .dll’s) and of the system and application configuration, identifies authorized processes that are pre-trusted to provide automatic updates to the system then denies all other types of changes. In addition currently running applications and local data, registry entries and configuration files can be read/write protected so they are only usable and visible to their native applications or those that require them for processing. Easy implementation, no application or change of current business delivered with a single solution that goes beyond PCI compliance but that also fulfills many of the current PCI requirements like protecting from malware today and future malware and file integrity monitoring. This method is accessible to all Merchants today and many may even find their POS vendor reselling or embedding the capability into their systems providing PCI-ready devices.

      Kim Singletary
      Director, OEM & Compliance Solutions

    5. Data Protection Says:

      The solution to the encryption conundrum is simple: define and stand by a standard. Unfortunately, there are too many hands in the encryption cookie jar for this to ever happen. Some fear that a single standard would be a bad thing, because if it were ever hacked, the losses could be staggering. Still, with a single standard comes increased strength and progress made in methods, along with more streamlined updates and implementation. Th result would be a much smaller chance for a successful attack, rather than a larger chance.


    StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

    Most Recent Comments

    Why Did Gonzales Hackers Like European Cards So Much Better?

    I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
    Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
    A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
    The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
    @David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

    Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.