As a security technology that obfuscates clear text data, tokenization is the red-headed stepchild compared to encryption. That’s changing, however, as tokenization has a key role in enabling mobile payment systems such as Apple Pay, Samsung Pay and Android Pay. If you use any of these smartphone-based payment applications, tokenization is already at work for you.
Unless you’re in the payments industry, you might not even know what tokenization is, or how it can protect sensitive data. Yes, there are uses for the technology beyond securing payment data. I’ll talk use cases in a minute, but first let me explain what tokenization is.
Tokenization is the process of turning a meaningful piece of sensitive data, such as a social security number, into a random string of characters (called a token) that have no meaningful value if breached. Unlike encryption, tokenization does not use a mathematical algorithm to transform the data value into the token. Instead, the clear text data value goes into a secure database, called a vault or a dictionary, where it is encrypted. In its place you are given a token that can be used in your regular applications. An index stores the relationship between the real data value and its token. If you need to retrieve the original piece of data, you present the token to the index and it looks up the real data value.
The most important thing to know about a token is that it can’t be turned back into the real data value if the token is stolen. There’s no algorithm or key that can turn the token into data. The thief would have to gain access to the highly secure token vault – which itself is protected with encryption – in order to retrieve the original data value.
You can see that tokenization and encryption are frequently used together to bolster data security. They are actually complementary technologies more than alternatives to each other.
The primary use case today for tokenization is to secure payment card data. PCI DSS had a big hand in the technology’s adoption. Regulations require annual security audits for every environment in which cardholder data is present. It used to be common for merchants to keep payment card data after purchase transactions were authorized. They would use this data to analyze customers’ purchasing histories, to develop marketing programs, to reward loyalty points, and so on.
Once PCI DSS came along, merchants were required to fully secure this data and to undergo intense scrutiny via annual audits. Merchants discovered they could use tokens instead of real card numbers for all of their ancillary purposes, and also reduce their audit requirements at the same time by fully removing real data from their backend applications.
Today mobile payments are dependent on tokenization to ensure secure transactions. The latest iterations of smartphone-based payment applications store tokenized versions of your credit card numbers in a secure element chip on the device or in a hosted card environment in the cloud.
When you go to use Apple Pay, for example, the phone app authenticates you via a fingerprint scan and sends the card token and a cryptogram via near field communications (NFC) to the merchant’s point-of-sale terminal, which passes them to the card network (e.g., Visa, MasterCard, etc.). The network authenticates the token and the cryptogram and forwards them to the bank that issued the payment card. The bank decrypts the token, determines its authenticity, associates it with your real account number and authorizes the transaction. The merchant is credited with the amount of the sale and your account is debited. This all happens in a matter of seconds at the point-of-sale.
Tokens are increasingly being used beyond payment applications. One major use case is when a company wants to store data in the cloud, but data sovereignty laws prohibit putting the real data – even if it’s encrypted – in a cloud application that may allow the data to cross international borders, such as for data backups. In this case, the company can tokenize the data before sending it to the cloud app. Without the real data being present, there is no violation of data sovereignty restrictions.