white paper

PCI DSS Tokenization Buyers Guide

How enterprises can use tokenization to reduce risk and minimize the cost of PCI DSS compliance

paper Focus: PCI DSS compliance Use Cases that can benefit from tokenization How tokenization eases PCI DSS compliance and increases security How tokenization relies upon but differs from encryption Assessing tokenization deployment options and tradeoffs, and why tokenization may not be cheap to build Checklist of questions for prospective tokenization buyers to ask before they commit to a solution

author
abstract
This guide is designed for PCI DSS compliance officers, PCI Qualified Security Assessors, and other security professionals who are evaluating tokenization as a technology to reduce risk and minimize the cost of PCI DSS compliance. The guide describes how tokenization works in practice and how retailers and other businesses can deploy it to reduce both their risk of a cardholder data compromise and their cost of PCI compliance. It also addresses how tokens are constructed, how they differ from but at the same time rely upon strong encryption, and what are the tokenization deployment options. We conclude with a list of questions your organization should address before committing to any particular tokenization approach.

walter Conway Payment Card Industry Qualified Security Assessor (QSA) at 403 Labs LLC.

Tokenization Buyers Guide

executive Summary .......................................................................................................................1 the Use Case: tokenization in the payment environment............................3 PCI DSS..............................................................................................................................................3 Use Case 1: Internal Tokenization ...................................................................................4 Use Case 2: Service Provider Tokenization ..............................................................5 token Construction ........................................................................................................................7 Building a Token ..........................................................................................................................7 Format-Preserving Tokens ..................................................................................................8 Single-Use and Multi-Use Tokens....................................................................................8 Token Collisions ...........................................................................................................................8 The Lifetime of a Token ........................................................................................................8 tokenization and encryption..................................................................................................9 Different Solutions for Different Requirements ..................................................9 The Role of Encryption in Tokenization ......................................................................9 Point-to-Point Encryption ....................................................................................................9 tokenization implementation alternatives ...............................................................10 Internal Implementation Home Brewed .................................................................10 Internal Implementation Packaged Solution........................................................10 Third-Party Implementation Processor Hosted ................................................11 Third-Party Implementation Token Vendor Hosted .......................................11 tokenization Functionality Some Observations ................................................11 Generating Tokens ....................................................................................................................11 Token Mapping and Securing the Token Vault .......................................................12 Integrating Tokens ....................................................................................................................13 Cryptographic Key Management .....................................................................................13 Reflecting PCI Council and Visa Guidance..................................................................13 tokenization Buyers Checklist.............................................................................................13 Is Tokenization Right for You? ...........................................................................................13 Have You Found All Your Data? ........................................................................................13 How Will You Generate Tokens?.......................................................................................14 Where in the Payment Process Do You Generate Tokens? ...........................14 How Will You Manage De-Tokenization? .....................................................................14 How Will You Address Legacy PAN Data? .................................................................14 Will Tokens Break Your Applications? POS? Business Process?..............14 How Effectively Will You Reduce PCI Scope? ..........................................................14 Outsourcing: What If Your Provider?..........................................................................15 Internal Tokenization: What If You? ............................................................................15 Concluding thoughts: tokenization and pCi DSS ..................................................15 tokenization Checklist.................................................................................................................16 about the author .............................................................................................................................17

Executive Summary
This Buyers Guide describes how tokenization can help enterprises achieve compliance with the Payment Card Industry Data Security Standard (PCI DSS). At its most basic level, tokenization is the process by which we replace a valuable piece of information with a meaningless number or token. In this Buyers Guide the valuable piece of information is the primary account number (PAN), but in a different context it could just as easily be a Social Security Number, drivers license number, birth date, medical information, or any other piece of personally identifiable information (PII). Tokenization has two attractive benefits. It can reduce an enterprises PCI scope and, therefore, cost of PCI compliance. Tokenization also can reduce the enterprises risk of a costly and brand damaging payment card data breach. Unfortunately, while there is a lot of information in the marketplace and a broad array of tokenization providers, there is as yet no agreed industry standard for what constitutes effective tokenization. The purpose of this Buyers Guide is to describe tokenization, explain how it works specifically in the context of protecting payment card data, and explore implementation options. We conclude this Buyers Guide with a list of questions that business and IT professionals need to address before selecting the tokenization solution that best meets their enterprises needs. This paper is aimed at business and IT professionals who are responsible for risk management and PCI compliance, and who are interested in approaches that can simplify the process and reduce the cost of maintaining PCI compliance.

The Use Case: Tokenization in the Payment Environment

The Payment Card Industry Data Security Standard (PCI DSS, or just PCI) is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. All enterprises that store, process, or transmit payment card data are subject to PCI DSS, which is described in Table 1 below. Looking at the table, you might think there are twelve PCI requirements. However by the time you count all the sub-requirements and sub-subrequirements, the total number of requirements is closer to 280. Therefore any technology that can reduce the enterprises PCI scope (i.e., the number of requirements that apply) can similarly reduce the cost and effort of PCI compliance. The benefit of tokenization is that it can reduce PCI scope significantly.

table 1: pCi Data Security Standard - high Level Overview Build and Maintain a Secure Network protect Cardholder Data Maintain a Vulnerability Management program implement Strong access Control Measures regularly Monitor and test Networks Maintain and information Security policy 1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks 5. Use and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications 7. Restrict access to cardholder data by business need to know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes 12. Maintain a policy that addresses information security for all personnel

Tokenization can reduce an enterprises PCI scope by replacing cardholder data with meaningless tokens, thereby shrinking an enterprises PCI scope, i.e., the number of people, processes, and systems that are subject to PCI. Reducing scope simplifies the effort and reduces the cost of becoming and remaining PCI compliant. The key principle is that tokens have no intrinsic relation to a payment card PAN, and therefore tokens should be out of PCI scope. They are not PANs. The degree of benefit (i.e., reduced PCI scope and increased security) will depend on the particulars of each enterprises own cardprocessing environment and practices. How much an enterprises scope can be reduced depends on many factors. While most of this Buyers Guide focuses on implementation, readers should also review guidance from the PCI Security Standards Council (PCI SSC, or PCI Council), which released its Information Supplement: PCI DSS Tokenization Guidelines in August 2011. In particular, the guidelines draw a distinction between tokens that are used in back office applications and those that can be used to initiate a transaction. They refer to the latter type as high value tokens. All

of the information in this Buyers Guide is appropriate for any tokens including these high value tokens. Every enterprise should consult with their acquirer or card processor to determine if they have such high value tokens, and if they do they need to determine whether their tokenization implementation is sufficiently secure to take these high value tokens out of PCI scope. Beyond reducing PCI scope, tokenization increases security because it can reduce an enterprises overall risk of a payment card data breach. Computer hackers focus on locating and stealing payment card data (i.e., the PAN, cardholder name, card expiration date), which they can use themselves or sell to others in a global criminal secondary market. Tokenization concentrates the storage of cleartext PAN data in a secure token vault. It thereby reduces the risk of an expensive and reputation damaging cardholder data breach. While it may seem that putting all your PCI eggs in one basket (i.e., the token vault) may create an attractive target for hackers, the reality is that you now have a single, secure location that you can monitor closely and manage securely.

When evaluating the positive benefits of tokenization for your enterprise, you need to consider the particulars of your own environment. As they say with new cars: your mileage may vary.

Use Case 1: internal tokenization

Tokenization reduces an enterprises PCI scope by replacing PAN data with strings of random numbers or characters. The enterprise then uses these tokens in its systems in lieu of PANs for back office applications such as sales analysis, velocity checking, or customer relationship management. When the enterprise manages the tokenization process itself we refer to it as internal tokenization. Figure 1 illustrates a payment card transaction data flow from the point-ofsale (POS), to the payment application. The enterprises back office, accounting, marketing, loyalty, or even the enterprises data warehouse applications access the PAN database. The boxes in blue are in scope for PCI compliance. In particular, since the back post-purchase applications use PAN data, every system in this diagram is in scope.

Figure 1: PCI scope

PAN POS Payment App

PAN PAN Data

Applications

In-scope

Figure 2 represents that same payment card transaction, but here we have replaced the PANs in the database with surrogate values or tokens. In this case, the token is generated internally (hence the term internal tokenization), and the PAN data are securely stored in a token vault. This implementation removes the post-purchase applications (and the token database) from PCI scope. These out of

scope areas are shown in green. The tokenization engine that generates the tokens is in scope for PCI, as is the secure token vault that stores the tokens and associates them with the original PANs. Figure 1 is a simplified description of a real environment, which may have tens or even thousands of servers and end points that access and store PAN data.

Tokenization can effectively remove all these servers and end points from the enterprises PCI scope. The payoff is a smaller PCI scope and, therefore, reduced PCI compliance expenses including the costs of an outside assessment.

Figure 2: Reducing PCI scope with Internal Tokenization

PAN POS Payment App PAN

Tokens Tokens

Tokens

Applications

PAN, Token In-scope Token Vault Out-of-scope

Use Case 2: Service provider tokenization

External or service provider tokenization is an alternative approach. With service provider tokenization, the enterprise contracts with a separate, outside entity (the service provider) to generate and store tokens. This approach reduces

the enterprises PCI scope further as described in Figure 3, although there will be additional costs (e.g., fees charged by the tokenization provider) and business issues (e.g., loss of control, third-party business risk) to consider. As we will explore later, service provider tokenization has its own particular

business considerations (e.g., difficulty changing service providers) and risks (e.g., service provider business stability).

Figure 3: Service Provider Tokenization

PAN POS Payment App PAN

Tokens Tokens

Tokens

Third-Party Environment Third-Party Token Engine PAN, Token In-scope Token Vault Out-of-scope 3rd Party Applications

In this case the enterprises PCI scope (again, the boxes in blue) is reduced to the POS and the actual payment application that processes and transmits the payment card transaction for authorization. In practice, the third party (in orange) would be either a specialized tokenization vendor or even the enterprises own payment processor or acquirer. The difference between this and Use Case 1 (internal tokenization) is that the tokenization

engine and secure token vault are the responsibility of the service provider, and these systems and processes are in their not the enterprises PCI scope. Figure 4 is a variation on this second use case. Here the enterprise sends the PAN data from the POS directly to the tokenization service provider. The service provider first authorizes the transaction and then returns only the token to the

enterprise. As above, the tokenization process and the token vault are in the service providers PCI scope, but now the service provider is processing the authorization, too. This implementation has the greatest potential impact on reducing PCI scope (in blue), although similar cost and business risk issues would apply here as in Use Case 1.

Figure 4: Service Provider Tokenization at the Point-of-Sale

Tokens POS PAN Payment App Tokens Tokens

Third-Party Environment Third-Party Token Engine PAN, Token In-scope Token Vault Out-of-scope 3rd Party Applications

Token Construction
Tokenization is a data security technology in which valuable information is replaced by strings of random characters or tokens. The tokens themselves have no value outside of the particular context for which they are designed. All of us have used tokens. Some of the more familiar examples of tokens include subway tokens, casino gambling chips, discount coupons, and store gift certificates or gift cards. In each case the token has value in a particular setting (the subway) or location (one casino or one store), but everyplace else the token has no value. The same principle applies to using tokens to replace payment card data. It is critical that any token used to replace a PAN have no relationship mathematically or otherwise to that original PAN. Using the analogy above, there should be no way to convert a casino chip back to legal tender without going to the casino cashier. This point illustrates the central difference between tokenization and encryption. Encryption is a two-way process. What can be encrypted can be decrypted. This is why encrypted PAN data are in PCI scope while properly constructed tokens representing PANs are not. This principle is illustrated in Table 2, below.

table 2: paNs, hashes, encryption, and tokens iteM Primary Account Number (PAN) truncated paN (Different from masked) hashed paN (One way; renders PAN unreadable) encrypted paN (More characters than the PAN and structurally different) token (Like PAN in length and character type, but randomly derived) exaMpLe 4123 4567 8901 2345 4123 45XX XXXX 2345 2fd4e1c6 7a2d28fc 9Ojr73h3d^&hh#&HFH&##ED*HD# 9483 7266 3928 9819 pCi SCOpe In PCI scope Out of scope Out of scope In PCI scope Out of scope

We begin with the actual PAN. That is always in PCI scope, and you store it (electronically or on paper) you must protect it as described in the PCI DSS. Truncating the PAN is one way to remove the data from scope. With truncation you retain only the first six and/or last four digits of the PAN. PCI does not consider a truncated PAN to be in scope. It is important that we not confuse truncation which means deleting all but first six/ last four with masking which means storing the full PAN, but displaying only the first six/last four digits. Another way to remove PAN data from scope is with a secure one-way hash. Encrypted PANs, however, are still in PCI scope. The reason is that encryption is a reversible function what can be encrypted can be decrypted. The one exception to this rule is if the enterprise has no ability to decrypt the data. In that one, special case (which we describe below) the encrypted data may be considered out of PCI scope.

Lastly we have a random token. The token may be the same length and share many characteristics of a PAN, but there can be no mathematical relation between the token and the associated PAN. That is, for tokenization to be effective there should be no way mathematically to reverse engineer a token and get back to the original PAN. Each of these approaches has advantages and disadvantages. Truncation clearly removes the data from scope, but truncated data may not be useful for many back office applications like fraud prevention or loyalty programs. Both hashed and encrypted values can contain alphabetic and non-numeric characters, which make either approach difficult to use with existing applications. Most legacy applications require a value that more closely resembles a PAN. All of which brings us to the inherent advantage and attractiveness of a token solution. A token can be made to resemble a payment card, including

sharing some of the digits from the original PAN (e.g., preserving the last four). That means the enterprise does not necessarily have to rewrite back office or post purchase applications. Tokens can, therefore, potentially be used for repeat purchases, recurring payments, and even chargebacks and refunds in addition to the post-processing applications described above.

Building a token
The single most important requirement in constructing a token is that it not be reversible. That is, knowing only the token, it should be computationally impossible to reverse engineer a token and get back to the original PAN. This requirement guarantees the token has value only in the enterprises own environment, and once outside the token is a meaningless string of digits. The best tokens are generated randomly. They may be generated using a hardwarebased random number generator or a 7

pseudo-random number generator based on the SHA family of hash algorithms. As noted above, you have some flexibility in generating tokens. You may, for example, preserve the last four digits of the original PAN, and generate the first 12 digits randomly. Once generated, the token has no meaningful value outside the enterprises environment. You can create tokens with other methods, even using a sequence number, possibly combined with the last four digits of the PAN. Regardless of the approach, the one constant is that recovery of the original PAN must not be computationally feasible given knowledge only of the token.

Single-Use and Multi-Use tokens

A single-use or one-time token is one that is generated each time a PAN is presented. That means if the same payment card is presented a second, third, or twentieth time, a unique token will be generated on each occasion. A multi-use token is preferred when the enterprise wants to track the behavior of individual payment cards. With a multi-use token, the same token is provided each time the card is used. The tokenization system accomplishes this by checking its database of PANs each time a card is used. If the PAN appears in the database, the previous token is retrieved and associated with the transaction. The choice of single-use or multiuse token depends on your business requirements. If the purpose is simply to remove PAN data from the payment application and there are few postpurchase applications, a single-use token will be all you need. If, however, you have extensive customer relationship management or loyalty program applications, or you do extensive fraud analysis (e.g., velocity checking), then multi-use tokens will meet your needs better.

vice versa. For this reason a tokenization system might intentionally avoid producing tokens that either pass a Luhn algorithm check or start with the digits 3, 4, 5, or 6. Most enterprises will want to retire and possibly re-use tokens at some point. As the number of new tokens grows and legacy transaction data are tokenized, the process of generating new tokens and checking them against the list of tokens currently in use may get increasingly involved. This could lead to unacceptable processing delays at the POS.

the Lifetime of a token

What is the lifetime of a token? It is important to know the answer because token collisions can occur not just with live PANs (as described above) but also with tokens previously constructed and still in use. Single-use tokens will exhaust the feasible token space faster than multi-use tokens, but that is not the biggest risk. There is no single answer to the optimal life of a token. One factor is how long you retain the data. With loyalty and customer relationship programs, you may track a customers activity over years, requiring the same token for all that time. On the other hand, if you use tokens primarily for exception item processing like chargebacks and refunds, you may be able to recycle them after, say, 90 or 120 days. Another factor is that issuers frequently replace cardholders cards (possibly because the original card was lost or stolen), which results in their having a new PAN. Enterprises using a third party should understand their providers tokenization processes, token lifecycle, and their alternatives (and costs). We will return to this topic when we address implementation options.

Format-preserving tokens
As their name implies, format-preserving tokens look like a PAN. They will have 16 digits, and they may even be constructed to pass a Luhn algorithm. The Luhn algorithm (also known as a Modulus-10 or Mod-10 check after the mathematical process behind the Luhn algorithm) is a formula for validating the authenticity of a PAN by calculating the last or check digit based on the previous 15 digits. Format-preserving tokens are all but required in a payment application context since so many existing systems were built to accommodate a value that looks like a payment card number. The risk with format-preserving tokens is a collision with a valid PAN. One way to avoid such collisions (which must be avoided according to the guidance from Visa referenced later in this Buyers Guide) might be to perform an anti-Luhn process to require the last digit of the token is not a valid check digit. Another approach is to restrict the range of the first digit of the token to avoid the ISO/IEC 7812 range set aside for banking (ATM), travel, and payment cards. This would mean no token would begin with a 3, 4, 5, or 6. As noted below, token collision is not exclusive to collisions with live PANs.

token Collisions
While 12 (assuming you want to preserve the last 4) or even the full 16 digits allows for a large number of tokens, that number is not infinite. If we further restrict the feasible space by preserving additional digits (e.g., the first six or a subset of them), restricting the token to passing (or not passing) a Luhn algorithm, and not colliding with a valid PAN (there goes any token starting with a 3, 4, 5 or 6), we begin to confront the very real possibility of running out of tokens. Your tokenization system needs to distinguish between a token and a genuine PAN. The reason is to keep you from spreading tokens to systems expecting a real PAN, and importantly

Tokenization and Encryption

Tokenization and encryption have a complicated relationship. Each is different, but tokenization depends on encryption to protect the token vault. Therefore, while some people may describe tokenization and encryption competing alternatives, the reality is more complex. In many cases the two technologies are actually complimentary. data for any reason or under any circumstance, the encrypted data must be deemed in PCI scope. Unfortunately, the PCI Councils list of Frequently Asked Questions has little on tokens or tokenization, providing only this definition of a token: A cryptographic token that replaces the PAN, based on a given index for an unpredictable value. 2 It is important to separate tokenization and format-preserving encryption. They are not the same thing. Format-preserving encryption creates tokens, but it uses encryption rather than a random process. Format-preserving encryption generates 16-digit strings that can be used with existing applications (just like formatpreserving tokens), but that is where the similarity ends. Format-preserving encryption is just that: encryption. Encryption scrambles your cardholder data into a different form but tokenization replaces the cardholder data. Furthermore, you dont have to manage encryption keys with tokenization. We therefore are left with the situation that both tokenization and encryption can protect cardholder data, but in most cases only tokenization removes the data from PCI scope. or keys. That means that a part of any tokenization solution is managing the encryption key for the token vault. The implication for any tokenization solution is that some entity either the enterprise itself if it manages the process or a third-party provider must manage the encryption process including protecting the encryption key. When you consider the relative importance of key management, keep in mind that while PCI has two sub-requirements dealing with encryption, it has twelve (!) subrequirements describing how to manage and protect the encryption key.

Different Solutions for Different requirements

The biggest difference between tokenization and encryption is that tokenization removes PAN data from the enterprises PCI scope. Encryption does not. What can be encrypted can be decrypted. Therefore encrypted data are still considered to be in scope for PCI. The one exception is when PCI compliant, strong encryption is managed by an outside entity, and the enterprise has no ability to decrypt the data and get back to cleartext PANs1. The PCI Councils test of whether encrypted data are out of scope is in two parts: The entity that possesses encrypted cardholder data does not have the means to decrypt it. Any technological implementation or vendor solution should be validated to ensure both physical and logical controls are in place in accordance with industry best practices, prohibiting the entity, or malicious users that may gain access to the entitys environment, from obtaining access to encryption keys. Service providers or vendors that provide encryption solutions demonstrate physical and logical controls to protect cryptographic keys in accordance with industry best practices, along with full compliance with PCI DSS. Point-to-point encryption (described below) is a strategy designed to take advantage of this situation. Since the merchant has no ability to decrypt the transaction data, those data may be considered out of the merchants PCI scope. If, however, the merchant can at any time access their original, cleartext
1 2

point-to-point encryption
Point-to-point encryption (sometimes wrongly called end-to-end encryption) is the process by which a third party encrypts cardholder data from one point (e.g., the merchant) to another point (usually the card processor or acquirer). Only the third party can decrypt the data. The effect is to remove the data between those two points from the retailer or merchants PCI scope since they have no ability to access the cleartext cardholder data. Some people describe point-to-point encryption as a substitute for or alternative to tokenization. It is actually something quite different. While it can accomplish the same goal, namely reducing the enterprises PCI scope, point-to-point encryption neither allows the merchant to access the PAN data nor provides a token as a replacement. Point-to-point encryption can be used in conjunction with and supplement a tokenization system. For example, a third party could provide an encrypting card reader to encrypt the PAN data at the point of sale, authorize the transaction, and then create a token and return it to the merchants POS system. Point-to-point encryptions role here would be to support a tokenization solution, not replace it.

the role of encryption in tokenization

While we may dismiss format-preserving encryption as a pure replacement for tokenization, encryption does play a critical role in tokenization. Specifically, encryption is used to protect the PANs stored in the token vault. We should note that PCI does not require encryption per se, but it is the only practical way to protect your original PAN data in the token vault. The token vault itself has three critical functions: storing the encrypted PANs; associating each token with the appropriate PAN; and providing controlled access when a cleartext PAN is requested by an authorized user. Modern encryption is almost impossible to break without access to the right key

PCI Security Standards Council FAQ #10359; note that all the PCI requirements for strong encryption still apply to the outside entity managing the encryption PCI Security Standards Council FAQ #5384

Tokenization Implementation Alternatives

Picking the right tokenization solution involves balancing the competing needs of controlling your payment environment, controlling costs, managing vendor risk, and speeding implementation. We consider these tradeoffs in each of the four alternative implementation strategies below together with each alternatives potential to minimize the enterprises PCI scope. risk: few enterprises consider security management to be a core strength. Lacking this expertise, creating a tokenization process from scratch may be neither practical nor even desirable. In both the software and hardware appliance cases the enterprise needs to assess both the systems functionality and their vendors strengths and weaknesses. For example: Can the application support both single- and multi-use tokens? What options are available for token creation and management? If it is a hardware solution, does it use true random numbers from a hardwarebased random number generator; or if a software solution, does it use a pseudorandom number process? What flexibility do you have on token policy? That is, can you configure your tokenization policy specify, for example, to preserve the original last four digits of the PAN? What encryption alternatives are available? PCI is pretty specific here about what constitutes strong encryption, and that includes, for example, AES (128 bits and higher), TDES (minimum double-length keys), and RSA (1024 bits and higher) What are the providers business viability and plan for continuing support? The last part is important. Control is valuable, but it should not come at the expense of an unreliable or unstable provider. You need to assess vendor business viability and your own risk if the vendors business fails. How does the solution help meet PCI compliance? There is more to successful tokenization than just generating tokens. The solution whether software or hardware based should include a guide on how to implement it in a PCI compliant manner. It is worth repeating that any internal implementation requires the enterprise to address its internal logical and physical security requirements for maintaining a PCI compliant environment.

internal implementation packaged Solution

An internally hosted solution developed by a specialized tokenization service provider can allow the enterprises to maintain a large degree of control of the tokenization process (and their customer data) while avoiding the cost and delay in designing and building a system from scratch. Such a packaged tokenization solution could be either a tokenization software package or a tokenization appliance. A software-based solution runs on the enterprises own hardware devices and network. The solution would create tokens and manage the token vault including all three functions described above. The enterprise still has a lot of work, e.g., developing its policies, configuring the tokenization process, and matching the tokenization process to the downstream user applications. The enterprise is also responsible for provisioning and hardening the servers running the tokenization system per PCI requirements. The basic tokenization process and token vault management structure, however, would be licensed from a specialized provider. Another approach is to use a tokenization appliance hosted by the enterprise. The token appliance combines the token and token vault management software suite of applications with a hardened server meeting all required physical security protections. The enterprise tunes the application (e.g., choice of tokenization options, encryption, access rules) and manages security as in the software-only case, but in this case we are approaching a turnkey tokenization solution.

internal implementation home Brewed

An enterprise can implement tokenization internally. In this case you will be responsible for generating the tokens, replacing the PAN data with the token, hosting and securing the token vault, encrypting the original PAN data in the vault, controlling the key generation and management process, restricting access and otherwise securing the token vault logically and physically, and managing the de-tokenization process. You will need to do all this while complying with every one of the PCI requirements. This approach places the tokenization process and the token vault squarely in the enterprises PCI scope. The benefits to this approach are that those systems not directly in the payment process can be removed from scope since they will now use tokens instead of PANs. Such applications would include customer relationship management and loyalty, recurring payments, repeat purchases (when using the same card and a multi-use token), and the enterprises data warehouse. The main advantage of an internal solution is control. The enterprise does not depend on any third party or service provider, and it controls how tokens are created, managed, and accessed. The disadvantage of a purely internally developed tokenization system is the cost in terms of money, staff resources, and security expertise to build and manage the tokenization process. Another disadvantage is increased

10

PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms

third-party implementation processor hosted

Internal implementation options may be most appropriate for larger or more technically adept enterprises. Small and medium businesses are much more likely to rely on a third party for tokenization services. Already many payment card processors are offering tokenization as an option for their merchants. A processor-hosted solution can be quick to implement, and the processor manages the task of generating the tokens and protecting the token vault. At an intellectual level, this makes a lot of sense. After all, the processor is in the payments business, and they should have the systems and expertise to provide such a value-added service to their merchants. Naturally, you will need to confirm this is the case. A processor-hosted solution has the added advantage of potentially reducing the enterprises PCI scope significantly. The reason is that the enterprise should be able to use tokens for all their post-payment processing including chargebacks, refunds, and even repeat and recurring payments. As described earlier, the enterprise provides the token (possibly with other, non-PAN data) back to the processor, which can add the actual PAN as needed and complete the transaction, whether it is a refund or repeat purchase. A processor-hosted solution generally does not remove the enterprises POS system from PCI scope. The POS system still processes and transmits cardholder data. But this solution can eliminate any need to store electronic cardholder data entirely. For a small or medium business, the difference between validating their compliance using Self-Assessment Questionnaire (SAQ) D with its 280+ items, and qualifying for a simplified SAQ, might justify the additional processor fees by itself.

Token collision is a potential risk. A large processor will have thousands of clients for whom they are generating tokens. They may re-use a particular token with different customers. Re-using a token is fine so long as the processor segregates each customers records securely to preserve token data integrity. Any enterprise considering a processor-based solution will want to investigate this topic with their processor(s). In addition to fees, enterprises exploring processor solutions should look at transaction speed (will there be a delay while the token is generated and substituted for the PAN?), data retention (how long are tokens and PANs retained?), and actual token generation (is it a random process?). They also should also ask themselves what they will do if or when they change processors: e.g., how will they painlessly migrate their old transaction data and tokens to the new processor; and how will they ensure the new and old tokens are compatible? These are two more topics to investigate well in advance of signing any contract.

Tokenization Functionality Some Observations

Following are some quick guidelines on tokenization that will apply whether you develop and host your own tokenization engine and token vault, or outsource tokenization to a third party. Visa notes4 that the value of any tokenization system depends on the secure implementation of four steps or components: Token Generation: Defines the process through which a token is generated Token Mapping: Defines the process for associating a token to its original PAN value Card Data Vault: Defines the central repository of cardholder data used by the token mapping process Cryptographic Key Management: Defines the process through which cryptographic keys are managed and how they are used to protect cardholder and account data.

third-party implementation token Vendor hosted

The fourth option is to have a specialized, tokenization vendor host the tokenization process. The appeal is similar to the processor-hosted solution above, but the tokens are generated and stored by a company that has tokenization as their main business. The advantages are similar to the processor-hosted solution above: quick implementation, reduced risk, and minimized PCI scope. An added plus in this case is that a token vendor solution should be processor independent. The disadvantages are also similar to the processor-hosted solution, but the enterprise will contract with a third-party (i.e., the token vendor) that may lack the financial resources, stability, and expertise of a large payment processor.

Generating tokens
Tokens should be random. The minimum requirement is that if someone knows only the token, it must not be computationally feasible to get back to the PAN. It may be possible to use hashing or cryptographic function to create a token that meets this test, however most enterprises will find that only a randomly generated formatpreserving token both meets this test and generates a token that works in their existing applications.

Visa Best Practices: Tokenization, version 1, July 14, 2010

11

token Mapping and Securing the token Vault

The token vault must be PCI compliant. Two of the three functions of the token vault are associating each token with the original PAN and returning a cleartext PAN to a properly authenticated and authorized user. (The third function is protecting the PANs with strong encryption.) Since the vault itself is in scope for PCI, it is subject to all its logical and physical access controls. PCI compliance includes the physical as well as logical security. Therefore the entire tokenization process including the token vault must be protected from

compromised insiders as well as external hackers utilizing strong access and authentication controls. This principle is illustrated in Figure 5 describing how attackers internal or external could exploit security vulnerabilities to gain access to the tokenization process or the token vault. In practice, this means the software controlling access to the vault should be resilient against attacks and provide strong authentication and authorization controls. In most cases the enterprise will want to ensure the authentication and authorization integrates with the existing identity management infrastructure already in place.

The enterprise is responsible for the token vault whether it is hosted internally or at a PCI compliant service provider. The maxim you can outsource a process, but you cannot outsource responsibility still applies. Therefore whether you outsource tokenization or implement an internal solution, you will ultimately be responsible for its security and its PCI compliance. Figure 5 also illustrates the need to spend some time determining how you will protect the token vault. It is worth repeating that these considerations apply whether you host the vault internally or use a third party. We can expect attackers to focus their efforts on breaching the token vault and its

Figure 5: Secure Vault Security Requirements

Trusted Application Requests PAN, Token

Token Vault

Existing Identity Management Systems

Malicious Application Requests

Vault protection requirements

Content Attack Prevention, Malicious Code Authentication, Authorization Identity Management Integration Secure Vault Access Encryption and Signing of Requests and Responses Thrott;ing and Rate-Shaping if De-Tokenization Requests

In-scope Out-of-scope

12

associated systems since that is where PAN data are centralized. Attackers will attempt malicious application requests or launch social engineering attacks to gain access. Therefore you need to assess how the enterprise will ensure only trusted applications and trusted users can access cleartext PAN data. One implementation option might be to have the token vault return only encrypted PANs. In this case only an approved application with the proper cryptographic key would be able to access cleartext PAN data. If the vault does return cleartext PANs, then additional throttling controls should be in place to prevent any user (or attacker) accessing an inordinately large number of PANs or even every PAN in the vault at one time. Hackers are very sophisticated (and motivated!), and allowing access to all PANs in the vault without some type of runtime control is risky.

reflecting pCi Council and Visa Guidance

In its tokenization guidance Visa noted where properly implemented, tokenization allows merchants to limit the storage of cardholder data to within the tokenization system, potentially simplifying an entitys assessment against the PCI DSS. Anyone interested in tokenization should visit Visas website (http://usa.visa.com/ merchants/risk_management/cisp.html) to download the tokenization guidance and monitor any updated documents. As noted earlier, the PCI Security Standards Council (https://www. pcisecuritystandards.org/) has issued its Information Supplement: PCI DSS Tokenization Guidelines. Any enterprise considering tokenization should review these guidelines to determine their PCI scope properly and to be sure to implement tokenization in a PCI compliant environment.

Due to misinterpretation of Visa dispute processing rules, some acquirers require their merchants to unnecessarily store full Primary Account Numbers (PANs) for exception processing to resolve disputes. To clarify, Visa does not require merchants to store PANs, but does recommend that merchants rely on their acquirer / processor to manage this information on the merchants behalf. Visa also recommends that acquirers / processors evolve their systems to provide merchants with a substitute transaction identifier to reference transaction details (in lieu of using PANs).5 Before spending a lot of time and money exploring tokenization, make sure that you have a business need. It may be that an alternative approach is preferable, including not storing PAN data in the first place.

have You Found all Your Data?

Once you have decided tokenization is for you, the first step is to find all your cardholder data. Developing a cardholder dataflow diagram that maps your card acceptance process is helpful. But this process is not guaranteed to find all the PAN data that might be stored on servers, databases, and end points throughout the enterprise. The only reliable procedure to find all your cardholder data is to use an automated sensitive number finder or data discovery tool. The reason is that data have a way of leaking into all sorts of databases and endpoints you might not know about. There are open source and commercial data discovery tools available. You should run such a tool on your entire network to locate current or legacy PAN data hiding in places your dataflow diagram might have missed.

integrating tokens
In addition to generating tokens and securing the token vault, we need to address how to implement tokens into the enterprises existing applications and databases. If the tokens cannot be integrated then there will be no PCI scope reduction. Enterprises need to plan for how the tokenization engine will support existing data center protocols and how it will interface with database systems and related post-purchase applications.

Tokenization Buyers Checklist

Following is a list of questions that any enterprise exploring tokenization should address before committing to any particular approach or vendor.

is tokenization right for You?

Perhaps the most obvious and sometimes overlooked question is: why are you tokenizing your data? In the context of PCI compliance, tokenization is valuable only if the enterprise needs the specific transaction information for business purposes. Otherwise, a point-to-point encryption approach may be more appropriate for your situation. We should be clear that retailers and other merchants do not need to retain PAN data to process chargebacks, refunds, and even recurring payments. Visa reinforced this position when it stated (the emphasis is Visas):

Cryptographic Key Management

Tokenization cannot realistically exist without encryption. We described above the critical role of strong encryption in any PCI compliant tokenization solution, primarily in protecting the PAN data stored in the token vault.

Visa Best Practices for Primary Account Number Storage and Truncation, July 14, 2010

13

We should note that PCI all but requires this automated approach when it states: at least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope.6 The guidance goes on to require the QSA to verify that no cardholder data exists outside of the currently defined cardholder data environment. The only reliable way to locate all your PAN data is with an automated and thorough search. Anyone considering tokenization should use this procedure (or the results of your QSAs assessment) to be certain you have found all the data that you need to tokenize as well as all the applications that use the data.

how will You Manage De-tokenization?

While anyone can use properly constructed tokens, you need to determine how you will restrict the people who can access the PAN data. Ideally, this will be a very small set of individuals or applications with a business need-to-know (PCI Requirement 7.2) and job function that requires access to PAN data. The implication of this requirement is that your tokenization solution has the flexibility to manage access to cleartext PAN data and the security features (including logging) to prevent unauthorized access Enforcing your internal restrictions likely will require additional layers of logical and physical security surrounding both the token vault and software that performs detokenization.

The requirement that you always be able to distinguish between a token and a real PAN makes this question particularly important. Many software application vendors are working on tokenization options or at least token compatibility. You will want to investigate token compatibility with your application vendor(s) before committing to any particular tokenization program.

how effectively will You reduce pCi Scope?

Many POS applications store cardholder data. That is the way they were built. Users can configure them to minimize the length of time the cardholder data are retained, but they usually cannot avoid storing PANs for some length of time. This business reality may in some cases limit the enterprises tokenization benefits. Take the example of a retailer whose POS application stores the PAN, and who tokenizes the data post authorization. While they replace the stored PAN in the application database with a properly constructed token, the POS application (and every system connected to it) is still in scope. In this case, the POS system will be subject to every PCI requirement because it stored the PAN even if only for a fraction of a second. This is not to underestimate the benefits of removing the business applications and even the data warehouse out of PCI scope with tokenization. Rather the point is to reinforce the need for a clear-eyed assessment of the expected benefits to your enterprise and your particular card processing systems. Part of this assessment has to include any official guidance from the PCI SSC or individual card brands.

how will You Generate tokens?

You need to know how you or your vendor will generate your tokens. While tokens can be generated using a strong cryptographic function or a one-way hashing function, in reality there is an almost infinite number of ways to generate strong tokens. Regardless of the approach you or your vendor uses (random or pseudo random numbers, sequence numbers, encryption, hashing, or some other method), you need to know what it is and be convinced that there is no way to reverse engineer the token to get back to the original PAN.

how will You address Legacy paN Data?

It is not just new transactions that will need to be tokenized. Dont forget to develop a plan to tokenize your existing PAN database(s) from the first day. This is also be a good time to review paper or even electronically scanned documents and explore how you and/or your vendor will use tokenization to remove these instances of PAN data from your PCI scope.

will tokens Break Your applications? pOS? Business process?

Not all payment applications work with tokenized data. Similarly, not all your post-purchase applications may work with tokens (or, at least with your selected token design). For example, an application (whether a POS, loyalty, marketing, or fraud application) may require a token pass the Mod-10 test or start with a 3, 4, 5 or 6. Applications were designed and built with these checks to avoid errors. Either your tokens need to be designed to reflect these requirements or you need to rewrite the applications.

where in the payment process Do You Generate tokens?

Since the purpose of tokenization is to reduce or eliminate storing PAN data, the earlier you tokenize in the payment process the greater your benefits. We illustrated this principle in Exhibits 2-4, above. The implication is that tokenizing close to the POS or concurrent with the card authorization process will minimize your PCI scope and yield the maximum benefit.

14

PCI DSS Requirements and Security Assessment Procedures, version 2.0

Outsourcing: what if Your provider ?

You can outsource the tokenization process, but you cannot outsource your responsibility. That means you need to consider the following scenarios when evaluating any third-party solution: what if my vendor goes out of business? You will want to assess the business viability of your tokenization vendor as you would any business partner. what if my vendor is acquired? will the new owners change technology, support, or pricing? what if this happens in the middle of my contract? You may want to include a provision for this contingency in your contract. in either case above, what happens to my data? You should continue to own your data. If you have concerns, you may want to consider a data escrow or similar provision so you can recover your data if the worst happens. what if my vendor suffers a security breach? will they take responsibility for their actions? will they indemnify you? when will they notify you? Include this eventuality (along with others) in your PCI risk analysis (Requirement 12.1.2) and incident response plan (12.9). Since the vendor is a PCI service provider, be sure they are PCI compliant (12.8.4), confirm the services they are providing to you were included in the scope of their PCI assessment, and have them acknowledge their responsibility for the security of your data (12.8.2). These are your responsibilities under PCI. As noted above, you can outsource a function, but you cannot outsource your responsibility.

Does the vendor have the capacity to meet my business needs? Be sure they can provide tokens fast enough so your payment process is not affected. Also investigate token life, token re-use, and safeguards in place to prevent token collisions. what if i want to change vendors? Can i get my data back? This situation arises either when you change processors (a fairly common occurrence) or you just want to change vendors. You will want to include contract terms that support a smooth transition to your new vendor. There is no substitute for a strong service level agreement (SLA).

Concluding Thoughts: Tokenization and PCI DSS

Tokenization is an exciting technology that can reduce significantly reduce an enterprises PCI scope while enhancing security. The degree to which you reduce PCI scope will depend entirely on your particular implementation. Tokenization is also a specialized technology requiring expertise in encryption, key management, and protecting both the logical and physical security of the token vault. Tokenization requires management commitment, for example restricting access to cleartext PAN data and assessing the risks of any service provider or third-party solution. While Visa and the PCI Security Standards Council have issued documents addressing tokenization for PCI compliance, at the time of writing this Buyers Guide there is not yet an agreed set of standards for what constitutes tokenization best practices. The purpose of this Buyers Guide is to offer a set of recommendations that will guide an enterprise evaluating tokenizing their payment card data to make an informed decision.

internal tokenization: what if You ?

Internal and internally hosted solutions pose their own issues: Can the enterprise manage both logical and physical security for the tokenization process and the token vault? You need to assess whether security is a core strength of the enterprise. Dont forget the critical role of strong encryption and key management processes in tokenization. Also remember to include logical and physical protections for the token vault as well as the software. will my internal application have the capacity to meet future business needs so the payment process is not slowed or negatively affected? Tokenization requires ongoing investment in hardware, software, and networking. What are your plans for scaling your tokenization system? Is it scalable? what if we suffer a data breach? The same advice applies here as to a third-party vendor: either way, ultimately it is the enterprise that will be responsible.

15

Tokenization Checklist
The table below may be helpful when reviewing internal and service provider tokenization options and when comparing vendor solutions. table 3: tokenization Checklist tOKeNizatiON taSK Or FeatUre preparatiON Have you found all your PAN data? Did you use an automated tool to be sure? Have you documented user requirements for tokens, as well as token and PAN access? Have you documented all POS and back office systems that will be impacted? Have you documented your current PCI scope? tOKeN GeNeratiON Does the solution generate tokens using hardware-based random number or similar process? If not, what process is used (e.g., sequence numbers, hashing) and will it meet the PCI non-reversibility test for tokens? Does the solution support single-use tokens? Does the solution support multiple-use tokens? What is the token lifetime? How is it determined? Is it configurable? Can the solution tokenize digitized legacy data (i.e., your current PAN databases)? What file types are compatible? That is, can the solution tokenize legacy data on paper, in MSWord or pdf documents, in your data warehouse, or in databases of electronically scanned documents? Can the solution provide tokens without introducing latency at the point of sale? tOKeN prOCeSS Where in the payment process does tokenization occur? What options are available that will minimize PCI scope? Is the solution compatible with existing POS equipment? Is the solution compatible with existing payment applications? Is the solution compatible with existing downstream or back office applications and business processes? Is the solution compatible with your detokenization business requirements (e.g., back office applications)? How much will the solution actually reduce your PCI scope? Does your QSA agree with this conclusion? Other iSSUeS Is security expertise a core strength of the solution provider (or the enterprise if solution is internal)? Is the provider financially sound? Have you updated your risk assessment (PCI Requirement 12.1.2) to reflect tokenization and potential risk if tokenization vendor or application is compromised? Have you updated security awareness training (PCI Requirement 12.6) to reflect tokenization? Will the vendor acknowledge in writing their responsibility for protecting your PAN data (PCI Requirement 12.8)? Have you updated your incident response plan (PCI Requirement 12.9) to reflect tokenization (e.g. tokenization failure; vendor failure; physical or logical breach)? prOViDer reSpONSe

16

About the Author

Walter Conway is a Payment Card Industry Qualified Security Assessor (QSA) at 403 Labs LLC. Walt is a frequent speaker at industry and security conferences, and he writes extensively on PCI compliance and data security issues. He also regularly leads PCI training sessions nationwide. Walt applies over 30-years of electronic payments and technology management experience to helping organizations including merchants, service providers, technology start-ups, and higher education institutions plan, implement, and manage PCI compliance. He spent over 10 years with Visa, and two years as president of an Internet-based payment processor. Walt writes a regular column exploring PCI and the retail industry at www. storefrontbacktalk.com, and he blogs on PCI issues at http://blog.403labs.com/.

paper Sponsorship
The Application Security and Identity Protection (ASIP) group sponsored the production of this Buyers Guide in order to facilitate broader understanding of use of tokenization technology for reducing PCI-DSS compliance scope. Intel has brought to market Intel Expressway Tokenization Broker, a solution that lowers costs and dramatically simplifies PCI DSS compliance and administration for organizations across all industry types that accept, capture, store, transmit or process credit card or debit card data. For more information on Intel Expressway Tokenization Broker visit: www.intel.com/go/identity

17

Reduce PCI Scope, Lower Costs & Protect Cardholder Data

More information
Resource Site: www.intel.com/go/identity

Americas: 878-948-2585

E-mail: asipcustomercare@intel.com

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTELS TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked reserved or undefined. Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice.Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or by visiting Intels Web site at www.intel.com. Copyright 2011 Intel Corporation. All rights reserved. Intel, the Intel logo, and Xeon are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Printed in USA Please Recycle 325985-001