tokenization buyers guide
TRANSCRIPT
-
8/3/2019 Tokenization Buyers Guide
1/18
PCI DSS Tokenization Buyers GuideHow enterprises can use tokenization to reduce risk and minimizethe cost of PCI DSS compliance
white paper
p Focus:
PCI DSS compliance Use Cases thatcan 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
auo
wl ConyPayment Card Industry
Qualified Security Assessor(QSA) at 403 Labs LLC.
absc
ThisguideisdesignedforPCIDSScomplianceofcers,PCIQualiedSecurity
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.
-
8/3/2019 Tokenization Buyers Guide
2/18
Tokenization Buyers Guide
ecuv Summy.......................................................................................................................1
t Us Cs: toknon n pymn envonmn............................3
PCI DSS ..............................................................................................................................................3
Use Case 1: Internal Tokenization ...................................................................................4Use Case 2: Service Provider Tokenization ..............................................................5
tokn Consucon ........................................................................................................................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
toknon nd encyon..................................................................................................9
Different Solutions for Different Requirements ..................................................9
The Role of Encryption in Tokenization ......................................................................9
Point-to-Point Encryption ....................................................................................................9
toknon imlmnon alnvs ...............................................................10
Internal Implementation Home Brewed .................................................................10
Internal Implementation Packaged Solution ........................................................10
Third-Party Implementation Processor Hosted ................................................11
Third-Party Implementation Token Vendor Hosted .......................................11
toknon Funconly Som Obsvons ................................................11
Generating Tokens ....................................................................................................................11
Token Mapping and Securing the Token Vault .......................................................12
Integrating Tokens ....................................................................................................................13
Cryptographic Key Management .....................................................................................13
ReectingPCICouncilandVisaGuidance..................................................................13
toknon Buys Cckls.............................................................................................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? .....................................................................14How 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
Concludng tougs: toknon nd pCi DSS ..................................................15
toknon Cckls.................................................................................................................16
abou auo.............................................................................................................................17
2
-
8/3/2019 Tokenization Buyers Guide
3/18
The Payment Card Industry Data
Security Standard (PCI DSS, or just PCI)
is a multifaceted security standardthat 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-sub-
Executive Summary
This Buyers Guide describes how
tokenization can help enterprises
achieve compliance with the PaymentCard 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
otherpieceofpersonallyidentiableinformation (PII).
Tokenization has two attractive
benets.Itcanreduceanenterprises
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
itworksspecicallyinthecontextof
protecting payment card data, and explore
implementation options. We conclude this
Buyers Guide with a list of questions that
business and IT professionals need toaddress before selecting the tokenization
solution that best meets their
enterprises needs.
The Use Case: Tokenization in the Payment Environment
requirements, the total number of
requirements is closer to 280. Therefore
any technology that can reduce theenterprises PCI scope (i.e., the number
of requirements that apply) can similarly
reduce the cost and effort of PCI
compliance.Thebenetoftokenizationis
thatitcanreducePCIscopesignicantly.
3
This paper is aimed at business and IT
professionals who are responsible for
risk management and PCI compliance, andwho are interested in approaches that can
simplify the process and reduce the cost
of maintaining PCI compliance.
Buld nd Mnn
Scu Nok
1.
2.
Install and maintain a firewall configuration to protect cardholder data
Do not use vendor-supplied defaults for system passwords and other security parameters
poc Cdold D 3.
4.
Protect stored cardholder data
Encrypt transmission of cardholder data across open, public networks
Mnn Vulnbly
Mngmn pogm
5.
6.
Use and regularly update anti-virus software or programs
Develop and maintain secure systems and applications
imlmn Song accss
Conol Msus
7.
8.
9.
Restrict access to cardholder data by business need to know
Assign a unique ID to each person with computer access
Restrict physical access to cardholder data
rgully Mono nd
ts Noks
10.
11.
Track and monitor all access to network resources and cardholder data
Regularly test security systems and processes
Mnn nd infomon
Scuy polcy
12. Maintain a policy that addresses information security for all personnel
tbl 1: pCi D Scuy Sndd - hg Lvl Ovv
-
8/3/2019 Tokenization Buyers Guide
4/18
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
scopesimpliestheeffortandreduces
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
degreeofbenet(i.e.,reducedPCIscope
and increased security) will depend on the
particulars of each enterprises own card-
processing 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
tokensthatareusedinbackofce
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 orcard processor to determine if they have
such high value tokens, and if they do
they need to determine whether their
tokenizationimplementationissufciently
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 nowhave a single, secure location that you can
monitor closely and manage securely.
Whenevaluatingthepositivebenetsof
tokenization for your enterprise, you need
to consider the particulars of your own
environment. As they say with new cars:your mileage may vary.
Us Cs 1:innl toknon
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
ofceapplicationssuchassalesanalysis,
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
transactiondataowfromthepoint-of-
sale (POS), to the payment application.
Theenterprisesbackofce,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 systemin this diagram is in scope.
Figure 1: PCI scope
POS Payment App PAN Data
Applications
PAN PAN
In-scope
4
-
8/3/2019 Tokenization Buyers Guide
5/18
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 andassociates them with the original PANs.
Figure 1isasimplieddescriptionofa
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, reducedPCI compliance expenses including the
costs of an outside assessment.
Figure 2: Reducing PCI scope with Internal Tokenization
Us Cs 2:Svc povd toknon
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 asdescribed 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
businessconsiderations(e.g.,difcultychanging service providers) and risks (e.g.,
service provider business stability).
POS Payment App
PAN
PAN
Tokens
Tokens
PAN, Token
In-scope
Out-of-scope
Tokens
Applications
Token Vault
5
-
8/3/2019 Tokenization Buyers Guide
6/18
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 paymentprocessor 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
providerrstauthorizesthetransaction
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 wouldapply here as in Use Case 1.
Figure 4: Service Provider Tokenization at the Point-of-Sale
Figure 3: Service Provider Tokenization
POS Payment App
PAN
PAN
Tokens
Tokens
PAN, Token
Third-PartyEnvironment
Token Vault
Third-PartyToken Engine
Tokens
Applications
In-scope
Out-of-scope
3rd Party
POS Payment App
PAN
Tokens
Tokens
PAN, Token
Third-PartyEnvironment
Tokens
Applications
Token Vault
Third-PartyToken Engine
In-scope
Out-of-scope
3rd Party
6
-
8/3/2019 Tokenization Buyers Guide
7/18
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 valueoutside 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
certicatesorgiftcards.Ineachcasethe
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
retainonlytherstsixand/orlastfour
digits of the PAN. PCI does not consider
a truncated PAN to be in scope. It is
important that we not confuse truncation
whichmeansdeletingallbutrstsix/
last four with masking which means
storing the full PAN, but displaying only
therstsix/lastfourdigits.
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.
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 tousing 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
Lastly we have a random token. The token
may be the same length and share manycharacteristics 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
manybackofceapplicationslikefraudprevention or loyalty programs. Both
hashed and encrypted values can contain
alphabetic and non-numeric characters,
whichmakeeitherapproachdifcultto
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
casino chip back to legal tender without
going to the casino cashier. This point
illustrates the central difference between
tokenization and encryption. Encryptionis 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.
sharing some of the digits from the
original PAN (e.g., preserving the lastfour). That means the enterprise does not
necessarilyhavetorewritebackofceor
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.
Buldng tokn
The single most important requirement
in constructing a token is that it not bereversible. 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 hardware-
based random number generator or a
iteM exaMpLe pCi SCOpe
Primary Account Number (PAN) 4123 4567 8901 2345 In PCI scope
tuncd paN (Different from masked) 4123 45XX XXXX 2345 Out of scope
hsd paN (One way; renders PAN unreadable) 2fd4e1c6 7a2d28fc Out of scope
encyd paN (More characters than the PAN and structurally different) 9Ojr73h3d &hh#&HFH#ED*HD# In PCI scope
tokn (Like PAN in length and character type, but randomly derived) 9483 7266 3928 9819 Out of scope
tbl 2: paNs, hss, encyon, nd tokns
7
-
8/3/2019 Tokenization Buyers Guide
8/18
pseudo-random number generator based
on the SHA family of hash algorithms. As
notedabove,youhavesomeexibilityin
generating tokens. You may, for example,preserve the last four digits of the original
PAN,andgeneratetherst12digits
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 ofthe token.
Fom-psvng tokns
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 checkdigit 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
rstdigitofthetokentoavoidtheISO/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.
Sngl-Us nd Mul-Us tokns
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 ispresented 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 multi-
use token depends on your business
requirements. If the purpose is simply
to remove PAN data from the payment
application and there are few post-
purchase 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.
tokn Collsons
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
isnotinnite.Ifwefurtherrestrictthe
feasible space by preserving additional
digits(e.g.,therstsixorasubsetof
them), restricting the token to passing
(or not passing) a Luhn algorithm, andnot 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
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.
t Lfm of toknWhat 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.
8
-
8/3/2019 Tokenization Buyers Guide
9/18
Tokenization and encryption have a
complicated relationship. Each is different,
but tokenization depends on encryption to
protect the token vault. Therefore, whilesome people may describe tokenization
and encryption competing alternatives,
the reality is more complex. In many
cases the two technologies are
actually complimentary.
Dffn Soluons fo Dffnrqumns
The biggest difference between
tokenization and encryption is that
tokenization removes PAN data from the
enterprises PCI scope. Encryption doesnot.
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:
Theentitythatpossessesencrypted
cardholder data does not have the means
to decrypt it. Any technological imple-
mentation 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.
Serviceprovidersorvendorsthatpro -
vide 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, cleartext1 PCI Security Standards Council FAQ #10359; note that all the PCI requirements for strong encryption still apply to the outside entity managing the encryption2 PCI Security Standards Council FAQ #5384
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
denitionofatoken:Acryptographic
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 format-
preserving 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 canprotect cardholder data, but in most cases
only tokenization removes the data from
PCI scope.
t rol of encyon ntoknon
While we may dismiss format-preserving
encryption as a pure replacement for
tokenization, encryption does play a
criticalroleintokenization.Specically,
encryption is used to protect the PANs
stored in the token vault. We should notethat 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
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 (!) sub-
requirements describing how to manage
and protect the encryption key.
pon-o-pon encyon
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 cleartextcardholder 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.
Tokenization and Encryption
9
-
8/3/2019 Tokenization Buyers Guide
10/18
Picking the right tokenization solution
involves balancing the competing needs
of controlling your payment environment,
controlling costs, managing vendor risk,
and speeding implementation. We considerthese tradeoffs in each of the four
alternative implementation strategies
below together with each alternatives
potential to minimize the enterprises
PCI scope.
innl imlmnon hom Bd
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
theenterprisesPCIscope.Thebenetsto 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 doesnot 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
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.
innl imlmnon pckgd Soluon
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 ora 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,
conguringthetokenizationprocess,
and matching the tokenization process
to the downstream user applications.
The enterprise is also responsible forprovisioning 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.
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:
Cantheapplicationsupportbothsingle-
and multi-use tokens?
Whatoptionsareavailablefortoken
creation and management? If it is a
hardware solution, does it use true
random numbers from a hardware-
based random number generator; or if a
software solution, does it use a pseudo-
random number process?
Whatflexibilitydoyouhaveontoken
policy? That is, can you configure your
tokenization policy specify, for example,
to preserve the original last four digits of
the PAN?
Whatencryptionalternativesare
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)
Whataretheprovidersbusinessviabilityand 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.
HowdoesthesolutionhelpmeetPCI
compliance? There is more to successful
tokenization than just generating tokens.
The solution whether software orhardware 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.
Tokenization Implementation Alternatives
3 PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms10
-
8/3/2019 Tokenization Buyers Guide
11/18
td-py imlmnon pocsso hosd
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,youwillneedtoconrmthisis
the case.
A processor-hosted solution has the
added advantage of potentially reducing
theenterprisesPCIscopesignicantly.
The reason is that the enterprise
should be able to use tokens for all
their post-payment processing including
chargebacks, refunds, and even repeatand 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 anyneed 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,andqualifyingforasimpliedSAQ,
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 isnesolongastheprocessorsegregates
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.
td-py imlmnon tokn Vndo hosd
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
nancialresources,stability,andexpertise
of a large payment processor.
Tokenization Functionality Some Observations
Following are some quick guidelines ontokenization 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:Denestheprocess
through which a token is generated
Token Mapping:Denestheprocess
for associating a token to its original
PAN value
Card Data Vault:Denesthecentral
repository of cardholder data used by
the token mapping process
Cryptographic Key Management:
Denestheprocessthroughwhich
cryptographic keys are managed and
how they are used to protect cardholder
and account data.
Gnng tokns
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,howevermostenterpriseswillnd
that only a randomly generated format-
preserving token both meets this test
and generates a token that works in their
existing applications.
4 Visa Best Practices: Tokenization, version 1, July 14, 2010 11
-
8/3/2019 Tokenization Buyers Guide
12/18
tokn Mng nd Scung tokn Vul
The token vault must be PCI compliant.
Two of the three functions of the token
vault are associating each token with theoriginal 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
Vul pocon rqumns
ContentAttackPrevention,MaliciousCode
Authentication,Authorization
IdentityManagementIntegration
SecureVaultAccess
EncryptionandSigningofRequestsandResponses
Thrott;ingandRate-ShapingifDe-TokenizationRequests
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 couldexploit 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 stillapplies. 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
Existing IdentityManagement Systems
PAN, Token
Token Vault
Trusted ApplicationRequests
Malicious ApplicationRequests
In-scope
Out-of-scope
12
-
8/3/2019 Tokenization Buyers Guide
13/18
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 howthe 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) accessingan 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.
ingng tokns
In addition to generating tokens and
securing the token vault, we need to
address how to implement tokens into
the enterprises existing applicationsand 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.
Cyogc Ky Mngmn
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.
rflcng pCi Councl ndVs Gudnc
In its tokenization guidance Visa
noted where properly implemented,
tokenization allows merchants to limitthe 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.
Tokenization BuyersChecklist
Following is a list of questions that
any enterprise exploring tokenization
should address before committing to any
particular approach or vendor.
is toknon rg fo 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
onlyiftheenterpriseneedsthespecic
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):
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 dos no require merchants
to store PANs, but dos commnd
thatmerchantsrelyontheiracquirer/
processor to manage this information
on the merchants behalf. Visa also
recommendsthatacquirers/processors
evolve their systems to provide merchants
withasubstitutetransactionidentier
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
notstoringPANdataintherstplace.
hv You Found all You D?
Once you have decided tokenization is
foryou,therststepistondallyour
cardholder data. Developing a cardholder
dataowdiagramthatmapsyourcard
acceptance process is helpful. But this
processisnotguaranteedtondallthe
PAN data that might be stored on servers,databases, and end points throughout
the enterprise.
Theonlyreliableproceduretondallyour
cardholder data is to use an automated
sensitivenumbernderordatadiscovery
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 tolocate current or legacy PAN data hiding in
placesyourdataowdiagrammight
have missed.
5 Visa Best Practices for Primar y Account Number Storage and Truncation, July 14, 2010 13
-
8/3/2019 Tokenization Buyers Guide
14/18
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
conrmtheaccuracyoftheirPCIDSSscope by identifying all locations and
owsofcardholderdataandensuring
they are included in the PCI DSS scope.6
The guidance goes on to require the
QSA to verify that no cardholder data
existsoutsideofthecurrentlydened
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.
ho wll You Gn tokns?
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
analmostinnitenumberofwaysto
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.
w n pymn pocss DoYou Gn tokns?
Since the purpose of tokenization is to
reduce or eliminate storing PAN data,
the earlier you tokenize in the payment
processthegreateryourbenets.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
PCIscopeandyieldthemaximumbenet.
ho wll You MngD-toknon?
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
tokenizationsolutionhastheexibilityto
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.
ho wll You addss LgcypaN D?
It is not just new transactions that will
need to be tokenized. Dont forget to
develop a plan to tokenize your existing
PANdatabase(s)fromtherstday.This
is also be a good time to review paper or
even electronically scanned documents
andexplorehowyouand/oryourvendor
will use tokenization to remove these
instances of PAN data from your
PCI scope.
wll tokns BkYou alcons? pOS?Busnss pocss?
Not all payment applications work with
tokenized data. Similarly, not all your
post-purchase applications may work with
tokens (or, at least with your selectedtoken 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
reecttheserequirementsoryouneedto
rewrite the applications.
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 ontokenization 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.
ho effcvly wll Yourduc pCi Sco?
Many POS applications store cardholder
data. That is the way they were built.
Userscancongurethemtominimizethe
length of time the cardholder data areretained, but they usually cannot avoid
storing PANs for some length of time.
This business reality may in some cases
limit the enterprises tokenization
benets.Taketheexampleofaretailer
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 thiscase, the POS system will be subject to
every PCI requirement because it
stored the PAN even if only for a
fraction of a second.
Thisisnottounderestimatethebenets
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
assessmentoftheexpectedbenets
to your enterprise and your particular
card processing systems. Part of this
assessmenthastoincludeanyofcial
guidance from the PCI SSC or individual
card brands.
6 PCI DSS Requirements and Security Assessment Procedures, version 2.014
-
8/3/2019 Tokenization Buyers Guide
15/18
Ousoucng:w if You povd ?
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:
w f my vndo gos ou of
busnss?
You will want to assess the business
viability of your tokenization vendor as
you would any business partner.
w f my vndo s cqud? wll
n ons cng cnology,
suo, o cng? w f s
ns n mddl of my conc?
You may want to include a provision for
this contingency in your contract.
in cs bov, ns o
my d?
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.
w f my vndo suffs scuybc? wll y k sonsbly
fo cons? wll y ndmnfy
you? wn ll y nofy 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.
Concluding Thoughts:Tokenization and
PCI DSSTokenization is an exciting technology
thatcanreducesignicantlyreducean
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. Tokenizationrequires 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 recommendationsthat will guide an enterprise evaluating
tokenizing their payment card data to
make an informed decision.
Dos vndo v ccy o
m my busnss nds?
Be sure they can provide tokens fast
enough so your payment process is notaffected. Also investigate token life,
token re-use, and safeguards in place to
prevent token collisions.
w f i n o cng vndos?
Cn i g my d bck?
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).
innl toknon:w if You ?
Internal and internally hosted solutions
pose their own issues:
Cn ns mng bologcl nd yscl scuy fo
oknon ocss nd oknvul?
You need to assess whether securityis 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.
wll my nnl lcon v ccy o m fuu busnss nds
so ymn ocss s no slod
o ngvly ffcd?
Tokenization requires ongoing investmentin hardware, software, and networking.
What are your plans for scaling your
tokenization system? Is it scalable?
w f suff d bc?
The same advice applies here as to a
third-party vendor: either way, ultimately
it is the enterprise that will be responsible.
15
-
8/3/2019 Tokenization Buyers Guide
16/18
tOKeNizatiON taSK Or FeatUre prOViDer reSpONSe
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 prOCeSSWhere 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 iSSUeSIs 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)?
tbl 3: toknon Cckls
Tokenization Checklist
The table below may be helpful when reviewing internal and service provider tokenization options and when comparing
vendor solutions.
16
-
8/3/2019 Tokenization Buyers Guide
17/18
About the Author
Walter Conway is a Payment Card Industry
QualiedSecurityAssessor(QSA)at403
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 twoyears 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/ .
p Sonsos
The Application Security and Identity
Protection (ASIP) group sponsored the
production of this Buyers Guide in order
to facilitate broader understandingof use of tokenization technology for
reducing PCI-DSS compliance scope. Intel
has brought to market Intel Expressway
Tokenization Broker, a solution that
lowerscostsanddramaticallysimplies
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
-
8/3/2019 Tokenization Buyers Guide
18/18
Reduce PCI Scope, Lower Costs & Protect Cardholder Data
Mo infomonResource Site: www.intel.com/go/identity Americas: 878-948-2585
E-mail: [email protected]
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IM PLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY
THIS DOCUMENT. EXCEPT AS PROVIDED IN INTELS TERMS AND CONDITIONS OF SA LE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABI LITY WHATSOEVER, AND INTEL DISCLAIM S ANY EXPRESS OR IMPLIED WARR ANTY,
RELATING TO SALE AND/OR USE OF INTEL PRODUCTS I NCLUDING LIABILITY OR WARR ANTIES 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 A RE 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.
Intelmaymakechangestospecicationsandproductdescriptionsatanytime,withoutnotice.Designersmustnotrelyontheabsenceorcharacteristicsofanyfeaturesorinstructionsmarkedreservedorundened.Intelreservestheseforfuturedenitionandshallhavenoresponsibilitywhatsoeverforconictsorincompatibilitiesarisingfromfuturechangestothem.Theinformationhereissubjecttochangewithoutnotice.Donotnalizeadesignwiththisinformation.
Theproductsdescribedinthisdocumentmaycontaindesigndefectsorerrorsknownaserratawhichmaycausetheproducttodeviatefrompublishedspecications.Currentcharacterizederrataareavailableonrequest.ContactyourlocalIntelsalesofceoryourdistributortoobtainthelatestspecicationsandbeforeplacingyourproductorder.Copiesofdocumentswhichhaveanordernumberandarereferencedinthisdocument,orotherIntelliterature,maybeobtainedbycalling1-800-548-4725,orbyvisitingIntelsWebsiteatwww.intel.com.
Copyright2011IntelCorporation.Allrightsreserved.Intel,theIntellogo,andXeonaretrademarksofIntelCorporationintheU.S.andothercountries.
*Othernamesandbrandsmaybeclaimedasthepropertyofothers.
PrintedinUSA PleaseRecycle 325985-001