In the digital age, protecting sensitive payment information has never been more paramount. Especially with the rise of e-commerce and remote transactions, the importance of securing card-not-present interactions has become increasingly critical.
While there are myriad measures to safeguard data, tokenisation emerges as the most effective. By transforming sensitive card details into indecipherable code, tokenisation thwarts potential fraudsters and data breaches. Tokenisation is also effective in reducing PCI scope and simplifying PCI compliance.
In this article, we will explore how tokenisation works and its associated requirements for PCI DSS compliance.
What is Tokenisation?
Tokenisation when applied to payment card security and PCI DSS compliance is the practice of substituting the Account Data with surrogate values, called tokens. The data that can be tokenised include Primary Account Number, card data, card holder and authentication data.
The data once tokenised is safeguarded by the tokens, prevented from being intercepted or stolen in case of a data breach. These tokens cannot be reverse engineered and traced back to the original data.
Tokenisation in a contact centre environment
The need to tokenise data is even more crucial in a contact centre environment where account information is gathered through various channels. This data can originate from an Agent Interactive Voice Response (IVR) system, either as voice or Dual-Tone Multi-Frequency (DTMF) tones, or directly from customer phone calls.
More critically, as this data traverses the payment process, it may be stored at certain points – to facilitate transactions, for customer service purposes, or to manage recurring payments. However, the storage of account data presents its own challenges. It often needs to be accessible to customer service agents, creating multiple potential points for data breaches and misuse.
When a merchant stores account data, they are obligated to protect it in accordance with the Payment Card Industry Data Security Standards (PCI DSS). These standards are not just guidelines but mandatory compliance requirements for protecting sensitive payment information in any merchant environment.
Tokenisation when businesses have more than one business units
How does tokenisation manage risks?
So how does tokenisation manage this risk? When you analyse the process carefully, the account data, especially the Primary Account Number, isn’t needed in each step of the payment process. In the flow described above the credit card information is only needed at the verification stage within the payment gateway. For all other stages, a token containing masked data is sufficient.
Tokenisation is how the credit card data is protected. The tokenised credit card information acts as a placeholder in the payment process. For example, a credit card may be tokenised as 411111abcxyz1111, where 4111 and 111 correspond to real numbers of the credit card.
Although it seems straightforward, ensuring the security of tokenised data against easy decoding is not a simple task. It involves more than a basic one-to-one substitution, as the process must guarantee that the tokenised data cannot be reverse-engineered and linked back to the original information.
Acknowledged the significance and sensitivity of this topic, PCI Security Council has even issued a separate supplement on tokenisation to the PCI DSS standards.
PCI DSS Supplement on Tokenisation
The fundamental principles that govern the tokenisation for PCI in its tokenisation supplement are outlined below.
Tokenisation solutions do not eliminate the need to maintain and validate PCI DSS compliance, but they may simplify a merchant’s validation efforts by reducing the number of system components for which PCI DSS requirements apply.
Verifying the effectiveness of a tokenisation implementation is necessary and includes confirming that PAN is not retrievable from any system component removed from the scope of PCI DSS.
Tokenisation systems and processes must be protected with strong security controls and monitoring to ensure the continued effectiveness of those controls.
Tokenisation solutions can vary greatly across different implementations, including differences in deployment models, tokenisation and de-tokenisation methods, technologies, and processes.
Merchants considering the use of tokenisation should perform a thorough evaluation and risk analysis to identify and document the unique characteristics of their particular implementation, including all interactions with payment card data and the particular tokenisation systems and processes. Remembering that the PCI DSS standards apply to any organisation that stores, processes or transmits credit card data.
Tokenisation vs Encryption
Tokenisation can be achieved through various methods, and it might be tempting for some to consider using encryption algorithms, as they seem to serve a similar purpose at first glance. However, there is a nuanced difference between encryption and tokenization that is important to understand.
Encryptions are usually reversible mathematical functions and can be deciphered with the right key and algorithm. They are mostly used to share data confidentiality across systems.
Tokenisation, on the other hand, are not generated mathematically and cannot be deciphered using an encryption key. They are randomly generated and are meant to hide the data, not to share the data. The Account Data can only be identified via a token vault which maps the relationship between the token and the original data. Encryption is then applied to the vaults to safeguard the maps.
Choosing the Right Tokenisation Method
Tokens can be single-use or multi-use. In single-use systems, they are only used for a single transaction and then discarded. The multi-use tokens are used to track and collaborate the data over multiple systems and may even be stored in databases for reuse. The choice of single-use or multi-use and the methods are dependent on the specific needs of the system and should be made carefully taking into business and security needs of the merchant.
The PCI DSS supplement identifies common ways tokens can be generated but are not limited to:
A mathematically reversible cryptographic function, based on a known strong cryptographic algorithm and strong cryptographic key (with a secure mode of operation and padding mechanism)
A one-way non-reversible cryptographic function (e.g., a hash function with strong, secret salt)
Assignment through an index function, sequence number or a randomly generated number (not mathematically derived from the PAN)
In the case of hash functions, additional controls need to be added to remove the risk of reverse engineering in particular if the hashed and truncated version of the hash version is present in the same environment. In this case, to be PCI DSS compliant, other controls need to be put into place to ensure hashed and truncated versions cannot be correlated to reconstruct the original account data details.
Security of Tokenisation Vaults
Tokenisation Vaults can become the single point of failure, and they need to be guarded with stringent security measures. It is critical to have these systems adhere to PCI DSS controls.
As per the PCI DSS tokenisation supplement, characteristics of a tokenisation system that meets PCI DSS requirements include but are not limited to the following:
The tokenisation system does not provide PAN in any response to any application, system, network, or user outside of the merchant’s defined CDE.
All tokenisation components are located on secure internal networks that are isolated from any untrusted and out-of-scope networks.
Only trusted communications are permitted in and out of the tokenisation system environment.
The tokenisation solution enforces strong cryptography and security protocols to safeguard cardholder data when stored and during transmission over open, public networks.
The tokenisation solution implements strong access controls and authentication measures in accordance with PCI DSS Requirements 7 and 8.
The tokenisation system components are designed to strict configuration standards and are protected from vulnerabilities.
The tokenisation solution supports a mechanism for secure deletion of cardholder data as required by a data-retention policy.
The tokenisation solution implements logging, monitoring, and alerting as appropriate to identify any suspicious activity and initiate response procedures.
What is De-Tokenisation?
De-tokenisation is the act of converting the tokenised Account data when it is required. The system should be designed to remove any risk of unauthorised de-tokenisation with strong access controls with well-defined roles and stringent authentication mechanisms.
Conclusion
Tokenisation is an instrumental technique to limit the exposure of Account data in payment systems and to achieve PCI DSS compliance. On its own, tokenisation does not guarantee PCI DSS compliance but is considered best practice to reduce PCI DSS scope and minimise your PCI DSS compliance burden, costs and risks.
IPSI are leaders in providing tokenisation solutions including cloud-based, omnichannel capabilities with ancillary credit card scanning capabilities. To discuss your tokenisation needs, please contact us on 1300 975 630 or email us at [email protected].
The advantages of IPSI tokenisation capabilities:
IPSI offers up to 14 customisable token formats tailored to your needs.
IPSI tokenisation capabilities support independence among different businesses by enabling them to selectively restrict or permit data access between units. This not only accelerates payment processes but also ensures customer data protection through controlled access across various departments or segments of the business.
IPSI platform efficiently facilitates de-tokenisation as part of its standard business operations, ensuring a smooth process under the appropriate controls and considerations. This functionality allows merchants to transition to new providers with ease and minimal disruption.
This approach allows for a tailored balance of information sharing to enable faster payment, at the same time safeguard customers data by restricting data access across different departments or sections within a business.
To discuss your tokenisation needs, please contact us on 1300 975 630 or email us at [email protected].
Comments