Reversing Credit Card Tokenization

Tym recently asked the PCI DSS guru:

“If I have tokenized some credit cards with my current gateway provider and I now want to move to new gateway provider. How can I get the credit card data from current gateway provider and give it to the new gateway provider, making sure the chosen way is PCI compliant?”

As you’re probably aware, Tym, tokenization is the process of replacing credit card numbers with a non-sensitive unique identifier.  This process, performed by your payment gateway, provides you with a value (or token) that you can store without running afoul of PCI DSS requirements.  For more information on tokenization, read What is Tokenization?

In your case, you’re looking to reverse the tokenization process and obtain the real credit card numbers.  You’ve already realized that you can’t do this on your own, as there is no way to compute the card number from the token that the gateway provided you.  Before you go about trying to obtain that information from your gateway, I’d ask you to consider whether you really need the actual card numbers for past transactions?  If you’re attempting to migrate recurring credit card transactions, this may be the case.  If you’re only worried about managing those transactions, perhaps your current gateway would be willing to continue to process refunds on your behalf after you migrate new transactions to another provider?

If you do need to obtain the actual card numbers and the gateway is both willing and able to provide them to you, you will need a secure means to transmit them.  This actually is not very complicated, as you aren’t trying to design a permanent, recurring process. You just need to complete a one-time transfer of sensitive cardholder information.  The easiest way to do this is by asking the gateway to store them in a file and then use strong encryption to protect that file.  For example, you might use WinZip to create an AES-encrypted file.

You’ll need to use a strong password to encrypt the file and then exchange that password in an out-of-band fashion.  This is as simple as authenticating yourself to the gateway’s technical team over the telephone and then agreeing on the document password over the phone.  Since the file is encrypted, they may then simply email it to you without worrying about the document’s security.  Once you receive it, you may decrypt it using the agreed-upon password.

Remember that the credit card numbers you receive are subject to all of the protection requirements of PCI DSS.  You’ll need to make sure that they are appropriately encrypted and that you have proper management over the encryption keys for as long as you retain the card numbers.  My advice would be to use them quickly for the conversion and then destroy any copies as soon as you are done.

PCI DSS Segmentation for a Hotel POS System

320px-Hyatt_Fisherman's_WharfDan recently asked the PCI DSS Guru about PCI DSS compliance for a hotel that has a restaurant, reservations system and staff computers:

“I have a hotel with 106 computers on the LAN. I am working on a plan for segmentation of the 37 machines that regularly interact with card numbers. These 37 are comprised of restaurant POS that swipe, front desk PCs that swipe, reservations PCs that hand enter card numbers and accounting PCs that hand enter or can access card info. Now we do tokenize all card numbers.

The other 69 computers have the application installed that allow them to view guest reservations and they could potentially enter a card number though there isn’t a clear business reason why they would. If I physically separate the 37 can the 69 still be considered in scope since they have access to the application where card data is entered/tokenized? Did this make any sense?”

This is a very interesting question, Dan, and it took me a few minutes to form my opinion on this.  I was about to say that, yes, you could probably define the scope of your cardholder data environment as the 37 systems that actually process credit cards and then segment them off from the other systems.  You would then have to treat the other 69 systems as remote access systems and provide a secure connection back to the CDE on an as-needed basis.

However, the more I thought about it, the more I questioned whether a QSA would actually accept this approach.  It seems like a solution where you’re trying to engineer a loophole rather than reflect the actual business environment.  If the systems in the non-card-processing offices are running the same software as the POS systems, they should probably be treated the same way.  I am guessing that there is some sort of thick client connection taking place between those systems and the backend application and, in my opinion, this makes them an inseparable part of the cardholder data environment.

If you truly want to segment these systems, I think that you need to break away from the thick client model for them.  For example, you might be able to build a web application that involves no potential cardholder data and then expose that to the 69 staff systems through the CDE firewall (with appropriate security controls around the web application, of course).  As long as you’re continuing to run the POS application on the staff systems, it is my opinion that you should consider them part of the CDE.

I’m sorry that’s probably not the news that you wanted to hear.  I welcome other opinions.  Feel free to chime in with comments!

PCI Compliance for the Resistant

Bill wrote in and asked the PCI DSS Guru this question:

We are a franchiser. The typical franchisee is a small store with 2 registers and a back office computer. They are having a difficult time with PCI compliance, mostly due to the store owner’s lack of knowledge of PCI, an unwillingness to budget sufficient funds to attain and maintain PCI compliance, and a lackadaisical attitude. 

Since these stores will never be PCI compliant, we have suggested that they take an approach that will protect themselves as much as possible. Our advice is to stop using the POS software to process credit cards, and switch to the terminals supplied by their processors. This would take their POS system out of scope entirely, and severely reduce the possibility of a keylogger type of attack. At that point, we believe their only PCI compliance issues would be protecting the terminals and how they handle credit cards that are phoned in and written down. We are getting a lot of push back from the stores that this would be a step backwards. 

Are we on the right track? Is there a better approach to handling people who simply can’t or won’t do what’s necessary to attain and maintain compliance?

Bill, I think that you’re definitely on the right track here.  I have a few specific pieces of advice that may help guide your PCI compliance efforts.

First, I would carefully consider how you have your merchant accounts structured.  Does each franchisee have a direct relationship with the bank?  This would be ideal, as the liability then rests with the franchisee to be PCI compliant.  If the franchisees are reluctant to comply and you don’t have the authority to make them comply, then you certainly don’t want to accept responsibility for their compliance!

Second, have you considered a point-to-point encryption (P2PE) solution? If the credit cards numbers are encrypted at the time of swipe and the merchant never has electronic access to them, the franchisees may be eligible to complete the abbreviated P2PE SAQ.  Quoting from that document:

SAQ P2PE-HW merchants may be either brick-and-mortar (card present) or mail/telephone-order (card not present) merchants.  For example, a mail/telephone-order merchant could be eligible for SAQ P2PE if they receive cardholder data on paper or over a telephone, and key it directly and only into a validated P2PE hardware device.”

Whatever approach you take, you should work to provide merchants with a solid path toward compliance.  In my mind, you’re responsible for guiding them to water, but you can’t make them drink.  Once you’ve outlined the path to compliance, it’s on them to step up and meet their contractual obligation.

PCI DSS Key Management in Tokenization Environments

keyZach recently asked the PCI DSS guru this question:

“PCI DSS Requirements 3.5 and 3.6  talk about securing data encryption keys and documenting the procedures on how you handle those keys. Now we as a company have decided to not store any cardholder data (CHD), with no exceptions. Since we do not store cardholder data at any level and use tokenization do we still need to comply with these 2 requirements as there is no CHD  to encrypt?”

First, Zach, let me commend you on the work that you’ve done to minimize the scope of your cardholder data environment.  I am strong believer in the idea of minimization.  It’s the easiest way to reduce the risk to your organization. If you don’t have data in the first place, you can’t lose it!

You’re also wise to be thinking about this issue.  Remember, the entirety of PCI applies to all merchants and, lacking specific guidance from the standard or clarifying documents, it’s up to you to interpret the standard and identify your obligations.  You can often do this by examining the testing procedures and guidance included in the full version of the standard.  The first requirement you mentioned, PCI DSS requirement 3.5, reads as follows:

“3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.”

When you read this requirement, logic would dictate that if you don’t have any stored cardholder data, then you have nothing to secure and wouldn’t, therefore, need to document any procedures.  IMHO, the “get out of jail free” card that you’re seeking comes in the guidance for this requirement, which contains the following sentence:

“The requirement to protect keys from disclosure and misuse applies to both data-encrypting keys and key-encrypting keys.”

If you don’t have either of these in your environment, then my reading would be that the requirement does not apply and you’re off the hook.

You also asked about PCI DSS requirement 3.6, a similar requirement that mandates that you:

“Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data”

Again, we find some relief in the accompanying guidance, which reads in part:

“This requirement applies to keys used to encrypt stored cardholder data, and any respective key-encrypting keys.”

So, it looks like you’re off the hook on this one!  The fact that you’re using tokenization and eliminating the storage of cardholder data in your environment seems to obviate the need for maintaining key management practices.  Congratulations!

What is Tokenization?


Tokenization is one of the best ways that you can secure your cardholder data environment.  The basic idea is that you take sensitive information, such as a payment card account number (PAN) and simply remove it from your database, replacing it with an alternative value that serves as a placeholder for your use but lacks the extreme sensitivity of the original information.  After all, if you don’t have the information  in the first place, you can’t be the source of a stored data compromise!

In payment card systems, tokenization often takes place at the payment gateway.  When you process a credit card transaction, you send the transaction information to the gateway.  When the gateway returns the transaction confirmation, they provide you with the token value that you may store in your database.  For technical convenience, the token is normally formatted in the same manner as a credit card number.  That way, it fits neatly into database fields designed to store numbers without any modification.  For business convenience, the last four digits of the token value are usually the last four digits of the real card number, allowing you to reference transactions with customers by the last four digits of their card.

How does this help with PCI compliance?  It gives you a path toward easily meeting a couple of requirements.  First, PCI DSS requirement 3.3 requires that you:

“Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.”

Since the token only contains the last four digits of the PAN, there is simply no way that an application can accidentally violate this requirement.  The full PAN simply isn’t in the database!

Second, PCI DSS requirement 3.4 mandates that you:

“Render PAN unreadable anywhere it is stored (including on portable digital media, backup media and in logs) by using any of the following approaches…”

It then goes on to name four methods that you can achieve this goal, including the use of truncation — which is, in effect, what you are doing by tokenizing card numbers.

Finally, as we pointed out in the answer to an Ask the PCI DSS Guru question, tokenization obviates the need for the key management procedures required by PCI DSS sections 3.5 and 3.6.

Remember, of course, that tokenization is not a cure-all.  If you’re still processing and transmitting card numbers to your payment gateway, you still run the risk of those processes becoming compromised and being the source of a breach of payment card information.  You may wish to consider adding the use of Point-to-Point Encryption (PTPE) to prevent credit card numbers from entering your system in the first place!

  • Free Newsletter

  • Search

  • Copyright © 1996-2010 PCI DSS Guru. All rights reserved.