Tokenization Product Security Guidelines
Tokenization Product Security Guidelines
Tokenization Product Security Guidelines
Version:
1.0
Date:
April 2015
Author:
Table of Contents
Introduction ........................................................................................................................................................... 4
Intended Audience ................................................................................................................................................. 5
Intended Usage ..................................................................................................................................................... 5
Terminology ........................................................................................................................................................... 5
Naming Convention for Guidelines/Best Practices .............................................................................................. 6
Tokenization Classification ..................................................................................................................................... 6
Tokens and Tokenization ........................................................................................................................................ 7
Irreversible Tokens ................................................................................................................................................ 7
Reversible Tokens ................................................................................................................................................. 7
Tokenization Roles .................................................................................................................................................. 8
Tokenization At-a-Glance ........................................................................................................................................ 8
Irreversible Tokens ................................................................................................................................................ 9
Reversible Tokens ............................................................................................................................................... 11
Detailed Tokenization Guidelines/Best Practices ............................................................................................... 13
Use of Secure Cryptographic Devices (SCDs) .................................................................................................... 13
General Guidelines/Best Practices ...................................................................................................................... 14
Overview of Security Domains for Tokenization ................................................................................................ 24
Applicability of Best Practices to Different Token types ................................................................................... 25
Irreversible Tokens ................................................................................................................................................ 26
Domain 1: Token Generation .............................................................................................................................. 26
Domain 2: Token Mapping................................................................................................................................... 31
Domain 3: Card Data Vault .................................................................................................................................. 31
Domain 4: Cryptographic Key Management ....................................................................................................... 32
Reversible Cryptographic Tokens ........................................................................................................................ 34
Domain 1: Token Generation .............................................................................................................................. 34
Domain 2: Token Mapping................................................................................................................................... 40
Domain 3: Card Data Vault .................................................................................................................................. 42
Domain 4: Cryptographic Key Management ....................................................................................................... 43
Reversible Non-Cryptographic Tokens ............................................................................................................... 47
Domain 1: Token Generation .............................................................................................................................. 47
Domain 2: Token Mapping................................................................................................................................... 52
Domain 3: Card Data Vault .................................................................................................................................. 54
Domain 4: Cryptographic Key Management ....................................................................................................... 56
Annex A Guidelines/Best Practices for Products Using an SCD (Normative).............................................. 58
Annex B Tokenization Installation Guide (TIG) (Normative)........................................................................... 63
Recommended Content for Tokenization Installation Guide ............................................................................... 63
Annex C Minimum Key Sizes and Equivalent Key Strengths for Cryptographic Primitives (Normative) . 67
Cryptographic Algorithms .................................................................................................................................... 67
Secure Hash Algorithms ...................................................................................................................................... 69
Random Number Generators .............................................................................................................................. 69
Annex D Cryptographic Key-Management Life Cycle (Informative) .............................................................. 70
Cryptographic Key-Management Life Cycle Process Definitions ........................................................................ 70
Operational Life of a Key ..................................................................................................................................... 71
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
......................................................................................................................................................... 81
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
Introduction
With a rising demand for tokenization products, the PCI Security Standards Council (PCI SSC) believes it is
imperative to build, test, and deploy products that provide strong support for compliance with the PCI Data
Security Standard (PCI DSS). With this aim, the Council has produced these technical guidelines for
evaluating tokenization products that replace the primary account number (PAN) with a surrogate value called
a token. The security and robustness of a tokenization system relies on many factors, including the
configuration of different components, the overall implementation, and the availability and functionality of
specific security features for each product. A tokenization product can be a hardware device, such as an
appliance, a software application, and/or a service offering.
The security objective of a tokenization process is to ensure the resulting token has no value to an attacker
(see Annex G Formal Security Objective of a Tokenization Product). When evaluating a tokenization
system, it is important to consider all elements of the overall tokenization implementation. These elements
include the technologies and mechanisms used to capture cardholder data, how a transaction moves through
the entitys environment, the transmission from the point-of-capture (e.g., point-of-sale system) to the
authorization endpoint, how tokens are retained for use (e.g. in back office systems) and so on. The
tokenization implementation should also address potential attack vectors against each component and
provide the ability to confirm with confidence the mitigation of associated risks.
A token, as described in these guidelines, replaces a PAN with a surrogate value. The token can be stored in
lieu of a PAN, reducing the risk of unauthorized disclosure of a PAN.
This document, Tokenization Product Security Guidelines, provides best practices for acquiring tokens,
which are defined as:
Tokens created by the acquirer, merchant, or a merchants service provider. This token is
created after the cardholder presents their payment credentials. Acquiring tokens may be used
as part of the authorization process, including card-on-file transactions.
The General Guidelines/Best Practices statements are intended for all types of token-generation methods,
and there are also specific Guidelines/Best Practices for irreversible and reversible tokens. This document
also describes different classifications of tokens (i.e., tokenization taxonomy), including their general use
cases. This document is neutral to which approach is used by product developers and builders.
This document does not address scope of the cardholder data environment (CDE) or applicable PCI DSS
requirements.
The launch of this document does not constitute a recommendation from the Council or obligate merchants,
service providers, or financial institutions to purchase or deploy such products.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
Intended Audience
The intended audience includes tokenization product developers, vendors and evaluators, as well as entities
wishing to design and build tokenization systems and products, and entities using, or wishing to use,
tokenization systems and products. These guidelines may also be applicable to any payment industry
stakeholder (e.g., merchants, payment processors, acquirers, service providers, and assessors).
Intended Usage
Usage for different stakeholders may include:
Tokenization solution or product vendors: May evaluate their tokenization offerings against these
guidelines, allowing customers to obtain a degree of assurance about a purchase.
Organizations wishing to develop their own tokenization solution: May use this document as best
practices upon which they can base functional and non-functional requirements.
Organizations wishing to procure tokenization products and solutions: May include these as
requirements in their RFPs or other processes for evaluating tokenization products.
Terminology
As stated above, the guidelines in this document are intended for use with acquiring tokens.
Tokenization as used within this document is a process by which a surrogate value, called a token,
replaces the primary account number (PAN) and, optionally, other data. The tokenization process may or may
not include functionality to exchange a token for the original PAN (de-tokenization). The security of an
individual token relies predominantly on the infeasibility of determining the original PAN knowing only the
surrogate value (i.e., token).
The terms Informative and Normative are used to distinguish informational content from a security best
practice or recommendation. For example: An annex marked as informative provides supporting material,
such as samples, examples, or tutorial. An annex marked as normative provides further clarification of the
security guidelines/best practices.
Further guidance of terms used throughout this document is provided in the Glossary, which follows the
annexes at the end of the document.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
Tokenization Classification
Figure 1 provides an overview of how the tokenization processes are classified in this document (i.e.,
tokenization taxonomy). Different types of tokens have differing use cases.
As the figure above shows, different classes of tokens may exist; these are created through distinct
mechanisms and may support different use cases. In general, tokens are either created by a mathematical
process (e.g., cryptographic function) or by a non-cryptographic process (e.g., data look-up through a
database function). However, this document does not preclude hybrid products using more than one
classification.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
Irreversible Tokens
Irreversible tokens can never be converted back to the original PAN. It is not possible in any circumstance for
any party to obtain a PAN from its irreversible token, either through analysis or from any kind of stored data
extraction. Within this classification, tokens may be authenticatable or non-authenticatable.
Reversible Tokens
Reversible tokens provide the possibility for entities using or producing tokens to obtain the original PAN from
the token. Reversible tokens have the potential to become a PAN again by the process of de-tokenization.
Reversible tokens can be mapped to a unique PAN or multiple tokens may map back to the same PAN
depending on technology used. If it is technically possible for a token to be de-tokenized, a product is
considered to be a reversible tokenization product even if the entity producing the tokens does not intend to
permit de-tokenization.
The security measures for the different approaches to reversible tokens (i.e., cryptographic and noncryptographic) have some common high-level recommendations; at the detailed level, they require tailored
criteria. For instance, regardless of whether the tokens are created cryptographically, a PAN is retrievable
from its reversible token. An authorized user may obtain the original PAN from its token with a de-tokenization
request through an appropriate access control mechanism.
An exception to this is a hybrid product in which the cryptographic token is stored in a card data vault (CDV) associating it
with its PAN. In this scenario, the guidelines/best practices for a non-cryptographic token also apply.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
Tokenization Roles
This section summarizes the roles of stakeholders with direct responsibility for tokenization products or
services.
Stakeholder Role
Responsibilities
Tokenization
Product Vendor
Tokenization
Service Provider
Tokenization At-a-Glance
In accordance with the tokenization taxonomy, irreversible and reversible tokens have different security
considerations in addition to the general guidelines that apply to all tokenization products. This section gives
an overview and illustration of the data flow within four tokenization scenarios. Figures 2 and 3 are examples
of irreversible tokenization scenarios. Figures 4 and 5 are examples of reversible tokenization scenarios. It is
important to note that the tokenization product schematics in the following figures are meant to illustrate one
of many possible scenarios.
Note: These examples illustrate data flow within a hypothetical tokenization product implementation and do
not describe any resulting cardholder data environment (CDE).
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
Irreversible Tokens
Figure 2 shows generic PAN sources sending a PAN to a tokenization product. The tokenization product then
sends an irreversible token back to the components requesting it along with any other transaction information,
excluding PAN and sensitive authentication data (SAD). In this case, only the token is stored after
authorization.
Note: This example illustrates data flow within a hypothetical tokenization product implementation and does
not describe any resulting CDE. Additionally, tokenization may occur pre-authorization or post-authorization.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
Figure 3 shows another irreversible tokenization scenario where the tokenization takes place at the point of
interaction. The irreversible token is then sent to the token-only components along with any other transaction
information, excluding PAN and SAD. In this case, after authorization only the token is stored.
Note: This example illustrates data flow within a hypothetical tokenization product implementation and does
not describe any resulting CDE. Additionally, tokenization may occur pre-authorization or post-authorization.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
10
Reversible Tokens
Figure 4 shows a reversible tokenization implementation where a reversible token is sent back to the
components requesting it. The figure shows that one portion of the environment has the capability for detokenization.
Note: This example illustrates data flow within a hypothetical tokenization product implementation and does
not describe any resulting CDE. Additionally, tokenization may occur pre-authorization or post-authorization.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
11
Figure 5 shows another reversible tokenization scenario where tokenization is performed with a software
product.
Note: This example illustrates data flow within a hypothetical tokenization product implementation and does
not describe any resulting CDE. Additionally, tokenization may occur pre-authorization or post-authorization.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
12
Tokenization Guideline/Best Practice This column defines the Tokenization Product Security
Guidelines against which tokenization products may be evaluated.
Evaluation Procedures This column shows processes to be followed to evaluate that the
tokenization product has met the Guidelines/Best Practices.
Guidance This column describes the intent or security objective behind each Guideline/Best Practice.
Reversible cryptographic tokenization products, as these use a cryptographic key to create tokens;
Tokenization products that encrypt part or all of the CDV to protect PAN, tokens, or the token/PAN
relationship;
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
13
Evaluation Procedures
Remarks
Hardware products that have achieved a FIPS
140-2 Level 3 rating have undergone a rigorous
qualification process to protect the cryptographic
module and verify cryptographic algorithms.
This provides an industry standard of assurance
for evaluating cryptographic modules and
algorithms. Additionally, the operation of an SCD
in FIPS mode increases the overall security of the
device and core functionality provided by the
SCD.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
14
Evaluation Procedures
Remarks
The intent is to show that the creation of token-toPAN pairs is independent of all other token-toPAN pairs. Therefore, the evaluation should show
that each instance of a token-to-PAN pair is
statistically independent of all other instances of
token-to-PAN pairs.
Additionally, the randomness and security of the
tokenization process should also be confirmed.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
15
Evaluation Procedures
Remarks
A data element or field is logically bound to its label if one or more of the following are true: (1) the label and datum are cryptographically bound such that an
attempt to change the label is detectable (e.g., as in message authentication); (2) the label and datum are programmatically bound (i.e., they form a data object
that the underlying programming language treats as a single objecte.g., a 2-tuple [label, datum]); or (3) the label is the logical representation of the data item
such that a change in the label results in it ceasing to represent the data with which it was previously associated and such that the data item represented by the
label cannot be changed or replaced except through use of the label.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
16
Evaluation Procedures
Remarks
Without proper instruction on how to install and
use the tokenization product, an entity might
configure and use the product in an insecure
manner. Therefore, the intent is to ensure that all
necessary information (see Annex B
Tokenization Installation Guide (TIG)) is provided
by the vendor of the product to the entity
implementing the product.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
17
Evaluation Procedures
GT 10.a Identify all logical access-control points
to the tokenization system, including but not
limited to applications, people, processes, and
systems.
GT 10.b Verify that all logical access-control
points function as specified in the documentation
and as defined by GT 9.
Remarks
The intent is to preserve the integrity of the
tokenization and/or de-tokenization process by
limiting access to the tokenization and/or detokenization system to only specifically authorized
users and systems. This can be accomplished
with a proper authentication process that is
documented and validated to include all accesscontrol points.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
18
Evaluation Procedures
Remarks
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
19
Evaluation Procedures
Remarks
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
20
Evaluation Procedures
Remarks
source.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
21
Evaluation Procedures
GT 11 Confirm that no function exists that allows
the conversion of Tokens produced under one
mechanism (or cryptographic key) to another
token produced under a different mechanism (or
cryptographic key).
Remarks
There are many reasons why it might become
necessary to change from one tokenization basis
to another. Examples include changing
tokenization vendor, suspected security failure,
regulatory change, transfer of assets (e.g., sale or
merger), and migration to a new platform that
requires a different product. As a result,
organizations may find the need to convert
tokens. To ensure the integrity of each of the
tokenization systems, the conversion process will
require the token to become PAN in order to
perform the next tokenization process. (See
Annex I Recursive Tokenization and Annex J
Token-to-Token Conversions.)
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
22
Evaluation Procedures
Remarks
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
23
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
24
Reversible
Reversible Non-
Cryptographic (RC)
Cryptographic (RN)
Hybrid
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
Potentially
Yes
Yes
Yes
Yes
Yes
Yes
Yes, if an SCD is
Yes, if an SCD is
Yes, if an SCD is
used
used
used
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
Yes
25
Irreversible Tokens
These Guidelines/Best Practices for irreversible tokens are in addition to the General Guidelines/Best Practices. They apply only to tokenization
products that qualify as irreversible.
Each domain has its own table that provides an overview of the domain. Each guideline/best practice is presented in detail following the table.
Summary of Tokenization
Guidelines/Best Practices
Characteristics
IT 1A
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
26
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
27
Evaluation Procedures
Guidance
IT 1A-2 Verify that the token does not contain cleartext digits of the PAN, except by chance.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
28
Evaluation Procedures
IT 1A-3.b Verify that the coexistence of a truncated
PAN and a token does not provide a statistical
advantage greater than the probably of correctly
guessing the PAN based on the truncated value
alone. Based on the mechanism used to produce the
irreversible token, assess whether the truncated
value would be sufficient to permit a known-plaintext
attack (which might occur off line). If so, would a
successful attack compromise the mechanism (e.g.,
cryptographic primitive) or only one PAN/token pair?
If the former, fail. If the latter, note weakness and
determine whether a control exists that would
effectively prevent or detect the acquisition of
multiple token/truncated PAN pairs. (Such a control
is unlikely to exist, so this would also generally fail.)
Guidance
The intent is to ensure that the probability of
guessing a token for a given PAN is no greater
than that of guessing the PAN based on a
truncated PAN under current rules without
recourse to a Luhn check.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
29
Evaluation Procedures
IT 1A-4.1.a Verify that mechanisms are in place to
prevent information leakage.
IT 1A-4.1.b Verify that the controls in place to
prevent attempted PAN-space exhaustion are
effective and function as document by the vendor.
Guidance
This intent is to ensure that no data leakage
from the tokenization process gives any
increased probability of guessing either an
associated PAN or a future token.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
30
Summary of Tokenization
Guidelines/Best Practices
Characteristics
Not applicable.
Domain 2 has no applicable Guidelines/Best Practices for the irreversible token scenario.
Characteristics
Not applicable.
Summary of Tokenization
Guidelines/Best Practices
Domain 3 has no applicable Guidelines/Best
Practices for this irreversible token scenario.
A CDV is not permitted for irreversible token implementations. Therefore, Domain 3 has no applicable Guidelines/Best Practices for the
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
31
Summary of Tokenization
Guidelines/Best Practices
Characteristics
Management
IT 4A
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
32
Evaluation Procedures
IT 4A-3.a Verify that the vendor asserted
mechanism exists that would zeroize/destroy
the cryptographic keys without requiring the
device to be tampered.
IT 4A-3.b Verify that the mechanism
zeroizes/destroys the cryptographic keys
without requiring the device to be tampered.
Guidance
The ability to render a device inoperable through
zeroization/destruction of its cryptographic keys
allows an organization to quickly respond to a bad
situation that could lead to the compromise of
PAN. It should be noted that access to this
function should be strictly limited and incorporates
logging and alerts.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
33
Characteristics
Key generation.
Summary of Tokenization
Guidelines/Best Practices
RC 1A Cryptographic key management should be
secure. (See Domain 4: CKM.)
RC 1B The probability of guessing a token to PAN
relationship should be less than 1 in 106.
RC 1C Tokens that are based on the entire PAN
should not be stored if the tokenization product
(including any dependent systems) also stores
their corresponding truncated PANs.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
34
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
35
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
36
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
37
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
38
Evaluation Procedures
Guidance
Alternatively:
Confirm that the tokens produced by the product
do not contain any digits from the original PAN,
except by chance.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
39
Summary of Tokenization
Guidelines/Best Practices
Characteristics
Testing Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
40
Testing Procedures
RC 2A-2.a Verify that documentation exists that
describes the RBACs used when obtaining a
PAN for its associated token.
Guidance
Using RBACs can ensure that the detokenization request is limited to only those
individual users with authorization to make those
requests.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
41
Characteristics
Summary of Tokenization
Guidelines/Best Practices
Domain 3 may have no applicable Guidelines/Best
Domain 3 has no applicable Guidelines/Best Practices because the PAN is not being stored in a card data vault.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
42
Characteristics
Key generation
Key storage
Key strength
Key lifecycle
Summary of Tokenization
Guidelines/Best Practices
RC 4A All cryptographic key management (CKM)
operations should be performed in an
approved SCD (e.g., HSM).
RC 4B CKM should be performed in accordance with
ISO/NIST Standardse.g., NIST Special
Publication 800-57, ISO/IEC 11770, and NIST
Special Publication 800-130.
RC 4C The effective key strength should be at least
128 bits.
RC 4D If cryptographic keys are used to produce
multiple, different PAN/token setse.g., to
separate merchantseach key should be
statistically independent.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
43
Evaluation Procedures
Guidance
All symmetric keys (except ephemeral keys that
are one-time use) must exist only in one of the
approved formsi.e., within an approved SCD,
in full-length cryptographic key shares, or
encrypted under another cryptographic key of
equal or greater effective key strength.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
44
Evaluation Procedures
RC 4B.a Verify that documentation exists that
describes all cryptographic key management
operations.
Guidance
In order to help ensure that CKM is performed
securely, ensure it is done in accordance with the
appropriate industry standards and the vendor
provides the relevant supporting documentation.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
45
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
46
Characteristics
Summary of Tokenization
Guidelines/Best Practices
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
47
Evaluation Procedures
RN 1A.a Verify that documentation exists
describing how the token is generated
independently from its PAN.
RN 1A.b Verify that the token is generated
independently of its PAN as described in the
documentation.
Guidance
The intent is to ensure that tokens are generated
independently of their corresponding PANs and
that their relationship only exists within the CDV.
If the token and the PAN are not independent,
then they have a relationship or are considered
a cryptographic token.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
48
Evaluation Procedures
RN 1B.a Verify that the product functions in
accordance with the security model or formal
proof provided by the vendor. (See Annex K
Security Models and Formal Proofs.)
Note: If a cryptographic primitive is used (per
Annex C Minimum Key Sizes and Equivalent
Key Strengths for Cryptographic Primitives), the
vendor should provide both a statistical
validation document (NIST CAVP cryptogram
validation document or similar), and security
proof in order to validate reversible token
generation. (See Annex C Minimum Key Sizes
and Equivalent Key Strengths for Cryptographic
Primitives for approved primitives and methods.)
Guidance
The intent is to set a floor for the probability of
guessing a PAN from its token. It is also
essential that the vendor clearly document how
they measure and achieve the probability of
guessing a PAN from its token.
RN 1B.b Assess the validity of the vendorasserted model or proof (See Annex K
Security Models and Formal Proofs).
Note: The vendor should provide both a
statistical validation document and security proof
to validate reversible token generation using
non-cryptographic means within their
application.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
49
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
50
Evaluation Procedures
RN 1B-4.a Verify that documentation exists
describing how a change in the clear digits of
the PAN changes the token mapping.
Guidance
The intent is to ensure that all PANs map to a
different token. Thus, if there is a change in the
clear-text digits of the PAN, there should be a
change to the token mapping.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
51
Summary of Tokenization
Guidelines/Best Practices
Characteristics
Evaluation Procedures
RN 2A.a Verify that documentation exists that
describes the mapping of a token to its
corresponding PAN.
Guidance
The de-tokenization of the token to the full PAN
value can only be performed via a data look-up
or index within the CDV only and not via a
cryptographic method.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
52
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
53
Summary of Tokenization
Guidelines/Best Practices
Characteristics
Evaluation Procedures
RN 3A.a Verify that documentation exists
describing the key strength of the key used to
encrypt the PAN.
RN 3A.b Confirm that the product actually uses
only keys that have an effective key strength of
at least 128 bits.
Guidance
The intent of strong cryptography is that the
encryption be based on an industry-tested and
accepted algorithmnot a proprietary or
"home-grown" algorithmwith strong
cryptographic keys.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
54
Evaluation Procedures
RN 3B.a Verify that documentation exists that
describe the RBACs used for accessing the
CDV.
RN 3B.b Verify that the RBACs function as
described in the vendor documentation.
RN 3B.c Assess whether the RBACs are
adequate when accessing the CDV.
Guidance
In order to limit access to the CDV, only those
individuals who need such access should be
defined using a role-based access-control
systeme.g., system administrator, security
administrator, or key administrator. Individual
access can be granted according to their job
classification and function by using an already
created role.
Documented procedures identify controls that
have been established for protecting backup
copies. These procedures allow for recreating
steps to ensure consistency of methods.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
55
Characteristics
Summary of Tokenization
Guidelines/Best Practices
RN 4A All cryptographic key management operations
protected.
(e.g., HSM).
RN 4B All CKM should be performed in accordance
with NIST/ISO Standardse.g., NIST Special
Publication 800-57, ISO/IEC 11770, and NIST
Special Publication 800-130.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
56
Evaluation Procedures
RN 4A.a Verify that documentation exists that
describes the CKM operations that are
performed within an approved SCD or HSM.
RN 4A.b Verify that all CKM operations are
performed within an HSM or SCD.
Guidance
Hardware products that have achieved a FIPS
140-2 Level 3 rating have undergone a rigorous
qualification process to protect the
cryptographic module and verify cryptographic
algorithms. Since key-management functions
are fundamental to the security of the
tokenization product, use of approved SCDs
provides reasonable assurance of secure
operations.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
57
Summary of Tokenization
Guidelines/Best Practices
Characteristics
Device Management
A 1A
life cycle.
Evaluation Procedures
Guidance
[Conditional] If secure
cryptographic devices are used:
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
58
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
59
Evaluation Procedures
A 1A-7.a Verify that documentation exists that
describes the procedures for restricting access
to devices in their possession to authorized
personnel.
A 1A-7.b Provide evidence of an independent
assessment (or audit) of the procedures in their
environment.
Guidance
Having documented procedures that restricts
access of the devices to only authorized personnel
of the product vendor ensures proper custody of
those devices. Unauthorized personnel may effect
changes to the devices knowingly or unknowingly
before it gets to the end user.
Integrity-check of update.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
60
Evaluation Procedures
Guidance
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
61
Evaluation Procedures
A 1A-10.a Verify that procedures exist for the
detection of tampered devices in the vendors
possession.
Guidance
Tamper-detection controls provide notification of
physical alternation or damage of the device.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
62
All hardware and software components of the tokenization product, including any dependent components that are separate to the product and
which are necessary for functionality of the tokenization product.
Description of the environment in which the product is intended to operatee.g., attended, unattended, physically secure, publicly accessible, or
mobile.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
63
TIG I: Tokenization Installation Guide Recommended Content for all Tokenization Products
2 Include the following as applicable to the tokenization product:
Describe the logical and physical technical architecture of all of the solution components including typical integration points with existing
infrastructuree.g., web proxy, email gateway, etc.
Provide details on hardware and OS infrastructure requirements, software or appliance, web server, application server, database requirements,
tiered logical architecture, application dependenciese.g., third-party software or open source usage, etc.
Attach logical and physical architecture diagrams depicting how the solution components would be implemented.
3 A description of the vendors published versioning methodology for the tokenization producti.e., both hardware and software components of the
productincluding:
Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.).
Details of any wildcard elements that are used, including that they will never be used to represent a security-impacting change.
A description of the purpose and tokenization methods for all tokenization functions performed by the product.
5 Instructions on how to install and set up the tokenization product for correct functioning of all tokenization functions.
6 Description of the environment in which the product is intended to operatee.g., attended, unattended, physically secure, publicly accessible, or
mobile.
7 A detailed description and data flow diagram of how the tokenization product stores, processes and/or transmits PAN.
8 If the tokenization product stores PAN for any tokenization process, outside of the CDV, describe the methodology or processes used by the product to
securely delete PAN upon completion of processing.
9 Details about how the application outputs clear-text PAN, including:
Description of any tokenization product functions that allow for the output of clear-text PANfor example, through the use of whitelisting BIN
ranges.
Instructions for configuring the tokenization product to permit only authorized personnel to access functions that allow for output of clear-text PAN
data.
10 Instructions for configuring secure authenticationincluding administrative, assigning privileges, adding user identifiers, passwords, etc.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
64
TIG I: Tokenization Installation Guide Recommended Content for all Tokenization Products
11 Procedures for the secure disposal of devices, including how to render sensitive data irrecoverable prior to device disposal.
12 List of protocols, services, and ports used by the tokenization product.
13 Instructions for use of secure communication methods, consistent with the products communication interfaces:
A description of what each external communication method is used for by the tokenization product.
Instructions for how to configure each of the tokenization products external communication methods for secure functioning.
14 For all configurable options provided with the tokenization product, provide necessary instructions for the appropriate security settings.
15 Specific instructions for installing and connecting tokenization appliances to maintain the integrity of tokenization product, including any permitted
connections to other devices.
16 If the tokenization product shares resources, include:
Instructions for configuring the tokenization product for secure integration with shared resources.
17 Instructions for performing pre-installation inspection procedures, including physical and functional tests and visual inspection, to verify tokenization
product components have not been tampered with or compromised. Also, provide instructions on what to do if tampering or compromise is
discovered.
18 A description of how tokenization product enforces secure application installations, upgrades, and updates.
19 Instructions for backing out or uninstalling applications and application updates.
20 Instructions for rendering cryptographic keying material irretrievable, to include:
Instructions on how to re-encrypt historic data with new keys, including procedures for maintaining security of clear-text data during the
decryption/re-encryption process.
Instructions on how to transition data to the updated version prior to destruction of previous version keys.
21 Instructions on how the tokenization application enforces strong authentication for any authentication credentialsfor example, user identifiers,
passwordsthat the application generates or manages. Refer to GT 9 and, as applicable, RC 2A-2, RN 2B, and RN 3B.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
65
TIG I: Tokenization Installation Guide Recommended Content for all Tokenization Products
22 Detailed instructions on how to physically secure tokenization devices to prevent unauthorized removal or substitution, including specific examples of
how devices can be physically secured.
23 Detailed procedures for performing physical inspections of tokenization devices to detect tampering or modification, including:
Guidance for physical inspections, including photographs or drawings of the device illustrating what to inspectfor example, missing or altered
seals or screws, extraneous wiring, holes in the device, or the addition of labels or other covering material that could be used to mask damage
from device tampering.
Details of device weight and/or how to determine the correct weight of the device for a given configuration.
25 If the tokenization product facilitates non-console administrative access, include instructions on how to configure the application to use strong
cryptography (such as SSH, VPN, or TLS) for encryption of all non-console administrative access to tokenization product.
26 Who to contact/or what steps to take if product fails.
The vendor may include additional information in the TIG that the vendor considers useful to the entity implementing the tokenization
product. For example, consider the following:
Provide benchmarking details of the capacity and performance, scalable and load balancing, synchronization and backups.
Define the memory and disc requirements for each of the solution components.
Provide document encryption export restrictionse.g., export licenses findings or classification from Department of
Commerce.
The intent of this document is to provide supplemental information. Information provided here does not replace or
supersede requirements in any PCI SSC Standard.
66
Cryptographic Algorithms
The following are the minimum key sizes and parameters for the algorithm(s) in question that should be used
in connection with key transport, exchange, or establishment and for data protection in a tokenization product
that uses encryption:
Algorithm
TDEA
AES
RSA
Elliptic
Curve
DSA/D-H
Not Allowed
128
3072
256
3072/256
A key-encipherment key should be at least of equal or greater strength than any key it is protecting. This
applies to any key-encipherment key used for the protection of secret or private keys that are stored or for
keys used to encrypt any secret or private keys for loading or transport. The following algorithms and bits of
security are considered equivalent for this purpose:
Table C-1
Key Lengths
Bits of Security
Symmetric key
algorithms
112
3TDEA
[168-bit key]
RSA
Elliptic Curve
D-H
2048
224-225
2048/224
128
AES-128
3072
256-383
3072/256
192
AES-192
7680
384-511
7680/384
256
AES-256
15360
512+
15360/512
Not
Allowed
3TDEA refers to three-key triple DEA keys exclusive of parity bits. The RSA key size refers to the size of the
modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this
order should be slightly smaller than the field size. The DSA key sizes refer to the size of the modulus and the
minimum size of a large subgroup.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
67
DH implementations Entities should securely generate and distribute the system-wide parameters:
generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p should be at
least 3072 bits long, and parameter q should be at least 256 bits long. Each entity should generate a
private key x and a public key y using the domain parameters (p, q, g).
ECDH implementations Entities should securely generate and distribute the system-wide parameters.
Entities may generate the elliptic curve domain parameters or use a recommended curve (See FIPS1864). The elliptic curve specified by the domain parameters should be at least as secure as P-256 (or P384). Each entity should generate a private key d and a public key Q using the specified elliptic curve
domain parameters. (See FIPS186-4 for methods of generating d and Q).
Each private key should be statistically unique, unpredictable, and created using an approved random
number generator as described in this document.
Entities should authenticate the DH or ECDH public keys using DSA, ECDSA, a certificate, or a
symmetric MAC (see ISO 16609 Banking Requirements for message authentication using symmetric
techniques). One of the following should be used: MAC algorithm 1 using padding method 3, MAC
algorithm 5 using padding method 4.
Modes
AES
CTR, OCB, CBC, OFB, CFB, FFn (ECB should not be used if encrypting more than
one block)
RSA
RSAES-OAEP
ECC
D-H
DHE, EHD
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
68
Table C-2
Bits of Security
Hash Algorithm
128
SHA-256
128
192
SHA3-384
256
SHA-512
256
SHA3-512
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
69
Definition
Generation
Key generation involves the creation of a new key for subsequent use.
Storage
Key storage involves the holding of a key in one of the permissible forms.
Backup
Key backup occurs when a protected copy of a key is kept in storage during its
operational use.
Use
Key use occurs when a key is employed for the cryptographic purpose for which
it was intended.
Replacement
Key replacement occurs when one key is substituted for another when the
original key is known or suspected to be compromised or the end of its
operational life is reached.
Destruction
Key destruction ensures that an instance of a key in one of the permissible key
forms no longer exists at a specific location. Information may still exist at the
location from which the key may be feasibly reconstructed for subsequent use.
Deletion
Key deletion is the process by which an unwanted key, and information from
which the key may be reconstructed, is destroyed at its operational storage/use
location. A key may be deleted from one location and continue to exist at
anothere.g., for archival purposes.
Archive
Key archive is the storage process for a key that is no longer in operational use
at any location.
Termination
Key termination occurs when a key is no longer required for any purpose and all
copies of the key and information required to regenerate or reconstruct the key
have been deleted from all locations where they ever existed.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
70
The effective cryptographic strength of the underlying algorithm for a given key length.
Technological advances that make previously infeasible attacks feasible (i.e., the risk equation
changes for the worse).
Change of ownership where a change of keys is associated with a change in assignment of liability.
Because these and other factors may force an end-of-key-life, any organization developing a tokenization
product that depends on cryptographic materials (or equivalent secrets) should include a mechanism for
supporting the cryptographic key-management life cycle.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
71
Irreversible Tokens
Authenticatable Irreversible Tokens
An authenticatable irreversible token could be used to support warranty enforcement where the
presentation of the payment card that was allegedly used for the purchase could be verified as the one
used. This situation may happen when a customer has lost their receipt and needs a way to prove the
transaction.
Merchant needs PAN for other entities with which they interact.
A typical process in these scenarios may include the business unit that needs the original PAN submitting the
token for de-tokenization. Then, after proper authentication, a PAN is returned in a secure manner (e.g.,
encryption), and when no longer needed, the PAN is deleted or destroyed.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
72
Illustration 1
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
73
In Illustration 2, a typical P2PE transaction occurs. This P2PE solution provider securely transmits the PAN to
the tokenization service provider. The tokenization service provider produces the token and provides the
token to the merchant.
Illustration 2
In Illustration 3, a typical P2PE transaction occurs. In parallel, the POI device produces a token, which goes
directly to the merchant.
Illustration 3
Note: The security of these implementations depends on many factors that are outside the scope of this
document.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
74
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
75
D (FP)
F (FP)
PAN
Token
Comment
7aF1Zx118523mw4cwl5x2
729129118523184663129
599400x18523mw4cw3383
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
76
Examples
H (FP)
I (FP)
PAN
Token
Comment
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
77
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
78
This annex is intended to illustrate how that process may work. Figure 7 shows a process (Process 1) that
converts the token into a PAN (i.e., de-tokenization). Then the PAN goes through another tokenization
process (Process 2), which is completely separate from the first. It is important to note that the two processes
should be separate.
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
79
GrahamDenning Model
HarrisonRuzzoUllman Model
Department of Defense Trusted Computer System Evaluation Criteria (DoD TCSEC) [DoD 5200.28-STD] is
an historic document based on an even earlier government effort [CSC-STD-00l-83, l5 Aug 83] that
formalized evaluating information security in the context of a formal model. The Common Criteria for
Information Technology Security Evaluation (CC) [(ISO/IEC 15408] is the modern prodigy of this
[https://www.commoncriteriaportal.org/cc/].
Formal security proofs use mathematics to model the behavior of a system. Statements about the behavior of
the system can then be evaluated. These hypotheses can be proven or disproven. By demonstrating that the
tokenization product acts in accordance to the model, the security proof can, by analogy, be extended to the
system the model represents.
Automated tools are often used to assist in developing formal security proofs for software. One such tool is
Coq. Coq is a formal proof-management system. It provides a formal language to write mathematical
definitions, executable algorithms and theorems, together with an environment for semi-interactive
development of machine-checked proofs. [http://coq.inria.fr/] As another example, Isabelle (proof assistant) is
an interactive theorem-prover that has been used to formalize theorems including correctness of security
protocols. [http://isabelle.in.tum.de/]
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
80
Glossary
Term
Definition
Acquiring token
Adequate
The technical ability to meet the requirement. The intent is to permit the
assessor flexibility in making this judgment.
(API)
Bespoke
Software that is specially developed for the entity to the entitys custom
requirements by, for example, an in-house software development group or
an external software development company.
(CDE)
Acronyms.
Computationally infeasible
Cryptographic primitive
De-tokenization
Evaluated API
APIs that have been evaluated against secure coding standards to ensure
they function properly.
Irreversible tokens
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
81
Term
Definition
Logically bound
Multi-factor authentication
(MFA)
These factors include something the user has (such as a smart card or
dongle), something the user knows (such as a password, passphrase, or
PIN), or something the user is or does (such as fingerprints, other forms of
biometrics, psychometrics, etc.).
Non-console administrative
access
over a network interface rather than via a direct, physical connection to the
system component. Non-console administrative access includes access
from within local/internal networks as well as access from external, or
remote, networks.
The PAN space is the set of all possible PAN (per ISO definitions that
would be from 13 to 19 digits with some restrictions based on what values
are valid for a given sub-field of the PAN). PAN space exhaustion is the
process of trying every probable value until you find the right one. It
assumes the existence of an oracle (i.e., a means for testing each value).
Reversible token
A token for which a mechanism exists that permits obtaining its associated
PAN.
(SCD)
(SAD)
Acronyms.
Static token
Any token that has a one-to-one relationship with a given PAN such that
the tokenization process for that PAN always results in the same token.
Token
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
82
Term
Definition
Token mapping
Token mapping is the relationship between the token and the PAN. For
instance, a PAN may be mapped to a token by encryption with a secret
key or by a data look-up process within a CDV (where the PAN/token
relationship is secret).
Tokenization appliance
A device (that is, a PCI-listed SCD, FIPS 140-2 Level 3 [validated to FIPS
140-2 Overall Level 3, operated in FIPS mode and initialized to Overall
Level 3 per security policy or above], a device Independently validated to
ISO 13491-1 or self-contained product (e.g., package hardware and
software tokenization product)) used for tokenization functions, detokenization functions, or any functions involving a CDV.
Token-only components
Components that contain the token and do not contain PAN or SAD.
User
Any individual (i.e., person) that is not a consumer (e.g., vendor personnel,
administrators, contractors, or merchant personnel).
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
83
Related Publications
The following American National Standards, International Standards, European Payment Council, NIST, and
PCI standards are applicable and related to the information in this document.
Standard/Resource
Source
ANSI
ANSI X9.119-2012 Retail Financial Services Requirements for Protection of Sensitive Payment
ANSI
ANSI
Control
SEPA Cards Standardisation (SCS) Volume Book of Requirements [Chapter 5]
EPC
ISO
ISO
ISO
ISO
ISO
ISO
NIST
NIST
NIST
PCI SSC
PCI SSC
PCI SSC
PCI SSC
The intent of this document is to provide supplemental information. Information provided here does
not replace or supersede requirements in any PCI SSC Standard.
84