Tokens Are Not The Same As Encryption. Honest
Written by Walter ConwayA 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.
It’s now been four months since the PCI Council’s guidance on tokenization, and people are still mixing up tokenization and encryption. They are also drawing incorrect parallels/inferences. Tokenization is not encryption. Trying to compare the two is not appropriate (or like comparing quarks to streetcars or your other favorite silly similes), and doing so can lead to mistakes in scoping PCI.
By the way, after much effort, I think I finally found a real-world example of what a high-value token should be. Let’s say I want to use my payment card at a merchant, but I don’t want that merchant to have my PAN for whatever reason. Let’s also say I can give my PAN to a trusted issuer or service provider, and that company in turn gives me a token to use at that untrusted merchant. Because that token—whatever it looks like—could be used by me (or anyone) to initiate a new transaction against the underlying payment card, that token would fit the definition of a high-value token requiring additional safeguards. I might even consider that high-value token to be in PCI scope.
The PCI Council’s tokenization guidance was designed to help merchants (and QSAs) determine PCI scope with tokenization. The document specifies seven objectives to be met for tokens to be considered out of scope, plus another eight recommendations to reduce scope with tokenization.
Everyone should note that the guidance is just that: guidance. Although everyone reads the same document, some merchants, vendors and QSAs may come to different conclusions as to what is and is not in scope with tokenization. I attribute at least part of this situation to a muddling of tokenization and encryption in people’s minds. Whatever the reason, the result for a merchant implementing tokenization is that it may find itself in a protracted argument internally, with competing vendors or maybe even with its QSA as to what is in and what is out of PCI scope.
Tokenization has the potential to both reduce a merchant’s PCI scope and limit the risk of a cardholder data breach. The technology reduces scope by restricting cardholder data to the token vault, which should be properly segmented from all other systems and protected like the crown jewels. It reduces the risk of a data breach, because everybody in the organization now uses tokens instead of cardholder data. So, theoretically at least, there should be a lot less PAN data to be compromised.
Merchants implement tokenization in one of three general ways: The solution can be outsourced to a third party, such as a processor or specialized tokenization vendor; it can be developed internally by the merchant; or the merchant can adopt a hybrid approach using a third-party solution but hosting it internally.
Irrespective of the implementation, tokenization differs from encryption. For example, encryption is reversible while random tokens are not. In terms of scope, the PCI Council settled the question of whether encrypted data is in or out of scope in its FAQ #10359, which states: “encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” Therefore, if anyone in the organization can decrypt the data, the encrypted data is in scope everywhere it appears. Conversely, if no one can reverse the encryption, the encrypted data is out of scope.
Tokens, however, are not (or at least should not be) reversible.
-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.