4 min read

What is Banking-Grade Tokenization According to PCI DSS

What is Banking-Grade Tokenization According to PCI DSS

The concept of a token has been used in the digital world for almost 50 years to separate and protect real data elements from exposure. In recent times, the concept of tokenization has been used as a security mechanism for protecting sensitive data.

When using tokens for data security, non-sensitive data elements that have no exploitable value act as a substitute for sensitive data elements. The tokens act as an identifier/reference that maps back to the sensitive data that is being protected through the tokenization system. Here we look at banking grade tokenization in relation to PCI DSS.

Tokenization is ideal for protecting sensitive data in banking applications and is used for credit card processing, bank accounts, loan applications, and financial statements. For these purposes, tokenization can protect personally identifiable information (PII) from falling into the hands of cyber-criminals.

How Does Tokenization Differ from Encryption?

Encryption and tokenization, when properly implemented, are effective ways to protect data. Ideally, both should be used in security solutions designed to protect data. However, while both methods are capable of protecting data, the way that they do it differs in the processes of how each accomplishes that job.

The most important difference between encryption and tokenization is that the latter can take a non-mathematical approach to replacing sensitive data with a non-sensitive substitute that does not alter the original type or length of the data being protected. Meanwhile, encryption works by making changes in the type and length of data that renders that information as unreadable in databases and other intermediate systems. Yes, tokenized data is secure, but it is still able to be processed by legacy systems. This makes tokenization more flexible that encryption.

Compared to encryption, tokenization generally consumes much less computational resources during processing. This is because some data is kept completely or partially visible for processing and analytic purposes. Meanwhile, the sensitive information that is being protected remains hidden. This allows data that is tokenized to be quickly processed while the strain on system resources is reduced. Tokenization can be advantageous when used on systems that rely on speed and high performance.

How Are Tokens Classified?

There are multiple ways in which tokens can be classified according to the level of security required to protect sensitive data. In the case where ensuring that payment card data is kept secure, there are three types of tokens, in which to be aware of:

  1. High-value tokens
  2. Low-value tokens
  3. Security tokens

When used for payments functions, high-value tokens (HVTs) and low-value tokens (LVTs) or security tokens perform different functions. HVTs and LVTs are considered payment tokens, which follow FINMA’s (Switzerland’s independent financial-markets regulator) guidelines. Security tokens, which follow the guidelines of the U.S. Securities and Exchange Commission (SEC) act in the same manner as LVTs. 

  • High-value tokens act as surrogates for Primary Account Numbers (PANs). These tokens are secure and randomly generated. If a hacker were to intercept this token, its data would be useless because it would not contain any cardholder information. The PAN cannot be retrieved even if its token and the system it originates from are compromised. The HVT cannot be reverse-engineered either to reveal the PAN.
  • Low-value/Security tokens can also act as surrogates for PANs in payment transactions but not in the same way as HVTs. On its own, an LVT or security token cannot be used to complete a payment transaction. Each requires the ability to match it to the PAN that it represents, however, this is done in an extremely controlled environment. The tokenization system must be secured to prevent breaches that would jeopardize the security of tokens that protect PANs.

Tokenization and PCI DSS

Any organization that processes, stores, or transmits credit or debit cardholder data must protect that data as mandated under the Payment Card Industry Data Security Standard (PCI DSS). Tokenization is often implemented on payment systems to comply with the mandate to protect stored credit card data. Tokenization replaces credit card and ACH (Automated Clearing House) numbers with a string of characters or a random value. Often the token is the last four digits of the card number.

When an authorization request is processed for a payment card, a token may be returned to the merchant instead of the actual card number along with the transaction’s authorization code. The token is then stored on the receiving system; however, the actual data for the cardholder is mapped to that token and protected by a secure tokenization system. Such systems that store tokens and payment card data are required to comply with PCI DSS requirements.

System Components in a Tokenization System

Token Generation

Common token generation methods include:

  • Mathematically reversible cryptographic functions that are based on known strong cryptographic algorithms and strong cryptographic keys.
  • One-way, non-reversible cryptographic functions, such as a hash function with a secret and strong salt.
  • Creation via a randomly generated number (not mathematically derived from the PAN), index function or sequence number.

Token Mapping

This is the process of assigning a token to the original value of the PAN. When PAN is processed for tokenization, it is common for the PAN and its generated token to be stored in a card-data vault. This allows for the ability to retrieve a particular PAN or token according to the type of request and how the solution has been implemented.

Card Data Vault

The card data vault is the central repository for PANs and their tokens in a tokenization system. It is used in the token-mapping process. Because this component holds both PANs and tokens, it is a prime target for cybercriminals.

New Call-to-action

Cryptographic Key Management

The processes used to create, use, manage, and protect cryptographic keys that are used to protect PAN data fall under cryptographic key management. These keys must be managed and protected according to PCI DSS requirements. When used in a tokenization solution, cryptographic key management refers to the keys used for the encryption PAN and any keys that were used to generate tokens. 

Tokenization Operations

A tokenization solution can be implemented in various ways. As a rule of thumb, tokenization and de-tokenization operations should only be performed within a clearly defined tokenization system. This system should include a process for submitting tokenization and de-tokenization requests with approved applications.

Tokenization Security Considerations

Security considerations for a tokenization system include:

  • Network segmentation from all networks, users, applications, processes, and system components that are not in the scope of PCI DSS.
  • Access limited to only authenticated users and system components of the tokenization system and tokenization/de-tokenization processes. The following authentication items should be considered while evaluating a tokenization solution:
    • Identification
    • Enrollment
    • Authentication
    • Authorization
    • Termination
    • Maintenance
  • Comprehensive monitoring that tracks, monitors and logs all access to and actions that occur within the tokenization system according to PCI DSS requirements.
  • A mechanism to distinguish between tokens and actual PANs that gives merchants or service providers the ability to determine if their tokenization system is properly functioning.
  • Meeting PCI DSS requirements for storing, processing and/or transmitting cardholder data on a tokenization system that is completely PCI DSS compliant.

When implemented correctly, a banking-grade tokenization system is an effective method for protecting critical payment card data.

 

Download white paper

References and Further Reading