A Cryptographic Study of Tokenization Systems

Sandra D´ıaz-Santiago

∗

, Lil Maria Rodriguez-Henriquez and Debrup Chakraborty

Department of Computer Science, CINVESTAV-IPN,

Av. IPN 2508, San Pedro Zacatenco, Mexico City 07360, Mexico

Keywords:

Payment Card Industry Standard, Tokenization, Symmetric Encryption, Format Preserving Encryption,

Provable Security.

Abstract:

Payments through cards have become very popular in today’s world. All businesses now have options

to receive payments through this instrument, moreover most organizations store card information of its

customers in some way to enable easy payments in future. Credit card data is a very sensitive information and

its theft is a serious threat to any company. Any organization that stores such data needs to achieve payment

card industry (PCI) compliance, which is an intricate process. Recently a new paradigm called “tokenization”

has been proposed to solve the problem of storage of payment card information. In this paradigm instead

of the real credit card data a token is stored. To our knowledge, a formal cryptographic study of this new

paradigm has not yet been done. In this paper we formally deﬁne the syntax of a tokenization system, and

several notions of security for such systems. Finally, we provide some constructions of tokenizers and analyze

their security in the light of our deﬁnitions.

1 INTRODUCTION

In our digital age, credit cards have become a usual

payment instrument. With increasing popularity of

business through internet, every business requires to

maintain credit card information of its clients in some

form. Credit card data theft causes a serious ﬁnancial

loss and a critical damage to the “brand image” of the

company in question.

The Payment Card Industry Security Standard

Council (PCI SSC) is an organization responsible for

the development and deployment of various best prac-

tices in ensuring security of credit card data. In par-

ticular PCI SSC has developed a standard called the

PCI Data Security Standard (PCI DSS) (PCI Security

Standards Council, 2008). This standard dictates that

organizations, which process card payments, must

protect cardholder data when they store, transmit and

process them. Actually it proposes to use “strong

cryptography” as a possible solution.

Traditionally credit card numbers have been used

as a primary identiﬁer in many business processes

and are scattered across the environment of merchant

sites. But, in most systems where credit card numbers

∗

Sandra D´ıaz-Santiago is on academic leave from Escuela Su-

perior de C´omputo (ESCOM-IPN), Av. Juan de Dios B´atiz, Col.

Lindavista, M´exico D.F. 07738, M´exico

are stored, the data itself is not required, it can be re-

placed by some other information which would “look

like” credit card numbers. This observation has lead

to a paradigm called “tokenization”, where credit card

numbers are replaced by tokens. Tokens are numbers

which represent credit cards but are unrelated to the

real credit card numbers.

There have been numerous industry white papers

and similar documents which discuss about the pos-

sible solutions to the tokenization problem (Securo-

sis White Paper, 2011; Voltage Security White pa-

per, 2012; RSA White paper, 2012). PCI SSC has

also formulated its guidelines regarding tokenization

(PCI Security Standards Council, 2011). However to

our knowledge a formal cryptographic analysis of the

problem has not been done.

SMALL DOMAIN ENCRYPTION. One obvious so-

lution for securing credit card numbers in a merchant

site is to encrypt them. But a strict requirement for ap-

plying encryption is that the cipher should look like a

credit card number. This necessity opened up an inter-

esting problem. A typical credit card number consists

of sixteen (or less) decimal digits, if this is treated as a

binary string, is about 53 bits long. Thus, direct appli-

cation of a block cipher (say AES) to encrypt would

result in a considerable length expansion, and it would

not be possible to encode the cipher into sixteen dec-

imal digits.

393

Díaz-Santiago S., Maria Rodriguez-Henriquez L. and Chakraborty D..

A Cryptographic Study of Tokenization Systems.

DOI: 10.5220/0005062803930398

In Proceedings of the 11th International Conference on Security and Cryptography (SECRYPT-2014), pages 393-398

ISBN: 978-989-758-045-1

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

The general problem was named by Voltage Se-

curity as format preserving encryption (FPE), which

refers to an encryption algorithm which preserves the

format of the message. There have been some in-

teresting solutions to this problem, but none of them

can be considered to be efﬁcient (Bellare et al., 2009;

Brier et al., 2010; Hoang et al., 2012; Morris et al.,

2009; Stefanov and Shi, 2012). A credit card num-

ber encrypted by an FPE scheme can act as a token.

Such a solution is also provided by Voltage Security

(Voltage Security White paper, 2012). But to the best

of our knowledge, this is the only solution to the tok-

enization problem with known cryptographic guaran-

tees.

OUR CONTRIBUTION. We study the paradigm

of tokenization from a cryptographic viewpoint. We

point out the basic needs for a tokenization system,

and deﬁne a syntax for the problem. Further, we de-

velop the corresponding security model, in line with

concrete provable security. We propose three dif-

ferent security notions IND-TKR, IND-TKR-CV, and

IND-TKR-KEY, which depend on three different threat

models. Finally, we propose three generic construc-

tions of tokenization systems, namely TKR1, TKR2

and TKR2a. We also prove security of our construc-

tions in the proposed security models. For lack of

space, in this version we provide only the basic ideas.

A more comprehensive version of this work can be

found in the IACR eprint archive.

2 TOKENIZATION SYSTEMS:

REQUIREMENTS AND PCI DDS

GUIDELINES

The basic architecture of a tokenization system is de-

scribed in Fig.1. In the diagram we show three sepa-

rate environments: the merchant site, the tokenization

system and the card issuer. The basic data objects

of interest are the primary account number (PAN),

which is basically the credit card number and the to-

ken which represents the PAN. A customer commu-

nicates with the merchant environment through the

“point of sale”, where the customer provides its PAN.

The merchant sends the PAN to the tokenizer and gets

back the corresponding token. The merchant may

store the token in its environment. At the request

of the merchant the tokenizer can detokenize a token

and send the corresponding PAN to the card issuer for

payments.

We show the tokenization system to be separated

from the merchant environment, but it is also possible

that the merchant itself implements its tokenization

Token

Issuer

PAN

Tokenization System

PAN

Merchant Environment

Token

Encrypted Channel

Card

Vault

Application

Server

Token

Generation

Point of

Sale

Figure 1: Architecture of the tokenization system.

solution, and in that case, the tokenization system is a

part of the merchant environment.

As described in (PCI Security Standards Council,

2011), a tokenization system has the following com-

ponents:

1. A Method for Token Generation: A process to

create a token corresponding to a primary account

number (PAN).

2. A Token Mapping Procedure: It refers to the

method used to associate a token with a PAN.

Such a method would allow the system to recover

a PAN, given a token.

3. Card Vault: It is a repository which usually will

store pairs of PANs and tokens and maybe some

other information required for the token mapping.

Since it may contain PANs, it must be specially

protected according the PCI DSS requirements.

4. Cryptographic Key Management: This module

is a set of mechanisms to create, use, manage,

store and protect keys used for the protection of

PAN data and also the information involved in to-

ken generation.

Here we state two basic requirements for tokens

and tokenization systems. We assume that tokeniza-

tion is provided as a service, thus multiple merchants

utilize the same system for their tokenization needs.

1. Format Preserving: The token should have the

same format as that of the PANs, so that the stored

PANs can be easily replaced by the tokens in the

merchant environment.

2. Uniqueness: The token generation method

should be deterministic. Thus the tokens for a

speciﬁc PAN should be unique, i.e., if the same

PAN is tokenized twice by the same merchant

then the same token should be obtained. More-

over, in a speciﬁc merchant environment two dif-

ferent PANs should be represented by different to-

kens.

In what follows we will adopt the following notations.

For a ﬁnite set S, x

← S will denote x to be an element

chosen uniformly at random from S . We consider an

adversary as a probabilistic algorithm that outputs a

SECRYPT2014-InternationalConferenceonSecurityandCryptography

394

Experiment Exp-IND-TKR

1. The challenger selects K

← K

2. Q ←

3. for each query (x, d) ∈ X × D of A ,

4. the challenger computes

t ← TKR

(1)

(x, d),

and returns t to A.

5. Q ← Q∪ {(x, d)}

6. until A stops querying

7. A selects (x

, d

), (x

, d

) ∈ (X × D) \ Q

and sends them to the challenger

8. The challenger selects a bit b

← {0, 1}

and returns t ← TKR

(1)

, d

) to A.

9. The adversary A outputs a bit b

′

10.If b = b

′

output 1 else output 0.

Experiment Exp-IND-TKR-CV

1. The challenger selects K

← K

2. Q ←

3. for each query (x, d) ∈ X × D of A,

4. the challenger computes

(t, c) ← TKR

(x, d),

and returns (t, c) to A.

5. Q ← Q∪{(x, d)}

6. until A stops querying

7. A selects (x

, d

), (x

, d

) ∈ (X × D) \ Q

and sends them to the challenger

8. The challenger selects a bit b

← {0, 1}

and returns (t, c) ← TKR

, d

) to A.

9. The adversary A outputs a bit b

′

10.If b = b

′

output 1 else output 0.

Experiment Exp-IND-TKR-KEY

1. The challenger selects K

← K

2. Q ←

3. for each query (x, d) ∈ X × D of A,

4. the challenger computes

t ← TKR

(1)

(x, d),

and returns t to A.

5. Q ← Q∪ {(x, d)}

6. until A stops querying

7. A selects (x

, d

), (x

, d

) ∈ (X × D) \ Q

and sends them to the challenger

8. The challenger selects a bit b

← {0, 1}

and returns t ← TKR

(1)

, d

) and K to A.

9. The adversary A outputs a bit b

′

10.If b = b

′

output 1 else output 0.

Figure 2: Experiments used in the security deﬁnitions: IND-TKR, IND-TKR-CV and IND-TKR-KEY.

bit b. A

⇒ b, will denote the fact that an adversary

A has access to an oracle O and outputs b.

If E : K × D × X → X be a tweakable permuta-

tion (Haleviand Rogaway, 2004) with message/cipher

space X and tweak space D, we deﬁne the

prp advan-

tage of an adversary A as

Adv

fprp

(A) =



Pr[K

← K : A

(·,·)

⇒ 1]−

Pr[π

← Perm

(X ) : A

π(·,·)

⇒ 1]



where Perm

(X ), is the set of all tweak indexed

length preserving permutations on X .

Let E : K × D × X → C be a deterministic en-

cryption scheme with key space K , tweak space D,

message space X and cipher space C. For all K ∈

K , E

(·, ·) must be an injection from D × X → C.

We deﬁne the det-cpa advantage of any adversary A,

which does not repeat any query as

Adv

det-cpa

(A) =



Pr[K

← K : A

(·,·)

⇒ 1]−

Pr[A

$(·,·)

⇒ 1]



where $(., .) is an oracle, which on input (d, x) ∈ D ×

X returns a random string of the size of the cipher-text

of x.

3 A GENERIC SYNTAX

A tokenization system has the following components:

1. X , a ﬁnite set of primary account numbers or

PAN’s. X contains strings from a suitable alpha-

bet with a speciﬁc format.

2. T , a ﬁnite set of tokens. T also contains strings

from a suitable alphabet with a speciﬁc format. It

may be the case that T = X .

3. D, a ﬁnite set of associated data. The associated

data can be any data related to the business pro-

cess.

4. CV, the card vault. The card vault is a repository

where PAN’s and tokens are stored. In our syn-

tax we shall use the CV to represent a state of the

tokenization system. Whenever a new PAN is to-

kenized, possibly both the PAN and the generated

token are stored in the CV, along with some addi-

tional data. Disregarding the structure of the CV,

we consider that “basic” elements of CV comes

from a set C.

5. K , a key generation algorithm. A tokenization

system may require multiple keys, all these keys

are generated through the key generation algo-

rithm.

6. TKR, the tokenizer. It generates tokens from the

PANs. It receives as input: the CV as a state, a

key K generated by K , some associated data d

which comes from a set D, and a PAN x ∈ X .

An invocation of TKR outputs a token and also

produces an element from C used to update the

CV. We use the square brackets to denote this in-

teraction. We formally see TKR as a function

TKR[CV] : K × X × D → T × C. For conve-

nience, we shall implicitly assume the interaction

of TKR with CV, and we will use TKR

(1)

(x, d)

and TKR

(2)

(x, d) to denote the two outputs (in T

and C, respectively) of TKR.

7. DTKR, the detokenizer which inverts a token to

a PAN. We denote a detokenizer as a function

DTKR[CV] : K × T × D → X ∪ {⊥}. For detok-

enization also, we shall implicitly assume its in-

teraction with CV and for K ∈ K , d ∈ D and

t ∈ T , we shall write DTKR

(t, d) instead of

ACryptographicStudyofTokenizationSystems

395

DTKR[CV](K, t, d).

A tokenization procedure TKR

should satisfy the

following:

• For every x ∈ X , d ∈ D and K ∈ K ,

DTKR

(TKR

(1)

(x, d), d) = x.

• For every d ∈ D, and x, x

′

∈ X , such that x 6= x

′

TKR

(1)

(x, d) 6= TKR

(1)

′

, d).

The second criteria focuses on a weak form of unique-

ness. We want that two different PANs with the same

associated data should produce different tokens. This

makes sense if we consider the associated data to be a

merchant identiﬁer. We do not want that a single mer-

chant obtains the same token for two different PANs,

but we do not care if two different merchants obtain

the same token for two different PANs.

4 SECURITY NOTIONS

We deﬁne three different security notions, which con-

sider three different attack scenarios:

1. IND-TKR: Tokens are only public. This represents

the most realistic scenario where an adversary has

access to the tokens only, and the card vault data

remains in-accessible.

2. IND-TKR-CV : The tokens and the contents of the

card vault are public. This represents an extreme

scenario where the adversary gets access to the

card vault data also.

3. IND-TKR-KEY : This represents another extreme

scenario where the tokens and the keys are public.

We formally deﬁne the above three security no-

tions based on the notion of indistinguishability, as is

usually done for encryption schemes. Three experi-

ments corresponding to the three attack scenarios dis-

cussed above are described in Figure 2. Each exper-

iment represents an interaction between a challenger

and an adversary A. The challenger can be seen as the

tokenization system, which in the beginning selects a

random key from the key space and instantiates the

tokenizer with the selected key. Then (in lines 3 to

6 of the experiments), the challenger responds to the

queries of the adversary A. The adversary A in each

case queries with (x, d) ∈ X × D, i.e., it asks for the

outputs of the tokenizer for pairs of PAN and associ-

ated data of its choice. Finally, A submits two pairs

of PANs and associated data (different from the ones

already queried) to the challenger. The challenger se-

lects one of the pairs uniformly at random and pro-

vides A with the tokenizer output for the selected pair.

The task of A is to tell which pair was selected by the

TKR1

(x, d)

1. t ← FP

(d, x);

2. return (t, NULL)

DTKR1

(x, d)

1. x ← FP

−1

(d, x);

2. return x

Figure 3: The TKR1 tokenization scheme using a format

preserving encryption scheme FP.

challenger. If A can correctly guess the selection of

the challenger then the experiment outputs a 1 oth-

erwise it outputs a 0. This setting is very similar to

the way in which security of encryption schemes are

deﬁned for a chosen plaintext adversary.

The three experiments differ in what the adversary

gets to see. In experiment Exp-IND-TKR

, A, in re-

sponse to its queries gets only the tokens and in Exp-

IND-TKR-CV

it gets both the tokens and the data

that is stored in the card vault. In Exp-IND-TKR-

KEY

, A gets the tokens corresponding to its queries,

and the challenger reveals the key to A after the query

phase.

Deﬁnition 1. Let TKR[CV] : K × X × D → T × C

be a tokenizer. Then the advantage of an adversary A

in the sense of IND-TKR, IND-TKR-CV and IND-TKR-

KEY are deﬁned as

Adv

ind-tkr

TKR

(A) =



Pr[Exp-IND-TKR

⇒ 1] −



Adv

ind-tkr-cv

TKR

(A) =



Pr[Exp-IND-TKR-CV

⇒ 1] −



Adv

ind-tkr-key

TKR

(A) =



Pr[Exp-IND-TKR-KEY

⇒ 1] −



In the following two sections we discuss two class

of constructions for tokenizers. The ﬁrst construction

TKR1, is the trivial way to do tokenization using FPE.

In the constructions TKR2 and a variant TKR2a, pre-

sented in Section 6, our main aim is to by-pass the

use of FPE schemes and use standard cryptographic

schemes to achieve both security and the format re-

quirements for arbitrarily formatted PANs/tokens.

5 CONSTRUCTION TKR1:

TOKENIZATION USING FPE

The construction TKR1 is described in Figure 3.

TKR1 uses an FPE scheme FP : K × D × X → T in

an obvious way to generate tokens. As FP is a permu-

tation on X , hence we assume that T = X .

For security we assume that FP

() is a tweakable

pseudorandom permutation with a tweak space D and

message space T . Note, that this scheme does not uti-

lize a card vault and thus is stateless. The scheme is

SECRYPT2014-InternationalConferenceonSecurityandCryptography

396

TKR2

(x, d)

1. S

← SrchCV(2, x);

2. S

← SrchCV(3, d);

3. if S

∩ S

4. t ← RN

[k]();

5. if t ∈ S

(1)

go to 4;

6. c ← (t, x, d);

7. InsertCV(c);

8. else let tup ∈ S

9. t ← tup

(1)

10. c ← (t, x, d)

11. end if

12.return (t, c)

DTKR2

(t, d)

1. S

← SrchCV(1, t);

2. S

← SrchCV(3, d);

3. if S

∩ S

4. return ⊥ ;

5. else let tup ∈ S

6. x ← tup

(2)

;

7. end if

8. return x

Figure 4: The TKR2 tokenization scheme using a random

number generator RN

().

secure both in terms of IND-TKR and IND-TKR-CV.

We formally state the security in the following theo-

rem.

Theorem 1. 1. Let Ψ = TKR1 be deﬁned as in ﬁg-

ure 3, and A be an adversary attacking Ψ in the

IND-TKR sense. Then there exists a

prp adversary

B such that

Adv

ind-tkr

(A) ≤ Adv

fprp

(B),

where B uses almost the same resources as of A.

2. Let Ψ = TKR1 be deﬁned as in ﬁgure 3, and A

be an adversary attacking Ψ in the IND-TKR-CV

sense. Then there exists a

prp adversary B (which

uses almost the same resources as of A) such that

Adv

ind-tkr-cv

(A) ≤ Adv

fprp

(B).

The ﬁrst claim of the Theorem is an easy reduc-

tion where we design a

prp adversary B which runs A

and ﬁnally relate the advantages of the adversaries A

and B. The second claim directly follows from the

ﬁrst, as in the construction TKR1, there is no card

vault, thus an IND-TKR-CV adversary for TKR1 does

not have any additional information compared to an

IND-TKR adversary. The proofs can be found in the

full version.

6 CONSTRUCTION TKR2:

TOKENIZATION WITHOUT

USING FPE

Here we propose a class of constructions which

avoids the use of format preserving encryption. In-

stead of a permutation on T as we did for the previous

construction, we assume a primitive RN

(), which

when invoked (ideally) outputs a uniform random el-

ement in T . This primitive can be keyed, we will

TKR2a

(x, d)

1. z ← E

(d, 0kx);

2. S

← SrchCV(2, z);

3. if S

4. let tup ∈ S;

5. t

′

← tup

(1)

;

6. t

aux

← E

−1

(d, t

′

);

7. Parse t

aux

as 1kt;

8. else do

9. t ← RN

]();

10. t

′

← E

(d, 1kt);

11. while SrchCV(1, t

′

) 6=

12. c ← (t

′

, z);

13. InsertCV(c);

14. return (t, c)

DTKR2a

(t, d)

1. t

′

← E

(d, 1kt);

2. S ← SrchCV(1, t

′

);

3. if S =

4. return ⊥;

5. else let tup ∈ S

6. z ← tup

(2)

;

7. x

aux

← E

−1

(d, z);

8. Parse x

aux

as 0kx;

9. end if

10.return x

Figure 5: The TKR2a tokenization scheme.

denote this by RN

[k](), where k is a uniform ran-

dom element of a pre-deﬁned ﬁnite key space K . We

deﬁne the rnd advantage of an adversary A attacking

() as

Adv

rnd

(A) =



Pr[k

← K : A

[k]()

⇒ 1] −

Pr[A

()

⇒ 1]



. (1)

Where $

() is an oracle which returns uniform ran-

dom strings from T . The task of a rnd adversary A

is to distinguish between RN

[k]() and its ideal coun-

terpart when oracle access to these schemes are given

to A.

We describe a generic scheme for tokenization in

Figure 4, which we call as TKR2 that uses RN

().

We consider that the card-vault CV is a collection of

tuples with 3 components (x

, x

), where x

, x

are the token, the PAN and associated data respec-

tively. For a tuple tup = (x

, x

), we would use

tup

(i)

to denote x

. Given a card-vault CV we also

assume procedures to search for tuples in the CV.

SrchCV(i, x) returns those tuples tup in CV such that

tup

(i)

= x. If S be a set of tuples, then by S

(i)

we will

denote the set of the i-th components of the tuples in

S. As it is evident from the description in Figure 4, the

detokenization operation is made possible through the

data stored in the card vault, and the detokenization is

just a search procedure. Also, the determinism is as-

sured by search.

It is easy to see that TKR2 is not secure in the

IND-TKR-CV sense, as in the card vault the PANs are

stored in clear. To achieve security in terms of IND-

TKR-CV, any CPA secure encryption can be used to

encrypt the PANs stored in the card vault. We modify

TKR2 to TKR2a to achieve this.

Modifying TKR2 to TKR2a: For this modiﬁcation,

we consider that the CV is a collection of tuples with

ACryptographicStudyofTokenizationSystems

397

two components (x

, x

), where x

is the encrypted to-

ken and x

is the encrypted PAN. We additionally use

a deterministic CPA secure encryption (supportingas-

sociated data) scheme E : K × D × X → C, with key

space K , tweak (associated data) space D and mes-

sage space X . Note that it is not required that C = X ,

as the ciphertexts would only be stored in the card

vault. The tokenization scheme TKR2a described in

Figure 5 uses the objects described above.

Security of TKR2 and TKR2a. The following two

theorems specify the security of TKR2 and TKR2a.

Theorem 2. Let Ψ ∈ {TKR2, TKR2a} and A be an

adversary attacking Ψ in the IND-TKR sense. Then

there exists a RND adversary B (which uses almost

the same resources as of A) such that

Adv

ind-tkr

(A) ≤ Adv

rnd

(B)

Theorem 3. Let Ψ = TKR2a and A be an adversary

attacking Ψ in the IND-TKR-CV sense, who asks at

most q queries. Then there exist adversaries B and

′

(which use almost the same resources as of A) such

that

Adv

ind-tkr-cv

(A) ≤ Adv

rnd

(B)

+Adv

det-cpa

′

) +

(2q+ 1)

where s is the size of the smallest element in C.

Finally it is important to note that TKR2 and

TKR2a achieve security in the IND-TKR-KEY sense,

when we instantiate RN

() with a true random num-

ber generator (TRNG). We can easily see this, consid-

ering that a TRNG is keyless, thus we have the prop-

erty of independencebetween the tokens and the keys.

7 CONCLUSION

We studied the problem of tokenization from a cryp-

tographic viewpoint. We proposed a syntax for the

problem and also formulated three different security

deﬁnitions. These newdeﬁnitions may help in analyz-

ing existing tokenization systems. We also proposed

three constructions for tokenization: TKR1, TKR2 and

a TKR2a. The last two constructions are particularly

interesting, as they demonstrate that tokenization can

be achieved without the use of format preserving en-

cryption. Also we analyzed all the constructions in

light of our security deﬁnitions.

More details about instantiations of the schemes

along with their security, efﬁciency properties and ex-

perimental results can be found in the extended ver-

sion.

ACKNOWLEDGEMENTS

The authors acknowledge the support from CONA-

CYT project 166763.

REFERENCES

Bellare, M., Ristenpart, T., Rogaway, P., and Stegers, T.

(2009). Format-preserving encryption. In Jr., M. J. J.,

Rijmen, V., and Safavi-Naini, R., editors, Selected Ar-

eas in Cryptography, volume 5867 of Lecture Notes

in Computer Science, pages 295–312. Springer.

Brier, E., Peyrin, T., and Stern, J. (2010). BPS:

a format-preserving encryption proposal.

NIST submission. Available at http://

csrc.nist.gov/groups/ST/toolkit/BCM/documents/

proposedmodes/bps/bps-spec.pdf.

Halevi, S. and Rogaway, P. (2004). A parallelizable en-

ciphering mode. In Okamoto, T., editor, CT-RSA,

volume 2964 of Lecture Notes in Computer Science,

pages 292–304. Springer.

Hoang, V. T., Morris, B., and Rogaway, P. (2012). An en-

ciphering scheme based on a card shufﬂe. In Safavi-

Naini, R. and Canetti, R., editors, CRYPTO, volume

7417 of Lecture Notes in Computer Science, pages 1–

13. Springer.

Morris, B., Rogaway, P., and Stegers, T. (2009). How to en-

cipher messages on a small domain. In Halevi, S., ed-

itor, CRYPTO, volume 5677 of Lecture Notes in Com-

puter Science, pages 286–302. Springer.

PCI Security Standards Council (2008). Payment card in-

dustry data security standard version 1.2. Available at

https://www.pcisecuritystandards.org/

security

standards/pci dss.shtml.

PCI Security Standards Council (2011). Information sup-

plement: PCI DSS tokenization guidelines. Available

at https://www.pcisecuritystandards.org/documents/

Tokenization

Guidelines Info Supplement.pdf.

RSA White paper (2012). Tokenization:

What next after PCI. Available at http://

www.emc.com/collateral/white-papers/h11918-wp-

tokenization-rsa-dpm.pdf.

Securosis White Paper (2011). Tokenization guidance:

How to reduce pci compliance costs. Available at

http://gateway.elavon.com/documents/Tokenization

Guidelines White Paper.pdf.

Stefanov, E. and Shi, E. (2012). Fastprp: Fast pseudo-

random permutations for small domains. IACR Cryp-

tology ePrint Archive, 2012:254.

Voltage Security White paper (2012). Payment

security solution - processor edition. Avail-

able at http://www.voltage.com/wp-content/ up-

loads/Voltage

White Paper SecureData PaymentsPro

cessorEdition.pdf.

SECRYPT2014-InternationalConferenceonSecurityandCryptography

398