Gartner Blog Network

Restarting the Discussion: Tokenization is Encryption (part 1)

by Ramon Krikken  |  April 11, 2012  |  2 Comments

It’s been a while since I blogged about tokenization. My last post on the subject drew some interesting comments – and conflicting comments at that: one commenter argued equating tokenization and encryption is bad for tokenization because tokenization is more secure per se. Another, however, commented that it’s in fact bad for encryption because encryption is based on proven algorithms while tokenization is not. Are these indeed contradicting views?

Interestingly enough, both commenters pose valid concerns. This is possible because the first view is based on architecture distinctions while the second is based on algorithm distinctions. In the end, though, tokenization is a form of encryption: the system builds a secret code book that contains the mappings between the plain texts and the cipher texts (or codes). In essence, it’s a symmetric block cipher in ECB mode.

Looking at history, we actually see many crypto systems based on code books. A famous example is the Navajo code talkers used in World War II. A lot of people get hung up on the “but tokenization doesn’t have a key” thing … problem is,  it most definitely does have one in the form of the code book. Those that disagree with such large things being called keys must by extension conclude the one time pad isn’t encryption either. An untenable position if you ask me.

So why do I keep banging this drum? IOW, why is it important to acknowledge this? The reason is simple: the security created by a tokenization system is first and foremost dependent on its architecture. Algorithms are of course extremely important, but a the best algorithm in the world simply can’t save a bad protocol / design / implementation. The rules by which tokenization and encryption have to play are identical.

However, there is a problem in practice: the way encryption and tokenization are defined in the PCI DSS, and how they impact PCI scoping as a result of that definition … but more on that in the next post, which will also address the “based on math” argument brought forward in a three-piece vendor counter-argument to my original post.

Additional Resources

View Free, Relevant Gartner Research

Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

Read Free Gartner Research

Category: security  

Tags: code-book  cryptography  encryption  pci  pci-dss  tokenization  

Ramon Krikken
BG Analyst
2 years at Gartner
15 years IT industry

Ramon Krikken is a Research VP the Gartner for Technical Professionals Security and Risk Management Strategies team. He covers software/application security; service-oriented architecture (SOA) security; structured and unstructured data security management, including data masking, redaction and tokenization...Read Full Bio

Thoughts on Restarting the Discussion: Tokenization is Encryption (part 1)

  1. Mark Bower says:

    I still think there’s room – and a need – for the PCI Council to create a validation criteria for Tokenization as defined in their guidance document. I agree that there needs to be a process by which the methods of operation and use are validated just as encryption technology is today.

    This is especially important when making “out of scope” claims. How can something be assessed to be out of scope if the black box thats providing that capability itself has no validation other than a cursory acceptance?

    Would a government permit medication to be dispensed that claims to guarantee a specific and miraculous cure without any independent scientific approval? Very unlikely today, but maybe 100 years ago in a world more ignorant but looking for a quick fix – to the benefit of the snake oil liniment salesman of yesteryear.

    If we contrast this with the cryptographic world, it would be the same as saying an unpublished algorithm can be trusted because someone simply says so therefore trust it and its implementation. Perhaps this may also come with an independent claim of validity but without any real proof. That kind of posture goes nowhere fast in hard risk terms: it breaks Kerckhoffs unswerving rule – do not rely on secrecy or security claims without open proof and most of all assume your attacker knows everything about your scheme to any level of detail. Lastly, in the event of a compromise, ensure that the things that need to change to recover secure operation are the least expensive, least impactful things in the system to manage.

    Yes, tokenization is a useful and valid technique or risk mitigation – but only with published open proofs of method and operation that stand up to independent cryptanalysis – in public. Methods purported to be “analyzed” – technobabble – yet with no public open proof only take advantage of the eager buyer who is inexperienced with security and wanting data breach risks to magically disappear. Sadly, the risks wont be addressed and the outcome will likely be a costly but valueless investment resulting a worst case scenario – compromise without detection – the attackers dream of a fully exploitable system that can be breached with minimal effort.

    If an provider isn’t confident that their implementation can stand up to completely independent and open scrutiny then its very likely they don’t actually know that its really secure.

    Mark Bower
    VP Products
    Voltage Security

  2. Ultimately I don’t think the argument is around tokenization vs. encryption but more on the lines of what constitutes valid “cryptographic techniques”. Both tokenization and encryption obfuscate the original information. Your argument seems more focused on how one or the other ensures the original data is secure. This argument can’t be decided at this level of discussion. Both tokenization and encryption are vulnerable to poor implementation and security practices. The real question is how do you ensure you’ve protected your data whatever scheme you’ve used to disguise your data. A weak token or encryption method will fail equally fast and easily. I’d like to see a discussion on how to ensure tokenization is secure, not if it’s encryption. Of course it is.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.