This is page 2 of:
Tokens Are Not The Same As Encryption. Honest
Tokens, however, are not (or at least should not be) reversible. Tokens should be randomly generated, and the token vault should be properly segmented from other systems and devices. The PCI Council (and Visa before it) stipulated that there should be no way mathematically to reverse the process and derive the PAN given only a token. This means that even if someone knew the PAN associated with one or more tokens, they would have no information to help de-tokenize the next one.
A security expert I respect greatly recently challenged me as to whether any tokenization system, particularly an internally hosted tokenization solution, could really reduce PCI scope. He compared tokenization with encryption, and he concluded that because encrypted data is considered in PCI scope if the organization can decrypt the data, then tokens, too, should be in scope if anyone in the organization can de-tokenize them.
I failed to see then (and I still fail to see) the parallel between encryption and tokenization, and I do not agree with applying the rules for encryption to tokenization. The sole fact that some people in the organization with appropriate privileges can access the token vault and retrieve a PAN does not make the tokens “reversible.” That ability does not bring tokens into PCI scope. Certainly all the persons and processes that retrieve PANs and use them for a transaction are in scope. But the tokens themselves should be considered out of scope.
The PCI Council’s guidance supports this position when it describes the special case of a “high-value” token, which may require additional safeguards.
High-value tokens are those that can be used to initiate a new card transaction. According to the PCI Council’s guidance document, such tokens “might be in scope for PCI DSS, even if they cannot directly be used to retrieve PAN or other cardholder data.” The use of the word “might” is hardly definitive, but the fact that the Council called out only these tokens for special treatment reinforces my argument that comparing tokenization and encryption is a false analogy.
Tokenization and encryption have a complex relationship. The two technologies are fundamentally different—that is, encryption is reversible, where random tokens are not. At the same time, tokenization solutions require strong encryption to protect card data stored in the token vault.
The fact that tokenization uses encryption does not justify applying the same PCI scoping considerations to each technology. For this to be the case, one of two situations has to exist. The first situation would be to have the token solution violate the rule that there is no way mathematically to reverse the token. This would validate the comparison to encryption, and I might consider such a solution to be encryption in the first place, thus negating the desired scope reduction. The only other situation is to consider all tokens to be high-value tokens, which seems inconsistent with the PCI Council’s guidance. Therefore, I have difficulty accepting a parallel between tokenization and encryption.
What do you think? Have you implemented tokenization? Did you receive the scope reduction benefits you expected? I’d like to hear your thoughts. Either leave a comment or E-mail me at wconway@403labs.com.
-Marc
December 15th, 2011 at 12:22 pm
Hi Walt, great post. I agree with all your points on how the technologies differ. The only possible disagreement I have is that you are very generous in giving PCI credit for distinguishing the differences between the two technologies and scope whereas I think they caused the confusion (or at least didn’t help).
I wrote a three part blog post on this same topic: “Tokenization is Encryption – NOT!” For anyone interested, the links can be found here: http://paymenttidbits.blogspot.com/2011/11/tokenization-is-encryption-not.html
December 15th, 2011 at 6:41 pm
I tend to disagree that tokenisation and encryption are different – indeed, I see tokenisation as a form of bespoke encryption (see this presentation I put together for my justification around this http://www.slideshare.net/AndrewRJamieson/encryption-vs-tokenisation-for-share ). Many of the arguments I hear about tokenisation being different from encryption leads to concerns about the security of encryption, or that encryption can be reversed.
Although it is true that encryption can be reversed with the key, I strongly dispute the arguments about the security of encryption, and personally I put much more faith in an algorithm that has undergone many decades of community research, where the security (key) can be isolated in approved hardware, than in a bespoke solution I have no visibility or independent assurance of.
In regards to reversal – tokenisation _must_ be reversible at some point, otherwise there is no value in having the token at all (indeed, what you have then is a payment reference number, not a card token). The arguments tend to focus on outsourced tokenisation – where the merchant does not have access to the tokenisation system. Once again, I personally put more faith in an approved key storage HSM where the difficulty of compromise of the key has been assessed and would require absolute physical (and destructive) access.
December 15th, 2011 at 7:30 pm
Walt,
This is a very good article, and I agree with you wholeheartedly about the differences between tokenization and encryption.
However, I disagree with you on the point you made about there being no way from a PCI scoping perspective to compare tokenization guidance to encryption clarification.
The parallel that I see is not between tokenization and encryption, but between the token and the encrypted data values themselves. Semantics? Maybe, but I believe there is a signifcant if not subtle difference between these two statements.
As you correctly stated, PCI FAQ #10359 leads one to conclude that an entity (e.g. merchant) must keep encrypted card data in scope if they have the means to decrypt the data.
(BTW – I don’t think the council “settled” anything with that FAQ because I still know entities that are taking encypted data out of scope if the ability to decrypt is merely segmented from the transaction processsing flow or whereever the encrypted card data is stored – and this is blessed by their QSA. But I digress…)
At any rate, the analogy that I am suggesting is that if this simplified equation is true:
A (encrypted data) + B (ability to decrypt) = C (still in scope for PCI)
then the following simplified equation should also be true:
A (token) + B (ability to de-tokenize) = C (still in scope for PCI).
This has nothing to do with the encryption algorithm, or the randomness of the token value. It’s merely possession of one or the other values plus the ability to “process” the value to recover a PAN – and it doesn’t mattter whether the PAN is reversed, derived, or merely looked up in a token vault.
I read the blog posts from Steve Sommers (previous commenter) and found a statement in his first blog that I believe supports this position. I’ll include it here for convenience:
“It is important to note that both TrueTokenization and PCI SSC tokenization allow for merchant-accessible de-tokenization capabilities. Solutions containing de-tokenization capabilities have a much greater risk profile. In other words, more places for a potential compromise… De-tokenization is all but a requirement for in-house solutions, thus one of the reasons Shift4 recommends outsourcing to reduce scope and risk.”
I agree that the Council’s Tokenization Guidance document implies that entities are allowed to host tokenization solutions internally, However, I strongly believe this is risky guidance unless and until there is more specific guidance published on how to safeguard and protect the de-tokenization method itself and the users that are authorized to make these de-tokenization calls.
I am emphatic about this point because a short time ago I had a discussion with a tokenization vendor that when I asked about how their solution would protect against unauthorized de-tokenization attempts commented that “that’s up to the customer to protect against… probably at the network layer…perhaps with ACLs.” I asked if they were going to provide the customer with any guidance or suggestions on how to securely implement their de-tokenization method, and he said, “We have no plans to do that.”
That SCARES ME.
Furthermore, I don’t believe that statements such as “[the token vault] should be properly segmented from all other systems and protected like the crown jewels” comes close to providing any kind of implementation guidance or security requirements for properly protecting the cardholder data. Exploiting trust relationships. IP spoofing. Man-in-the middle attacks. Session Hijacking. Sniffing credentials. Masquerading. These are some of the things I worry about, and I’ve seen no mention of this in any of the tokenization forums, blogs, white papers, vendor slicks, etc.
I’ll pause for now because I’m very curious to hear what others have to say about this topic.
Thanks for putting it out there!
December 16th, 2011 at 4:08 am
“High-value tokens are those that can be used to initiate a new card transaction.”
Personally, I didn’t understand this part of the doc. Surely that’s the point of a token, so I’m assuming they mean a token that can be used independently of a ‘vault’ type of service to initiate and complete a transaction.
Otherwise every token would be a High Value token. Services like Square’s card case where a person’s name can trigger a payment, or PayPal’s where an email and password trigger a card payment. In these cases a name and email would be tokens and as they are initiating a card payment could be considered a High Value token.
Given this, then even a persons name and email address could now be in scope for PCI.
In my opinion, the guidance doc needs better clarification of terms and use cases
December 16th, 2011 at 12:20 pm
Cards and PANs are issued with lots of terms and conditions of operation, management, use, and liability involving the issuer, the consumer, the brand, and the acquirer – contracts – and very complex ones. If anyone can issue a ‘tool’ (a piece of data or something physical) which directly references the original card and PAN in the same way – to initiate a payment – even in a specific domain of use, then it becomes a Payment Instrument in its own right. Payment Instruments are regulated. So, this creates a gap in contracts. Who takes liability for an exposure or breach in this case ?
With the proliferation of tokenization, I’m sure the brands don’t want just anyone acting as a proxy to a live card without a contractual framework in place equal to that already in place for the card network.
Similarly, if such a tool is created, then surely it makes sense to protect it in the same way as a card – otherwise you’ve just shifted the risk from one entity to another- and worse, without a framework for managing liability – very risky.
Tokens aren’t magically immune from risk and liability – their scope of use needs to be considered.
December 16th, 2011 at 11:47 pm
A closing thought – and an open question.
How can QSA be comfortable determining if something is out of scope, if he or she does not know how the system providing that benefit explicitly works in all conditions over its lifetime – especially if its distributed and may its functionality and risk profile may change over time – and can be explicitly guaranteed ?
A QSA takes liability for such a de-scoping claim. Only proofs of security and evidence can stand behind that – something seriously lacking in most of the debate.
January 2nd, 2012 at 12:47 pm
Walt – thanks for the article.
I have a couple of things to add to the discussion. I’ve said it before and I say it here again – Tokenization is a use case of data transformation, not a specific technology. Humans have been practicing tokenization using multiple methods for centuries and claiming that one method of data transformation is the “real” tokenization and not some other way doesn’t make sense.
Tokenization must be reversible, as Andrew points out above. Claiming that one reversible method is more secure than another is difficult to defend without a thorough understanding of the context. And unfortunately, the reversibility of random number assignment systems for tokens currently depends on very attackable application systems like operating systems and database platforms.
As far as “high-value” tokens goes, I have the unfortunate distinction of bringing that particular topic into the discussion in the PCI SIG. Understanding why a “high-value” token does not change PCI DSS scope, in my opinion, requires a discussion on the differences between fraud protection and data protection. The long and short of it – a token that can be used to initiate a transaction (your hotel room number for instance) can still be used to perpetrate fraud, but it still does not expose the cardholder data. I can generate PANs all day long and use them to commit fraud, but that doesn’t mean I have breached a system where that data might be housed. We need to be clear that DSS controls are not in place to prevent fraudulent behavior.
January 29th, 2012 at 5:01 am
“… or PayPal’s where an email and password trigger a card payment.”
As a matter of interest, I doubt the above activity directly triggers a card payment.
PayPal has stated—in a letter to the US Fed. circa May 2011 (http://www.cnbc.com/id/42916668/)—that PayPal is “not a debit card or payment network – it is a large merchant of sorts.”
And, indeed, for a change, there is truth in this statement. PayPal, indeed, does all their online “payments processing” not via their own system or directly by the banks’ system but simply by riding, precariously, on the back of the banks’ existing systems.
For accessing PayPal users’ funds other than from a PayPal “account” (in effect an unlicensed bank deposit account) or as a “large merchant of sorts” by direct debiting users’ banking accounts, in effect, PayPal operates a credit card merchant account (with the Wells Fargo bank) to then charge users’ credit cards.
PayPal is one more unnecessary middleman. Where the responsibility lays for security here, who knows? And they certainly are a source of concern for eBay merchants as the linked story in the “Guardian” on 27 January demonstrates.
Still, in due course, Visa’s professional offering, V.me, will undoubtedly drive PayPal back into its eBay box, and that should solve whatever security problem PayPal poses, off eBay at least..
As a merchant, you offer PayPal at your peril.