Mobile payments and electronic commerce (e-commerce) are booming globally. Businesses continue to roll out innovative omnichannel capabilities, which allow consumers to shop, purchase, and ship merchandise from practically anywhere to basically everywhere. Indeed, eMarketer estimated worldwide e-commerce would reach $1.6 trillion in 2015, up 25% from 2014.
The growth has continued despite headlines revealing businesses’ ongoing struggles to protect payment data. In 2015, for instance, the U.S.-based Identity Theft Resource Center (ITRC) reported there were 781 total reported breaches, the second highest annual number on record since 2005 (when ITRC began tracking data). The 781 breaches exposed over 169 million records, which included 800,000 credit/debit card numbers.
Security concerns persist throughout the payment ecosystem, but solutions are emerging to address the threats and vulnerabilities that put primary account numbers (PANs) and other sensitive payment data at risk.
Tokenization versus “classic” encryption
Both tokenization and “classic encryption” effectively protect data if implemented properly, and an ideal payment security solution will use both. However, tokenization and classic encryption differ in several key ways. Explaining all of the differences goes well beyond the scope of this post.
One key distinction is particularly relevant: Unlike classic encryption, tokenization will never change the length of the data it protects, which is extremely attractive since many legacy systems will not allow changes to data field length (e.g., in databases).
Types of tokens
There are numerous ways to classify tokens, including single use and multi-use, reversible and irreversible, cryptographic and non-cryptographic, authenticable and non-authenticable, and various combinations thereof. All token classifications and their distinctions are beyond the scope of this post, but Payment Card Industry Data Security Standard (PCI DSS) documentation includes detailed guidance.
Unfortunately, many information sources only implicitly reveal the type of token being discussed, and even fewer highlight important distinctions. To make matters worse, the terminology is not fully mature and agreed upon yet. In effect, usually the audience must make assumptions. In this post, we look at the difference between payment tokens (i.e., high-value tokens) and security tokens (i.e., low-value tokens).
High-value tokens or payment tokens
High-value tokens (HVTs) are values that act as surrogates for actual PANs in payment transactions. Importantly, an HVT solution (e.g., Apple Pay) enables the HVT itself to be used as an instrument for completing a payment transaction. To function, HVTs must look like actual PANs. (For more information on Apple Pay from the merchant and end-user perspectives, see this guide.)
Here are a few key drivers for using an HVT for an actual payment rather than the PAN it is mapped back to:
Multiple HVTs can map back to a single PAN – In very basic terms, HVTs are helpful because they are created out of “thin air” and multiple HVTs can be and are mapped back to a single physical credit card without the owner being aware of it.
Limit range of fraud – HVTs usage can be limited to certain networks (e.g., Apple Pay) and/or merchants (e.g., Apple, Amazon, etc.) whereas PANs cannot.
Bind tokens to devices – HVTs can be bound to specific devices. It would be easy to correlate tokens to some physical device identifier (e.g., media access control [MAC] address, International Mobile Subscriber Identity [IMSI], etc.) along with historical location data. Anomalies between token use, physical devices, and geographic locations could then be flagged as potentially fraudulent.
Low-value tokens or security tokens
Low-value tokens (LVTs) also act as surrogates for actual PANs in payment transactions. They exist for a different reason than HVTs (see below). By design, and in contrast to HVTs, LVTs cannot be used in and of themselves to complete a payment transaction. For LVTs to work at all, it must be possible to match them back to the actual PANs they represent, but only in a tightly controlled fashion.
For example, using an LVT solution, a consumer’s PAN (e.g., 4485-4269-0687-2380) is tokenized by replacing the actual value with the surrogate value, the token (e.g., 0x3K-9u4L-09e8-03i7). This token obviously cannot be used in place of an actual card number in any transaction. It must always be matched back to the actual PAN (e.g., 4485-4269-0687-2380) to complete a payment transaction. This mapping from LVT to actual PAN is done within a “tokenization system.” A tokenization system converts LVTs to PANs and vice versa, and it can reside both in a separate hardware device, as well as on highly secured servers. As we will see below, the whole point of using tokens to protect PANs becomes moot if a tokenization system is breached. Hence, securing the tokenization system itself is extremely important.
The business value of low-value tokens or security tokens
LVTs are also called security tokens because they prove valuable in protecting PANs in several specific scenarios. Suppose, for instance, a malicious actor gains access to the entire disk drive of a payment processing system. The access could be physical or logical (insider) or remote (outside criminal), and the system could be in the merchant, acquirer, or issuer environment. The attacker would encounter one of several scenarios:
If the data on the disk drive were not encrypted or tokenized, then nothing prevents the attacker from using the cleartext PANs in fraudulent transactions and/or selling them in the online black market.
If the PANs were encrypted using classical cryptography but not tokenized, then the attacker could potentially also steal the encryption key (which typically is only a few bytes long) to decrypt the data and then proceed with fraud or resale.
However, if the PANs were tokenized via LVTs and the tokenization system itself is secure, then the data would prove useless to the attacker because LVTs alone cannot be used for payment. Without access to the tokenization system, the LVTs cannot be mapped back to the actual PANs. In this way, the stolen LVTs would prove worthless to the criminal without the reference list.
Stay tuned to the comForte blog as we continue discussing tokenization solutions, use cases, and tradeoffs in future posts. The next post on this topic will address where “security tokenization” or using LVTs fits within your security plan.