Security Versus Scope: Choose One

Written by Walter Conway
February 11th, 2010

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

Tokenization and end-to-end encryption are designed to secure information both in transit and at rest. In other words, the focus of each technology is security first. The fact that they can reduce PCI scope or make PCI compliance easier is a secondary benefit. That tokenization and end-to-end encryption vendors are starting to figure this point out is good news.

The smart ones—and the only vendors you should be talking to, by the way—will tell you that there is no silver bullet to make PCI go away, which is a victory for reality over marketing hype. But there is one thing you should know about reducing your PCI scope: It is pretty important. If retailers are going to get the full value for their investment in either or both of these technologies, they better look carefully at their implementation or they may find they will not get all that they paid for.

There have been some pretty good arguments made that tokenization and end-to-end encryption each can reduce a retailer’s PCI scope. But if these technologies are not implemented properly, you may find that you are more secure (a good thing) but haven’t reduced your PCI scope (a bad thing).

Whether you insist that your tokens be compliant with the Luhn algorithm (used to compute the check digit in the PAN) or not is not particularly relevant. Similarly, the issues of token collisions (duplication) and even format preserving encryption/tokenization (the encrypted data or tokens look like a PAN) are secondary. The main question retailers need to ask is whether they will have the ability to de-tokenize or decrypt the data and return it to plain text. If you have this ability, through whatever means, that data is in still scope for PCI and you will have lost a lot of the value of your investment.

As almost everyone should know, the PCI Council has decreed that encrypted cardholder data is in your PCI scope. The sole exception is “if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” The whole idea of investing in either tokenization or end-to-end encryption is to get as many of your systems and databases out of PCI scope as possible and to reduce your cost of PCI compliance.

Therefore, this one exception is important. The clear intent of the Council is to say that if you, the merchant, have access to any mechanism that allows you to go from a token back to the clear text PAN–whether you call that mechanism decryption or de-tokenization or de-anything–that tokenized data is still in scope. You gained some extra security, but you just blew the opportunity to reduce your PCI scope.


4 Comments | Read Security Versus Scope: Choose One

  1. Steve Sommers Says:

    I agree with all your arguments and this is one of the reasons I advocate third party gateways — provided that the gateway does not allow the merchant to de-tokenize the data.

    I disagree with the PCI SSC when it comes to it’s decree that encrypted data is out-of-scope if “…it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” Encrypted data is still data and can always be decrypted. What will the ruling be if and when someone gets hacked and it is determined that “encrypted data” was being siphoned off for months or years and then, all of a sudden some end-to-end encryption key or base derivative key (in the event of DUKPT) was cracked? Now all this out-of-scope encrypted data is as open to the hacker as plain text.

  2. Mark Bower Says:

    “Encrypted data is still data and can always be decrypted” is a meaningless statement. It like saying “the sun will eventually explode”.

    Please explain how “Encrypted data is still data and can always be decrypted” can performed without a key ?

    Propagating a myth that somehow its easy to brute force strong, proven cryptography is false and misleading. Attacking AES, RSA, ECC, IBE, FPE etc when strong keys are used is completely infeasible.

    After all, surely even Tokenization services like Steve’s third party gateway rely on encryption and key management every nanosecond for its own security – from the connection to the banks to protect the live data in transit, the back end PAN database, the front end token API to device, to application user interfaces over SSL to manage things etc.

    So, why not encrypt from the moment of swipe and be done with it – take everything after out of scope all the way to the processor? Using Format Preserving Encryption as mentioned in the article means the in between applications still work – easy.


  3. Steve Sommers Says:

    I never meant to imply that brute force encryption key attack is easy (even though, technically it is, it just takes a long time). All encrypted data can be cracked, it’s just a matter of at what cost and how long. What is considered strong today may be insignificant tomorrow. DES (single DES) was thought to virtually uncrackable not so many years back. There are still DES devices being used and it has not been until recently that the rules were changed to phase it out. SSL1 was strong at one time — now it’s virtually useless. MD5 hashing was state of the art at one time, now PCI outlaws it.

    I do see one flaw in my original statement. I should not have used the word cracked because that does imply brute force attack or encryption vulnerability. While these are possible attack vectors, I probably should have used a more generic statement like “compromised” via whatever means. Many times it’s easier to attack the key management components than it is to brute force attack for a password. My point is that if the key is ever compromised, all the freely available encrypted data is now vulnerable.

    Yes, Steve’s data center does use encryption, but our data center is in full scope of PCI and we have various layers to keep the data in our data center, whereas PCI is saying a vendor can freely store, process, transmit or distribute encrypted CHD as long as the vendor does not have the key. Do you really think this is secure?

  4. Luther Martin Says:

    Even though the claim that any encryption can eventually be cracked is technically true, it’s also somewhat misleading. It’s also the case that absolutely nobody ever thought that DES was ever thought to be uncrackable. The only people who ever argued that this was true were people from the US government who wanted to control the export and use of encryption outside the US, and nobody really believed them.

    Let’s get a rough idea of exactly how secure 112- and 128-bit keys are by estimating the level of effort needed to crack one. Let’s base this on the EFF’s DES Cracker.

    The DES Cracker can test roughly 92 billion keys per second on 1,536 special-purpose chips. Given a plaintext-ciphertext pair, it can test all possible DES keys in a bit over 9 days, and you’d expect it to find the key that decrypted the ciphertext in about half that time, or about 4 and a half days.

    Let’s assume that we can make a special-purpose computer that can test keys one billion times faster than the DES Cracker, or roughly 92 quintillion keys per second. This isn’t even close to realistic with today’s technology, but maybe a combination of Moore’s law, faster clock speeds and adding lots of additional chips to the computer will let us do this one day.

    Even with this huge increase in power, such a hypothetical machine will still take roughly one million years to recover a single Triple-DES key, or about 100 billion years to recover a single 128-bit AES key. So unless someone finds an incredibly severe weakness in the encryption algorithms that we use today, it looks like that assuming that they’re essentially unbreakable is fairly reasonable. No other component of a security architecture even comes close to being this strong.

    So for all intents and purposes, a hacker is never going to attack the cryptography. He’s always going to bypass it. That’s even Shamir’s Third Law, which he discussed in his Turing Award lecture in 2002.

    But if 112- or 128-bit encryption is essentially unbeatable, key management certainly isn’t. You need to authenticate a user or application that’s requesting a key, for example, and that process will never be as strong as what you get from the actual encryption. Note that this also applies to tokenization: you need to authenticate a user or application that requests a detokenization operation, etc. So if you worry about key management (like you should), you should also worry about the corresponding issues around the way that tokienization is implemented.

    So the security provided by either encryption or tokenization are essentially the same: they’re both limited by system issues that don’t really relate to the encryption or tokenization technology. People seem to either not understand that or to cheerfully ignore it.


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.