Monday, November 2, 2009

Your encryption sucks - here, use mine

I just read an amusing article on SearchSecurity.com: Heartland CIO is critical of First Data's credit card tokenization plan. In this article, Steven Elefant claims front-end tokenization solutions are less secure than end-to-end encryption solutions because front-end tokenization solutions depend on encryption. Huh? "Front-end tokenization, where you take a credit card number and send it up to a token server and then send it back to the terminal, is not good because you are totally exposed from the time you swipe the card until it gets to the token server," Elefant said in an interview with SearchSecurity.com. "If you are not encrypting with very strong crypto and hardware, you don't have security." I like the idea of end-to-end but let’s get some perspective. The end-to-end encryption technology that Elefant endorses uses unproven "hidden" or "format preserving" encryption. Could this be the case of the pot calling the kettle black?

If you're reading this trying to decide on end-to-end vs. front-end tokenization, here are some things to consider. Security should be thought of as layers. A solution that provides or allows for overlapping of end-to-end and tokenization would be the best approach. In lieu of that, true tokens (where the token value is in no way related to the card number other than as a reference) are not considered cardholder data and are not in scope of PCI whereas encrypted cardholder data is still considered cardholder data. Tokenization solutions may be adjusted to allow for repeatability (depending on provider) whereas end-to-end cannot and should not be able to provide repeatability – this comes into play when presenting recurring transactions are using cardholder data for loyalty lookups or risk analysis. End-to-end, in most cases, can work better in remote offline locations whereas most tokenization solutions require online access (but Shift4 does provide offline tokenization capabilities). Most end-to-end solutions use a "keys-to-the-kingdom" approach and therefore require tamper resistant hardware security modules; if these keys are ever breached, all the systems that store this "encrypted" data are vulnerable whereas true tokens are useless even if the token generation logic is known to the world.

2 comments:

  1. Pre-authorization card replacement technologies (what I like to call Card Number Firewalls), like Shift4’s 4Go technology is where a value such as a false card number (other similar value) is used to never allow actual card data (swiped or otherwise) to enter into the Point-of-Sale (POS) system, its logs or databases. This too, like E2E is encrypted from the time it is swiped. For all intents and purposes, our 4Go is functionally similar to what Steven is trying to accomplish with Heartland’s E3 solution, without the need for specialized hardware.

    Specialized hardware is a hardware vendor’s entitlement act, and remains to be seen whether it gives any additional security. It may be perceived that encryption at the device level is better, but I would simply turn your readers to the recent press release about the card brands pushing out the date for PINpad/ATM compliance. Our Nation’s ATM and PINpad infrastructure is security anemic at this time and is not going to get fixed anytime soon. These are the same hardware vendors that we are being asked to rely on to secure using E2E technologies. Can they be trusted? I know my organization’s solutions have gone through countless merchant level 1 and 2 PCI-DSS assessments and been vetted by more than one QSA, can E3 say this? Additionally, working with “standards boards” does not produce a secure solution. Besides “standards” always have areas of discretion, and with security the devil is in the details my friend.

    E3 and other E2E encrypted solutions have exactly the same issues as any other encryption solution. (rekeying yearly, key management, availability of data, etc) The fact that it is encrypted data and so it is still cardholder data as defined by the PCI-SSC. Post Authorization Tokenization is not, and neither is false cardholder data. It is true that the actual cardholder data that is strongly encrypted from the POS card swipe to the “Tokenization sever” as Steven Elefant talks about is CHD, but strong (PCI-DSS compliant) encryption is strong encryption. Elefant is straining at gnats.

    Steve, I do agree with you however that until someone really takes a hard look at the “hack-ability” factor of this untested and untried card level encryption methodology, Heartland is just asking for trouble. In my opinion, Heartland may be painting a target on their backs and those of their merchants. Shift4 with our 4Go solution has had true end-to-end encryption with Heartland payment since 2007 and has the largest number of post authorization Tokenized solutions in the industry, so I simply do not see the difference in what is being pushed by Heartland, and what it really buys the merchant. Other then of course, increased costs in both additional fees and hardware replacement. Finally , any solution purchased from a Merchant Services Provider like a Heartland Payment, First Data or any other has the consequence of tying that merchant to that provider. Once the contract is up, what happens to the merchant’s data? Can the encrypted data be used or transferred to another provider? Can the Tokenization data?, Shift4’s can.

    Lots of questions, not a lot of answers.

    ReplyDelete
  2. I normally would not trash a fellow in the industry trying to do good by helping to secure our Nation’s transaction processing system, but Steven Elefant’s comments are in my opinion uninformed, a wee bit self serving to his organization and for the most part nonsense.

    I think that the problem is that the industry has confused, or at least not distinguished between pre and post authorization “tokenization.” Tokenization(sm), a term coined and defined by Shift4 in 2005 at its Security Summit is a non 1 to 1 value not related to the credit card number in any way, and is used “post authorization” for any storage related activities. That is, it is used for both short term, like post auth completion (settlement) of a transaction, and long term such as returns, credits, incremental authorizations, back orders, periodic billing, card-on-file scenarios, etc. In this case Steven Elefant is correct, no encryption or replacement occurs until after the authorization event. But once that event occurs, no card data is needed to perform the functions mentioned above or any other for that matter and can be discarded.

    ReplyDelete