I just finished reading the tokenization guidelines from the PCI Council. A very good document, much more informative than the one on virtualization. However, it does not provide the simple connect the dots type of advice most would want because t10n is complicated. It is complicated in its own right, let alone the fact that it is being deployed as part of PCI DSS compliance program.
Here are some of the issues that are raised:
- Solution architectural,
- Deployment,
- Operational challenges
- Software development, and
- Contractual terms and conditions.
So will tokenization make your PCI compliance pain go away? Will it even ease your pain? Just a little bit?
Let me cut to the chase: Maybe, but don’t count on it. There are no silver bullets in the PCI compliance arena. At the end of the day t10n is a *scope reduction* approach. As such it can help reduce and minimize your PCI compliance efforts, but it does not eliminate your need to comply. Also, because it is part of what defines your PCI DSS scope it will need to be reviewed in detail each and every year when you undergo your PCI validation whether Self-Assessment Questionnaire or Report on Compliance.
I highly recommend that merchants thinking about deploying t10n give it a read. I also highly recommend any service providers looking to offer a t10n solution read it as well. It’s got good advice for both. Let’s dig in a bit more:
The Idea of t10n
The whole idea is to turn a primary account number (PAN), a valuable piece of data, into a token, that is not a valuable piece of data. Tokens should not be valuable in any way to an attacker. If the token allows you to conduct a transaction then it is a payment instrument or a high value token. These can (and likely will) be monetized by criminals. The guidance says they “might be in scope for PCI DSS.” You are directed to consult with your acquirer and/or the card brands. In my opinion high value tokens should be treated no differently than cardholder data, they are in scope. At least until the card brand or acquiring banks rule otherwise.
Tokens can be single use or multi-use. What kinds you’ll need are dependent on your business processes. There isn’t really a PCI DSS impact on one or the other. Both kinds of tokens, how they are generated, used, and destroyed will have to be reviewed in detail.
How to do it
Turning a PAN into a token can be done in three main ways:
- Encryption (transforms the PAN directly and is reversible)
- Hashing (transforms the PAN directly and is not reversible)
- Indexing (does not transform the PAN, is not reversible, maps a PAN to a randomly selected value)
In all cases, recovery of the PAN from the token must be computationally infeasible. This is a technical term from the cryptography field that basically means it should take millions of years of effort to do so. Even if you leverage “the cloud” it should take millions of years. Recovery should not be possible even if you have a number of tokens (ciphertext only attack) and/or a number of PAN/token pairs (known plaintext attack). One last thing is that if tokens are generated by hashing, the hash of the PAN should be not stored with a truncated version of the PAN, this makes brute forcing the PAN significantly easier.
You should take two things from this:
- A t10n system is, at its core, a cryptographic system. Cryptography is HARD. It is hard to design the ciphers, it is hard to design the protocols, and it is hard to implement them correctly. Rolling your own crypto for an in-house developed t10n solution is definitely not recommended. Even using a solution from an otherwise reputable brand is potentially risky. How are they implementing the crypto? Do they have any experience? How are they testing?
- Encrypted tokens are still encrypted PANs. The would still be subject to requirements 3.4, 3.5 and 3.6, unless PCI FAQ 10359 applies (the “no access to encryption keys” FAQ). According to the guidance document The Council is “further evaluating how these consideration may impact PCI DSS scope” in these situations.
Token mapping
There are definitely two times in the lifetime of a transaction where a PAN is mapped to a token.
- When a transaction is started and a PAN is submitted for t10n, and
- When a token is submitted for de-tokenization to get a PAN back.
Any device that submits a PAN or retrieves a PAN is in-scope. So are the people, processes, and systems involved. In your efforts to reduce scope and minimize the handling of cardholder data, who and what can access the t10n system and use the t10n process is a key point to pay attention to. The guidance mentions that the “necessary authentication information” be provided when interacting with the t10n system. There is no elaboration on this.
As part of requirement 7 you’re supposed to be implementing least privileges and access to cardholder data only on a “need to know” basis. Requirement 8 spells out the authentication requirements for in-scope systems. It may be tempting to simply deploy an authentication system that meets these minimum standards. However, even passwords that pass all the sub-requirements of 8.5 are not particularly strong. You should be looking at something stronger.
Is that a token you’ve got there?
With t10n comes the challenge of distinguishability. Just what is a token and what isn’t. This is most prevalent with format-preserving approaches to t10n. Your solution may allow you to turn a PAN into something that looks just like a PAN but actually isn’t. It’s the right length, right format, passes the mod-10 checksum (Luhn) algorithm. So how do you know it’s really a token and not a PAN?
If there is no way to tell, this may lead to mis-scoping and leaving cardholder data unprotected where you thought it was. A very big mistake to make.
Scope: what’s in, what’s out?
Considering that you are going to deploy a t10n solution to help reduce your PCI scope, just what will be left in scope? Here are some general guidelines.:
- Obviously the t10n system itself is in scope. This includes the devices doing token mapping, and the card data (token) vault itself. There may be other support systems that provide encryption key management, and/or authentication services. These would be in scope as well.
- Systems, devices or processes that accept PANs and then get them tokenized.
- Systems, devices or processes that submit tokens and have them de-tokenized.
- Systems, devices or processes with *access* to the t10n system or t10n process.
- Any other system, device or process connected to the above 3 types of systems, even if it does not perform tokenization or handle PAN data directly.
That 4th bullet point is a tough one. It essentially creates a hard divide between in-scope and out of scope devices. If a device accesses the t10n solution for any reason, maybe to patch, maybe to provide authentication, then it is in scope as well. While this may be stringent, it is certainly clear.
Outsourcing, tokens in the cloud
A new breed of service provider is popping up providing t10n services. We could call them t10n service providers (TSPs) or tokenization as a service (TaaS) providers to make them sound more cloud-like. Some are brand new entities, and some are just a new service from existing service providers and acquiring banks. Regardless, using them is attractive because it can reduce your burdens, but it won’t get you off the hook for your compliance. There is still requirement 12.8 (the 3rd party service provider requirement). The merchant is ultimately responsible for the validation of whatever t10n solution they use. Who does precisely what is depends on precisely what the TSP does for you. It should be spelled out in detail in your SLA with the TSP.
Recommendations
As you can see there are a lot of subtleties and nuances with a t10n solution. So what to do?
- If you haven’t decided on a direction or solution yet, get a conceptual Threat and Risk Assessment (TRA) done. Make sure that whoever is performing the TRA has access to a QSA, or better yet is a QSA. This can help you decide whether you even should take a t10n approach. T10n is all the rage lately, but maybe it’s not for you.
- If you have selected a solution but haven’t deployed it yet, have a logical TRA performed as well as a detailed PCI Scope assessment of the current and future post t10n environment. This will help you determine that actual impact to your PCI scope and the resulting PCI DSS compliance efforts. Don’t rely on the vendor, they most likely are not a QSA and not conversant with all the little gotchas that can crop up.
- If you have selected and maybe even implemented a t10n solution, even if you’ve had it looked at by a QSA, do another review. This guidance changes things. The QSA who assessed it may have been making an assumption that has now been clarified that made their previous advice incorrect.
- If you do decide to go with t10n, strongly consider deploying it in conjunction with end to end encryption. That way PANs are only ever contained in PTS approved PINPADs. That is a whole other kettle of fish that we’ll have to deal with at another time.
Jason M.
