Tokenization Buyers Guide

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.


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


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


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


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


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


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/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


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


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


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


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


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


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


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


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


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


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

Date post:	06-Apr-2018
Category:	Documents
Upload:	chad-roberts
View:	254 times
Download:	2 times

Tokenization Buyers Guide

Documents