This post covers why I think tokenization will radically change payment security.

EMV-compliant terminals offer several advantages over magnetic stripe readers – notably the abilities to communicate with mobile devices, validate chipped credit cards, and process payment requests with tokens rather than credit card numbers. Today’s post focuses on use of tokens in EMV-compliant payment systems. This is critically important, because when you read the EMV tokenization specification it becomes clear that its security model is to stop passing PAN around as much as possible, thereby limiting its exposure.

You do not need to be an expert on tokenization to benefit fully from today’s discussion, but you should at least know what a token is and that it can fill in for a real credit card number without requiring significant changes to payment processing systems. For those of you reading this paper who need to implement or manage payment systems, you should be familiar with two other documents: the EMV Payment Tokenization Specification version 1.0 provides a detailed technical explanation of how tokenization works in EMV-compliant systems, and the Payment Account Reference addendum to the specification released in May 2015.

If you want additional background, we have written plenty about tokenization here at Securosis. It is one of our core coverage areas because it’s relatively new for data security, poorly understood by the IT and security communities, but genuinely promising technology. If you’re not yet up to speed and want a little background before we dig in, there dozens of posts on the Securosis blog. Free full research papers available include Understanding and Selecting Tokenization as a primer, Tokenization Guidance to help firms understand how tokenization reduces PCI scope, Tokenization vs. Encryption: Options for Compliance to help firms understand how these technologies fit into a compliance program, and Cracking the Confusion: Encryption and Tokenization for Data Centers, Servers and Application to help build these technologies into systems.

Merchant Side Tokenization

Tokenization has proven its worth to merchants by reducing the scope of PCI-DSS (Payment Card Industry Data Security Standard) audits. Merchants, and in some cases their payment processors, use tokens instead of credit card numbers. This means that they do not need to store the PAN or any associated magstripe data, and a token is only a reference to a transaction or card number, so they don’t need to worry that it might be lost of stolen. The token is sufficient for a merchant to handle dispute resolution, refunds, and repayments, but it’s not a real credit card number, so it cannot be used to initiate new payment requests. This is great for security, because the data an attacker needs to commit fraud is elsewhere, and the merchant’s exposure is reduced.

We are focused on tokenization because the EMV specification relies heavily on tokens for payment processing. These tokens will come from issuing banks via a Token Service Provider (rather than from a merchant); the TSP tracks tokens globally. That is good security, but a significant departure from the way things work today. Additionally, many merchants have complained because without a PAN or some way to uniquely identify users, many of their event processing and analytics systems break. This has created significant resistance to EMV adoption, but this barrier is about to be broken. With Draft Specification Bulletin No. 167 of May 2015, EMVCo introduced the Payment Account Reference. This unique identification token solves many of the transparency issues that merchants have with losing access to the PAN.

The Payment Account Reference and Global Tokenization

Merchants, payment gateways, and acquirers want – and in some cases need – to link customers to a payment instrument presented during a transaction. This helps with fraud detection, risk analytics, customer loyalty programs, and various other business operations. But if a PAN is sensitive and part of most payment fraud, how can we enable all those use cases while limiting risk? Tokenization.

EMVCo’s Payment Account Reference (PAR) is essentially a token to reference a specific bank account. It is basically a random value representing a customer account at an issuing bank, but cannot be reverse-engineered back to a real account number. In addition to this token, the EMV Payment Tokenization Specification also specifies token replacement for each PAN to reduce the use and storage of credit card numbers throughout the payment ecosystem. This will further reduce fraud by limiting the availability of credit card numbers for attackers to access. Rather than do this on a merchant-by-merchant basis, it is global and built into the system. The combination of these two tokens enables unambiguous determination of a customer’s account and payment card, so everyone in the payment ecosystem can leverage their current anti-fraud and analytics systems – more on this later.

Let’s look at PARs in more detail:

• PAR is a Payment Account Reference, or a pointer to (what people outside the banking industry call) your bank account. PAR is itself a token with a one-to-one mapping to the bank account, intended to last as long as the bank account. You may have multiple mobile wallets, smart cards or other device, but that PAR will be consistent across each.
• The PAR will remain the same for each value of PAN; as a payment account may have multiple PANs associated with it, the PAR will always be the same.
• The PAR token will be passed, along with the credit card number or token, to the merchant’s bank or payment processor.
• A PAR should be present for all transactions, regardless of whether the PAN is tokenized or not.
• PAR tokens are generated from a Token Service Provider, requested from and provided via the issuing bank.
• A PAR will enable merchants and acquirers to consistently link transactions globally, and to confirm that a Primary Account Number (PAN) (your credit card number) is indeed associated with that account.
• A PAR has a one-to-one relationship with the issuing bank account, but a one-to-many relationship with payment cards or mobile devices.
• For the geeks out there, a PAR cannot be reverse-engineered into a bank account number or a credit card number, and cannot be used to find either of those values without special knowledge. Token Service Providers will use format preserving encryption, tokens created from random numbers, or – given the requirement for global consistency – code books or one-time pads.
• The specification envisions a tokenized value of the PAN being used, but this is not currently mandatory, so the spec currently permits legacy usage of the original credit card number as a PAR.

The relationship between the PAR token, the Primary Account Number (PAN) and the payment token can be envisioned like this:

What Is The Impact?

PAR removes the majority of merchant objections to tokenization and loss PAN, and when combined with a payment token, provides better value than the PAN alone. Essentially the complains about removing PAN are addressed. And the loss of functionality with just a payment token are addressed as well.

“In theory there is no difference between theory and practice. In practice there is.” –Yogi Berra

An EMV card, or a mobile wallet, enables a terminal to validate the authenticity of a payment object presented by a customer. That is no surprise, but it gets much more interesting when you consider the PAR value. The technical specification for the PAR defines an open standard for exchanging authorization data between the various stakeholders, as well as processes for provisioning and payment transactions. This essentially means Visa, MasterCard, and Europay – in concert with the issuing banks – are now identity providers for merchants, payment networks, and acquirers.

Unlike identity providers such as Facebook, Google, and Twitter – who manage identities as a service for unaffiliated sites to leverage their user identities, the PAR value is intended solely for use within the payment ecosystem. And unlike services that leverage SAML or OAuth tokens, the PAR is not an identity token as such, and not interchangeable. The PAR technical specification emphatically states that a PAR is not a consumer identifier, but due to the way a single PAN and CCV value are issued for all credit cards in a single household, inevitably it will be in practice. A PAR token offers the same granularity as a home phone number or a PAN today, and both merchants and acquirers can glean enough intelligence from the transaction context to determine which card user is behind one if needed. Privacy buffs will have a problem with this, but it is no worse than what has been going on for decades.

A PAR is not to be provided to consumers, and should only be shared among firms which process payments. Undoubtedly attackers will go after PARs first, as well as PAN or tokenized PAN values. A PAR should not be used to initiate payment transactions but attackers will inevitably test merchant, acquirer, and payment services vendors to see how well they obey the rules.

A PAR should enable Point to Point Encryption (P2PE) without the loss of data elements merchants want for anti-fraud, consumer tracking, affiliate programs, and various other programs. Some merchants will still dislike tying themselves to a single payment processor or acquiring bank, but the PAR removes most of the other impediments. With a PAR token to unambiguously identify customers, merchants can manage most current analytics, even if P2PE is used from the swipe through the payment gateway to the merchant bank.

We have explained for years that payment data security requires several supporting technologies: Chip and PIN for user and device authentication, P2PE for data transmission, and tokenization or FPE for record storage. The forward-looking PAR specification accommodates all three, with minimal impact on business operations. As this approach is rolled out it will disrupt existing card security programs and PCI certifications, and should force attackers to change their tactics. This is a major win for both merchants and banks.