Information Security Journal: A Global Perspective

ISSN: 1939-3555 (Print) 1939-3547 (Online) Journal homepage: www.tandfonline.com/journals/uiss20

Tokenization and Other Methods of Security for

Cardholder Data

Jeff Stapleton & Ralph Spencer Poore

To cite this article: Jeff Stapleton & Ralph Spencer Poore (2011) Tokenization and Other
Methods of Security for Cardholder Data, Information Security Journal: A Global Perspective,
20:2, 91-99, DOI: 10.1080/19393555.2011.560923

To link to this article: https://doi.org/10.1080/19393555.2011.560923

Published online: 11 Apr 2011.

Submit your article to this journal

Article views: 526

View related articles

Citing articles: 2 View citing articles

Full Terms & Conditions of access and use can be found at

https://www.tandfonline.com/action/journalInformation?journalCode=uiss20
Information Security Journal: A Global Perspective, 20:91–99, 2011
Copyright © Taylor & Francis Group, LLC
ISSN: 1939-3555 print / 1939-3547 online
DOI: 10.1080/19393555.2011.560923

Tokenization and Other Methods of Security

for Cardholder Data
Jeff Stapleton and
Ralph Spencer Poore ABSTRACT This paper compares the relative security strengths and practical
Cryptographic Assurance use of tokenization with other cardholder data protection methods including
Services LLC, Arlington, Texas truncation, masking, encryption, hash, and keyed hash. The usefulness of each
method is described, and the subtle security weaknesses of combining meth-
ods are explored. Further, the inherent complexities of using cryptographic
methods with sound key management practices are also presented.

KEYWORDS PCI, tokenization, PAN, masking, truncation, hash, encryption

INTRODUCTION
The Payment Card Industry (PCI) Security Standards Council (SSC) pub-
lished the Data Security Standard (DSS) version 1.2 in October 2008 and
released v2.0 in October 2010. The requirements to “protect cardholder data”
include:
Requirement 3: Protect stored cardholder data and Requirement 4: Encrypt
transmission of cardholder data across open, public networks. Requirements
3.3 and 3.4 provide more detail:
Requirement 3.3: Mask PAN when displayed (the first six and last four digits
are the maximum number of digits to be displayed).
Requirement 3.4: Render the primary account number (PAN), at minimum,
unreadable anywhere it is stored (including on portable digital media, backup
media, in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography

• Truncation
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and
procedures

The PCI DSS prescribes four basic methods of protecting the PAN, the 16-
Address correspondence to Ralph digit number embossed on the front of a credit card and further encoded in
Spencer Poore, Cryptographic
Assurance Services LLC, 4101 West
Track 1 and Track 2 of the magnetic stripe data. To better understand how
Green Oaks Blvd., Suite 305, each method provides protection and how certain combinations of methods
PMB 150, Arlington, TX 76016. introduce security weaknesses, an overview of the PAN structure is provided
E-mail: ralph.poore@cryptographic
assuranceservices.com (refer to Figure 1).

91
 as private-labeled cards. Note that co-branding agree-
MII 5–12 Digits PAN ments (e.g., Chevon Visa card, Amex MasterCard,
BIN b b b b b b a a a a a a a a a c LCD American Airlines Visa card) have blurred the original
IIN AC distinctions.

FIGURE 1 Primary account number layout. Issuer Identification Number

The IIN identifies the issuer. For the United States,
the designated national organization that assigns and
Primary Account Number manages the IIN is the American Bankers Association
The PAN is actually composed of four separate ele- (ABA). Combining the one-digit MII and the five-digit
ments: the major industry identifier (MII), the issuer IIN make up the bank identification number (BIN),
identification number (IIN), an account number (AN) which uniquely identifies the issuer. For example, all
and a check digit based on the Luhn formula. All Visa cards start with a “4,” and the ABA has assigned
of this is defined in the international standard ISO most, but not all, of the six-digit BINs to Visa. In a
7812 Identification Cards — Identification of Issuers similar fashion, the ABA has assigned all of the BINs
(ISO/IEC, 2007). beginning with “51” to “55” to MasterCard. So for any
given issuer, the first six digits of the PAN are prede-
termined, although large issuers typically have many
Major Industry Identifier BINs. Another industry term is the brand “prefix”
referring to a subset of the BIN. For example, the Visa
The major industry identifier (MII) is one digit
prefix is “4” although Visa does not own all BINs rang-
with a value of 0 to 9. Each value has a specific
ing from 400000 to 49999, and the MasterCard prefix
industry usage (see Table 1). “0” is reserved for ISO,
is “51” to “55” as MasterCard owns all BINs ranging
“1” and “2” are for Airlines, “3” is for Travel and
from 510000 to 550000.
Entertainment (used by American Express), “4” (used
by Visa) and “5” (used by MasterCard) are for Banking,
“6” is for Merchandizing (used by Discover), “7” is Account Number
for Petroleum, “8” is for Telecommunications and
The AN can be a 5-digit to 12-digit number.
“9” is reserved for national standards bodies. These
Practically speaking, the PAN can be as short as a 12-
numbers are allocated for international use, and it is
digit number or as long as a 19-digit number. In the
important to note that this numbering scheme is not
early days of credits cards, there were 13-digit, 15-digit,
always followed by smaller issuers, which are referred to
16-digit and several 19-digit debit cards. Today, most
issuers have standardized on 16-digit cards. The AN
TABLE 1 MII Industry Usages can be any number from all zeroes to all nines; how-
ever, most issuers have proprietary numbering schemes
MII Assignment Notes and examples
(see FIGURE 2 for examples).
0 Reserved for ISO www.iso.org
1 Airline
2 Airline Luhn Check Digit
3 Travel and e.g., American Express The last number is the Luhn credit digit (LCD),
entertainment (Amex)
probably one of the simplest, most misunderstood and
4 Banking e.g., Visa
5 Banking e.g., MasterCard possibly misused number. The formula to calculate the
(51 – 54) check digit is defined in the ISO 7812 standard. Its pri-
6 Merchandizing e.g., Discover mary function was to detect transposed digits because
7 Petroleum e.g., British Petroleum in the early days of credit cards the PAN was manu-
8 Telecommunications ally keyed by a sales clerk and errors often occurred. So
9 Reserved for national www.ansi.org
given the first 15 digits of a PAN, the final 16th digit is
standards
deterministic.

J. Stapleton and R. S. Poore 92

 12-digit PAN 105 possible account numbers
b b b b b b a a a a a c

13-digit PAN 106 possible account numbers

b b b b b b a a a a a a c

14-digit PAN 107 possible account numbers

b b b b b b a a a a a a a c

15-digit PAN 108 possible account numbers

b b b b b b a a a a a a a a c

16-digit PAN 109 possible account numbers

b b b b b b a a a a a a a a a c

17-digit PAN 1010 possible account numbers

b b b b b b a a a a a a a a a a c

18-digit PAN 1011 possible account numbers

b b b b b b a a a a a a a a a a a c

19-digit PAN 1012 possible account numbers

b b b b b b a a a a a a a a a a a a c

FIGURE 2 PAN lengths.

Originally there was more variety in PAN lengths. Masking is a method that replaces PAN digits with
For example, Diners issued a 14-digit card, Amex a benign character such as an asterisk “∗ ” or, in this
issued a 15-digit card, Visa issued 13-digit and 16-digit paper’s examples, an “X” character. Exactly which
cards and MasterCard issued 16-digit credit cards and digits are masked depends on the rules of the asso-
19-digit debit cards. Since most issuers have converted ciated compliance regime. Alternatively, tokenization
to 16-digit cards and to simplify the analysis, this paper is a method that replaces PAN digits with a different
focuses on 16-digit PAN. digit (or another character); however, the industry rules
and practices (Visa Best Practices, 2010) are not uni-
formly defined, and the methods include proprietary
techniques. Token generation might employ hashing
methods, encryption or random numbers.
ANALYSIS
As shown in FIGURE 1, even though a PAN is
16 digits it does not have 1016 possible permutations.
Theoretically it might have 1015 once the Luhn check
Masking
digit is accounted for, but practically speaking not all The United States Fair and Accurate Credit
BINs are in use. In fact, since the majority of credit Transactions Act (FACTA) of 2006 prohibits merchants
cards today are Visa, there is at least a 1 in 5 chance that from printing more than the last five digits of the PAN
any randomly selected card is Visa and therefore begins or the card expiration date on any cardholder receipt.
with a “4,” so the number of permutations is more For this method, the masking is also referred to as
akin to 1014 or about 249 possible values. If an adver- truncation.
sary were to target a specific issuer where the BINs are For PCI, masking is a method that allows the first six
known, the number of permutations is realistically 109 and last four digits to remain. so only the middle six
for a single BIN or about 231 potential values. These digits are unknown. Also, 106 permutations or about
numbers are so small that building a list of all possible 221 possible values are even smaller numbers to list all
PAN for a specific BIN is trivial with today’s comput- potential PAN. Thus if an adversary were to obtain a
ing power. This fact is important when considering the database of masked PAN there would be even fewer
overall security of the protection method. FIGURE 3 potential PAN to list since the presence of the Luhn
shows examples of various approaches. check digit allows some invalid PAN to be eliminated.
93 Tokenization and Other Methods of Security for Cardholder Data
 All 16 digits unmasked
Clear PAN
Clear b b b b b b a a a a a a a a a c
with clear digits.

Masked PAN
First 11 digits masked,
for FACTA
Masked X XXXXX XXXXXa a a a c
last 5 clear digits.

Middle 8 digits
Masked PAN
masked, first 4 and
Masked b b b b XX XXXXXX a a a c
for PCI
last 4 clear digits.

Middle 8 digits
Tokenized
tokenized, first 4 and
Tokenized b b b b TT TTTTTT a a a L
PAN in Middle
last 4 clear digits.

Tokenized All 16 digits tokenized

Tokenized T TTTTT TTTTTTTTT T
PAN with Alias with no clear digits.

FIGURE 3 Protection methods.

The Luhn formula is based on a modulo 10 algorithm, for Applications Using Approved Hash Algorithms
so roughly 9 out of 10 potential PAN will not vali- provides security guidelines when using cryptographic
date with a given check digit. Therefore, the potential applications that use the hash functions specified
PAN is reduced to 105 or about 217 possible values, an in FIPS 180-3. Further, NIST has sponsored the
even smaller number. To put this into perspective, 105 Cryptographic Hash Algorithm Competition (http://
is only 100,000 possible numbers which can be listed csrc.nist.gov/groups/ST/hash/sha-3/index.html), also
in a Microsoft Office Excel 2007 spreadsheet. called the “SHA-3” competition.
For example, the SHA-1 algorithm generates a 20-
byte output, or 160-bits. When used with data inputs
Hashing larger than the PAN, the collision resistance for the
Hashing is a method whereby the PAN is the input SHA-1 is estimated at 80-bits. However, when used
to a hash algorithm that generates a fixed sized out- with the smaller PAN as input, not all 2160 possible out-
put. There are many available hash algorithms with puts are generated. That is, the entropy of the output
abbreviated names such as MD4, MD5, SHA-1 and cannot be greater than the entropy of the input. Thus,
SHA-2. MD4 is considered too weak by today’s stan- a 16-digit PAN for a given BIN which really only has
dards, and even MD5 has issues. The financial ser- about 231 potential values can only generate 231 hash
vices standards only recognize SHA-1 and SHA-2 as values, so the vast majority of the SHA-1 outputs are
acceptable. SHA-2 is actually a suite of hash algo- not used. However, an adversary trying to build a list
rithms defined in the Federal Information Processing of valid PAN matched to known hash values would not
Standards (FIPS) 180-3 Secure Hash Standard, which know which PAN to search, so the larger 1014 or about
specifies five secure hash algorithms: SHA-1 and the 249 possible values would need to be searched for each
SHA-2 suite with larger outputs consisting of SHA-224, hash value.
SHA-256, SHA-384 and SHA-512. This paper is not In the case where a masked PAN and a hashed PAN
intended to be a tutorial on hash functions; however, are stored in the same database, the adversary would
the National Institute of Standards and Technology only need to search the lesser 105 or about 217 possible
(NIST) Special Publication 800-107 Recommendation values for each entry. The masked PAN essentially

J. Stapleton and R. S. Poore 94

reduces the effective security of the hash to the lesser However, it has already been shown that the num-
of the two protection methods. Combining these two ber of potential PAN for any random Visa card is more
methods significantly undermines the security of the akin to 1014 or about 249 possible values. Since every
hash method. power of 2 decreases the search space by half and the
DES challenge was achieved in 80,100 seconds, then
the hash for every Visa card can be generated in about
Encryption 625 seconds. Further, since the masked PAN is only 105
Encryption is a method by which a PAN and a or about 217 possible values, then the hash for every
cryptographic key are used with a cryptographic algo- possible card can be generated in about 145 nanosec-
rithm to create a ciphertext that is, for all practical onds. Thus, a database of 10 million entries could be
purposes, seemingly random and unrelated to the clear- determined in about 1 second. Realistically, this is not
text PAN. There are several methods including format very strong security.
preserving encryption (FPE) where the original format Another hashing technique not explicitly men-
of the clear data (e.g., numeric PAN) is preserved in the tioned in the PCI DSS is called a keyed hash. It is a
encrypted data (e.g., numeric). However, at least part method where the cleartext is combined with a cryp-
of the BIN is necessary to route transactions among tographic key and a hash algorithm. Keyed hash works
the merchant, acquirer, network and issuer (refer to with any hash algorithm. The output looks the same
FIGURE 4) so the PAN cannot be fully encrypted as a nonkeyed hash value, but an adversary has to
(PAN Encryption, 2009). test not only all possible cleartext values but also the
The secrecy of the key is essentially the security testing needs to be repeated for each possible crypto-
strength of the encryption method. Different algo- graphic key. For example, for each 1014 or about 249
rithms use different key sizes, which are expressed as possible PAN values, if a 56-bit key (256 possible val-
the number of bits or powers of two. For example, the ues) were used, an adversary would also need to search
data encryption standard (DES) uses a 56-bit key. The the product of the two search spaces—about 2105 possi-
key block is actually 64-bits, but eight are parity bits ble values—a much larger and more reasonable security
that are stripped away before the key is used with the strength.
algorithm. DES is an older algorithm and by today’s Other algorithms use larger keys, but the mathe-
more modern cryptography standards uses too short of matical strength of the algorithm also needs to be
a key, but its history puts security strengths in perspec- considered. For example, triple DES is an implemen-
tive. In 1999 the Third DES challenge solved for a DES tation of “single” DES where the cleartext is first
key (256 possibilities) to be exhaustively determined encrypted using DES, then decrypted using DES and
in 22 hours and 15 minutes. The researchers achieved then encrypted again using DES. If the same key is
an estimated 245 billion DES calculations per second. used for all three DES operations, the result is the same
It just so happens that 256 possible keys is approxi- as just DES. However, if two different keys are used
mately 1016 , which is the size of a PAN. Assuming such that one key is used for the two encryptions and
the DES algorithm is about the same computation as a the second key is used for the decryption, the result
hash algorithm, it would have taken approximately the is a stronger implementation. If three different keys
same amount of time to generate all 1016 possible hash are used for each DES operation, a stronger result is
values for all PAN. obtained. However, due to inherent properties of DES,

PAN ⇒ Token
3rd Party

Token
Merchant Acquirer BIN Network BIN Issuer
PAN

PAN Token
3rd Party

FIGURE 4 Tokenization flow.

95 Tokenization and Other Methods of Security for Cardholder Data

triple DES does not achieve the full strength of two or The international equivalent is ISO 11568 Banking —
three keys. NIST has produced comparisons of relative Key Management (Retail), Part 1: Principles (2005), Part 2:
cryptographic strengths in the Special Publication 800- Symmetric Ciphers, Their Key Management and Life Cycle
57 Recommendation for Key Management. The current (2005) and Part 4: Asymmetric Cryptosystems — Key
advanced encryption standard (AES) is the preferred Management and Life Cycle (2007). There are several key
symmetric algorithm. management basics from which all other requirements,
If the PAN is being encrypted using a symmetric policies, practices and guidelines can be derived.
algorithm, it can likewise be decrypted making the
access controls over the cryptographic key essential. 1. Symmetric (and asymmetric private) keys are secret,
Even if a keyed hash is used, the cryptographic key meaning no one should ever know the value of
must be properly protected and controlled. PCI DSS a key. Proper controls must be in place to pro-
provides some guidance for proper key management tect against disclosure of the key. This can only be
procedures and refers to NIST (http://csrc.nist.gov) in accomplished using a cryptographic hardware mod-
the following: ule where the cleartext key is never exposed outside
Requirement 3.6: Fully document and implement the protected memory of the module. By definition
all key-management processes and procedures for cryp- this invalidates software based cryptography since
tographic keys used for encryption of cardholder data, the key is exposed in the memory of the computer.
including the following: There are methods by which keys can be stored
outside of the cryptographic hardware module, for
3.6.1 Generation of strong cryptographic keys example, as ciphertext encrypted by another key,
3.6.2 Secure cryptographic key distribution key components or K of N key secret shares.
3.6.3 Secure cryptographic key storage 2. Symmetric (and asymmetric) keys are generated and
3.6.4 Periodic cryptographic key changes used for a specific purpose; this is called key sep-
3.6.5 Retirement or replacement of old or suspected aration. Using any cryptographic key for multiple
compromised cryptographic keys purposed can make the key or the data protected
3.6.6 Split knowledge and establishment of dual con- by the key vulnerable to misuse or protocol weak-
trol of cryptographic keys nesses. This topic is too broad to address in this
3.6.7 Prevention of unauthorized substitution of cryp- paper, but there are well-known cryptanalytic attacks
tographic keys based on keys being used for multiple purposes.
3.6.8 Requirement for cryptographic key custodians to 3. Symmetric (and asymmetric) keys all have a life
sign a form stating that they understand and cycle that has a specific beginning, a middle that
accept their key custodian responsibilities must be fully audited and an end where the keys are
eventually destroyed. Keys cannot be used forever
The NIST Special Publication 800-57 Recommen- as this will eventually expose information about the
dation for Key Management (2007) provides a good key or the data protected by the key or allow for
summation of key management: an exhaustive key attack. The size of the key, the
All keys need to be protected against unauthorized substitu-
strength of the algorithm and the type of data being
tion and modification. Secret [symmetric] and private [asymmetric] protected all play a role in determining the key life
keys need to be protected against unauthorized disclosure. Key man- cycle.
agement provides the foundation for the secure generation, storage,
distribution and destruction of keys.
Symmetric keys are essentially random numbers such
This paper is not intended to be a tutorial on key that the ability to determine a specific key, in the
management; however, there are other more appro- absence of a more efficient cryptanalytical attack, is
priate key management standards developed specifi- restricted to an exhaustive key search. Given sufficient
cally for the financial services industry, namely, the time and computing power, any key can be exhaus-
American National Standard X9.24 Retail Financial tively determined as was the case with the Third DES
Services Symmetric Key Management, Part 1: Using challenge mentioned above. Given a practical upper
Symmetric Techniques (2004) and Part 2: Using Asymmetric bound of computing power based on current technol-
Techniques For The Distribution Of Symmetric Keys (2006). ogy and costs, larger keys require more time to search

J. Stapleton and R. S. Poore 96

the possible values. Using the Third DES challenge as issue is the security of the exchange protocol between
baseline, every bit added to a key doubles the comput- the merchant and the third-party provider.
ing time. For example, given that the 56-bit key was As another example, a PAN independent tokeniza-
determined in 80,100 seconds, a 57-bit key (257 pos- tion scheme might use an incremental sequence num-
sibilities) can be extrapolated to 160,200 seconds. Of ber, a PRNG or a random number generator (RNG).
course there is a slight (nonzero) chance that the very For a sequential number, the order of the tokens may
first key tested was the correct key, so these estimates be significant depending upon the security of the
presume that the majority of the key space would need exchange protocol. For a PRNG scheme, the random-
to be searched. For such rough estimates one day can be ness of the seed value is not a vulnerability per se;
used for the 56-bit DES key. By the same extrapolation, however, the security of the exchange protocol is an
a 128-bit AES key (2128 possibilities) would require 12 issue. For an RNG scheme, the likelihood that the
trillion eons (an eon is a billion years). Of course, com- same random token might be generated for two differ-
puters are much faster since the 1999 DES challenge, ent PAN should only be a concern if the RNG is not
so using a doubling of computer power every year per very good. For more information refer to the American
Moore’s law, the approximate 10 years increase in com- National Standard X9.82 Random Number Generation,
puting power significantly reduces the time to a mere Part 1: Overview and Basic Principles (2006), Part 2:
12 million eons. The relative security strength of mod- Entropy Sources (2007), Part 3: Deterministic Random Bit
ern cryptography is clearly far superior as compared to Generator Mechanisms (2007) and Part 4: Random Bit
the PCI DSS data protection methods of masking and Generator Construction.
hashing, especially when they are used in combination The exchange protocol between the merchant and
with each other. the third-party provider must be secure such that an
adversary cannot eavesdrop or intercept to obtain the
PAN and the token regardless of whether the tokeniza-
Tokenization tion traffic is separate from the merchant’s credit card
Tokenization is a method by which a PAN is asso- authorization traffic. Presumably third-party providers
ciated with a reference number where a merchant only would service numerous merchants. The exchange pro-
needs to keep the token and a trusted third party keeps tocol must therefore be flexible enough to support
the PAN and manages the association. The token can merchants online in real time and in batch mode.
be generated and the association can be established Further, the exchange protocol must implement cryp-
either independently of the PAN or by using the PAN tography that provides data confidentiality, mutual
(dependent) as part of the data input to the tokeniza- entity authentication and data integrity. Thus the pro-
tion scheme. It is important to note that tokenization tocol must support encryption and digital signatures
methods (Visa Best Practices, 2010) are not uniformly or message authentication. The distribution of crypto-
defined. graphic keys necessary for the cryptography might be
For example, a PAN dependent tokenization scheme preshared or preferably be security exchanged online
might use a pseudo random number generator (PRNG, using public key infrastructure (PKI) technology. From
a hash, a keyed hash or an encryption algorithm. If the a security perspective such an implementation is non-
scheme relies on the PAN as input exclusive of a cryp- trivial and must be designed appropriately.
tographic key, then the token would be susceptible to
the same vulnerabilities and weaknesses discussed for • If an adversary can masquerade as a merchant and
hashing above. A PRNG is no stronger than the ran- spoof the service provider, then a dictionary of PAN
domness of the seed value, and if the PAN is the seed, and tokens might be generated. Further, if the service
the PRNG and the hash from a security perspective provider sends the PAN to the merchant on a token
have about the same strengths. If the scheme relies on query, the adversary might obtain PAN as cleartext.
the PAN as input inclusive of a cryptographic key, then • If an adversary can masquerade as a service provider
the token is much stronger and less vulnerable to an and spoof the merchant, then the PAN for that
exhaustive attack. However, the token provider would merchant can be obtained.
need to implement proper key management proce- • If an adversary can masquerade and spoof both
dures. In any of the schemes discussed above, another the merchant and the service provider, then the

97 Tokenization and Other Methods of Security for Cardholder Data

 man-in-the-middle attack allows the adversary to DataLossDB indicates that only 30% was online data
obtain PAN without detection. Even more prob- and only 14% was payment card data. Verizon recog-
lematic is a browser-in-the-middle attack where an nizes the bias of its DBIR as it is based on Verizon’s
adversary has infiltrated the merchant system and investigative response team engagements and not the
obtains PAN regardless of the exchange protocol. industry at large.
• If an adversary can eavesdrop on the tokenization The statistics are clearly evident that much of the
traffic it might be possible for sufficient informa- cardholder data breaches occur during the online
tion to be gathered and analyzed such that the authorization process versus the offline (stored) data.
tokenization method or its parameters might be For example, several cardholder data breaches have
compromised. occurred where either POS terminals were physically
compromised or malware was installed on POS sys-
Tokenization schemes are relatively new and the tems. If a merchant or a process needs to retain
overall architecture has yet to be fully defined (see cardholder data, tokenization can eliminate the threat
Figure 4 for examples). At the beginning of the pay- of a database breach. However, the business process
ment transaction a cardholder presents a credit card by which a merchant interacts with a tokenization ser-
to the merchant for which the merchant needs to get vice provider for dealing with clearing and settlement
authorization from the issuer. The PAN is a critical data or chargebacks has not been standardized, and again
element of the authorization request and must be pro- the exchange protocol needs to be cryptographically
vided to the issuer. The issuer cannot process a token. secured.
Thus the two basic transaction flows are either the mer- Another issue is the nature of the tokenized PAN.
chant completes the authorization and then gets the Legacy transaction processing systems and message for-
token from the service provider, or the merchant sends mats (ISO Financial Transaction Card,) mandate that
the authorization request to the service provider. The the PAN is a numeric field and often apply addi-
latter restricts the merchant to getting authorization tional edits. Hence, for purposes of transparency the
from the service provider, but in reality the larger mer- token or encrypted format is often a 16-digit numeric
chants deal with multiple transaction providers, so a field. Further, the LCD in some proprietary tokeniza-
sole sourced tokenization provider would not be a rea- tion schemes is recalculated. This may result in the
sonable solution. Conversely, smaller merchants tend undesirable effect of inadvertently mimicking another
to use a single transaction provider so relying on a tok- valid PAN such that the risk to the original PAN is
enization provider to also process the transaction is a unintentionally transferred to another PAN.
more viable option. However, the smaller merchants
have lower volumes and represent a less attractive tar-
get for a data breach where the larger merchants remain
more of a target.
CONCLUSION
The former transaction flow does not protect Tokenization will not eliminate the threat of card-
the merchant during the authorization process, and holder data breaches, since the third-party service
it is during authorization where much of the risk providers themselves will become targets instead of
resides. The Verizon 2009 Data Breach Investigations the merchants. Such third parties will need to undergo
Supplemental Report (2009) provides a comparison PCI assessments to ensure their compliance. Further,
between its Data Breach Investigations Report (DBIR) their assessments will need to include a detailed analy-
and the Open Security Foundation Data Loss Database sis of the exchange protocols, their business logic and
(DataLossDB). DataLossDB is a community research their key management systems because none of these
project aimed at documenting known and reported areas have been standardized. In fact, an American
data loss incidents worldwide. Both the DBIR and National X9 or ISO standard for tokenization is neces-
DataLossDB show that external breach sources are sary to ensure reasonable implementations and criteria
the most predominant (73% and 56%, respectively). for compliance assessments. The working draft X9.119
Further, the DBIR indicates that 93% of the breach Retail Financial Services – Requirements for Protection
asset source was online data versus devices or offline of Sensitive Payment Data is one such effort by the
(stored) data and that 84% was payment card data. The ANSI X9 Accredited Standards Committee.

J. Stapleton and R. S. Poore 98

 Masking, hashing, encryption and tokenization are ISO. ISO 8583 financial transaction card originated messages — inter-
change message specifications. www.iso.org
all methods to protect the PAN from unauthorized dis- ISO. (2005). 11568 banking — key management (retail), Part 1: Principles.
closure in an attempt to deter fraud. However, it must www.iso.org
be recognized that the PAN is an identifier used in ISO. (2005). 11568 banking — key management (retail), Part 2:
Symmetric ciphers, their key management and life cycle. www.iso.org
the authorization process, it is not authentication data. ISO/IEC. (2006). ISO/IEC 7812 identification cards — identification of
For example, personal identification numbers (PINs) issuers — Part 1: Numbering system. www.iso.org
ISO/IEC. (2007). ISO/IEC 7812 identification cards — identification
are used with debit transactions to authenticate the of issuers — Part 2: Application and registration procedures.
cardholder. Another example is the card security code www.iso.org
located on the back of many credit cards used with ISO. (2007). 11568 banking — key management (retail), Part 4: Asymm-
etric cryptosystems — key management and life cycle. www.iso.org
online credit transactions to ensure the physical pres- National Institute of Standards and Technology. (2007, March). NIST spe-
ence of the card in the hands of the cardholder. The cial publication 800-57: Recommendation for key management –
Part 1: General (revised); Part 2: Best practices for key management
basic problem is that signature based authentication organization. www.nist.gov
is the responsibility of the merchant and is not part National Institute of Standards and Technology. (2009, February). NIST
of the online authorization transaction upon which special publication 800-107 recommendation for applications using
approved hash algorithms. www.nist.gov
the merchant relies. Stronger authentication methods Payment Card Industry. (2008, October). Payment card industry data
such as PIN, challenge-response schemes, or possibly security standard – requirements and security assessment procedures,
version 1.2. www.pcisecurity
biometrics are needed for card present transactions Verizon. (2009). Verizon 2009 data breach investigations supplemental
at the merchant location and for online transac- report – anatomy of a data breach. www.verizon.com
tions on the Internet including mobile environments. Visa. (2010, July). Visa best practices: Tokenization, v1.0. www.visa.com
Visa. (2010, July). Visa best practices: Visa best practices for primary
The working drafts X9.117 Secure Remote Access – account number storage and truncation. www.visa.com
Mutual Authentication, X9.112 Wireless Management (2009, June). PAN encryption: The next evolutionary step? ISSA Journal,
pp 30–33.
and Security – Part 3: Mobile Commerce, and X9.122
Secure Consumer Authentication for Internet Debit
Transactions are all efforts to develop stronger authen- BIOGRAPHIES
tication methods.
Jeff Stapleton is the CTO with Cryptographic
Assurance Services with over 25 years experience in the
cryptography, security, financial and healthcare indus-
REFERENCES tries. Jeff has his BS and MS in Computer Science
American National Standard. (2004). American national standard X9.24
from the Universities of Missouri and has instructed
retail financial services symmetric key management, Part 1: Using at Wash U and UTSA. He has participated in devel-
symmetric techniques. www.X9.org oping ISO and X9 American National Standards for
American National Standard. (2006). American national standard X9.82
random number generation, Part 1: Overview and basic principles. over 20 years, the current 10-year chair of the X9F4
www.X9.org working group, and the President and Founder of the
American National Standard. (2006). American national standard X9.24
retail financial services symmetric key management, Part 2: Using
Information Assurance Consortium.
asymmetric techniques for the distribution of symmetric keys. Ralph Spencer Poore, CISSP, CFE, CISA, CHS-III,
www.X9.org CTGA, QSA, is the President & Chief Cryptologist,
American National Standard. (2007). American national standard X9.82
random number generation, Part 2: Entropy sources. www.X9.org Cryptographic Assurance Services LLC. Ralph has over
American National Standard. (2007). American national standard X9.82 35 years of information technology experience with
random number generation, Part 3: Deterministic random bit genera-
tor mechanisms. www.X9.org
emphasis on privacy, security, audit, and control in
American National Standard. (2007). American national standard X9.82 electronic commerce, enterprise systems, and enabling
random number generation, Part 4: Random bit generator construc- technologies. An author, speaker, inventor, and instruc-
tion. www.X9.org
Federal Information Processing Standards. (2008, October). FIPS publica- tor, he is well known in the information security
tion 180-3 secure hash standard. profession.

99 Tokenization and Other Methods of Security for Cardholder Data