Evan Schuman's StorefrontBacktalk

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

1. Chris Miller Says:
   April 16th, 2009 at 8:10 am

   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:
   April 16th, 2009 at 5:40 pm

   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.

   Regards,
   Mark
   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:
   April 20th, 2009 at 6:11 pm

   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:
   April 23rd, 2009 at 11:59 pm

   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
   Solidcore.com

5. Data Protection Says:
   November 5th, 2009 at 11:17 am

   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.

Leave a Reply