![](bg4.png)
8. Reusability. The space of all tokens’ open digits
being smaller than the expected number of token
requests, the same open digits should be able to
be issued several times.
9. Auditability. This depends on the legislation the
TSP is submitted to. It varies from one country to
another. We consider that the time and data for all
tokenizations and all detokenizations (succeeded
or failed) should be stored for 5 years.
10. Security. Any storage of data should be as secure
as possible as long as all previous specifications
are validated.
11. Limited Storage Space. Any data storage used
should be small enough to not create additional
costs for TSPs, as long as all previous specifica-
tions are validated.
3 RELATED WORK
In this section, we present the related work on format-
preserving encryption (FPE) and static pre-computed
tables. We position our contribution with respect to
the described related work.
The authors in (Díaz-Santiago et al., 2014) for-
mally define tokenization systems and identify three
different systems that solve the problem of tokeniza-
tion both securely and efficiently. The first one uses
format-preserving encryption (FPE), while the lat-
ter two systems rely on off-the-shelf cryptographic
primitives using ordinary block ciphers, stream ci-
phers supporting initialization vectors, and physical
random number generators. The difference between
both relies on whether pairs of token and PAN are
stored in the card-vault in the encrypted form or not.
The authors also give several security notions and
provably secure constructions. However, they do not
consider adaptive constructions, and unlike (Cachin
et al., 2017), they do not address updatable tokens.
The authors also refer to the “Voltage Security” so-
lution (Voltage Security, 2012) as the only solution
at this time to the tokenization problem with known
cryptographic guarantees, using static pre-computed
tables.
As a matter of fact, most existing solutions are
static and do not provide key updatability, i.e., they
do not regularly update the cryptographic keys, while
maintaining the tokens’ consistency, which could lead
to security issues. Therefore, in most practical de-
ployments, cryptographic keys must be re-keyed pe-
riodically to ensure continued security. (Cachin et al.,
2017) constructs two tokenization models for updat-
able tokenization with key evolution, in which a key
exposure does not disclose relations among tokenized
data in the past, and where the updates to the tok-
enized data set can be made by an untrusted entity and
preserve the consistency of the data. The authors for-
mally define the security requirements that guarantee
unlinkability among different tokens generated from
a same user.
3.1 Format-preserving Encryption
One common option for the generation of tokens is
the use of Format-preserving Encryption (FPE) (Bel-
lare et al., 2009). FPE can be seen as a key-indexed
pseudorandom permutation of the set of all values of
correct format, called domain. The keyspace can be
much greater than the domain (should have crypto-
graphically big enough size).
FPE has gradually emerged as a useful tool in ap-
plied cryptography in recent years. The initial mo-
tivation for its use came from the encryption issues
raised by companies looking for specific data formats.
For instance, encrypting distinct and unpredictable
16-digit credit card numbers with traditional block ci-
phers would expand the data and change its format,
which would require modifications of the applications
or databases at huge expense (Liu et al., 2010).
The goal of FPE is to avoid the need for a database
to link a token to a CCN. The natural use of FPE is to
encrypt the individual account digits (and the check-
sum digit) as the 8 open digits of the token. The vali-
dation of the token is then done by decryption of the 8
open digits of the token to retrieve a card number that
is then transmitted to the bank for payment. If the to-
ken given by the merchant to the TSP is incorrect, the
corresponding bank account would be invalid.
For now, the domain size remains out of reach of
known attacks on small domains, as it is big enough.
For example, in (Hoang et al., 2018), attacks are pro-
vided on domains up to 8 bits. Following the attacks
discovered in (Durak and Vaudenay, 2017), the Na-
tional Institute of Standards and Technology (NIST)
recommends using domains of at least one million el-
ements (NIST, 2020). With one hundred million do-
mains, the CCNs FPE systems are still out of reach for
now, but this should be a concern for a long-lasting
system.
The first limitation found in the use of FPE is that
the map from users to the 8 open digits is not bijec-
tive, since two banks with different fixed digits can
issue the same open digits to two different users, e.g.,
John Doe, client ID 1234 5678 at BankA and Michel
Dupont, client ID 1234 5678 at BankB. Such a sce-
nario would imply that the tokens generated by these
users would always be the same. These two users can-
SECRYPT 2021 - 18th International Conference on Security and Cryptography
18