Reducing Threats from Flawed Security APIs:
The Banking PIN Case∗
Mohammad Mannan and P.C. van Oorschot
School of Computer Science
Carleton University, Ottawa, Canada

Abstract
Despite best efforts from security API designers, flaws are often found in widely deployed security
APIs. Even APIs with a formal proof of security may not guarantee absolute security when used ina real-world device or application. In parallel to spending research efforts to improve security of theseAPIs, we argue that it may be worthwhile to explore design criteria that would reduce the impact of an
API exploit, assuming flaws cannot completely be removed from security APIs. We use such a design
philosophy in dealing with PIN cracking attacks on financial PIN processing APIs; several of these attacks
have been reported in the last few years, e.g., Berkman and Ostrovsky (FC 2007), Bond (CHES 2001).
Our solution is called salted-PIN : a randomly generated salt value of adequate length (e.g., 128-bit) is
stored on a bank card in plaintext, and in an encrypted form at a verification facility under a bank-chosensalt key. Instead of sending the regular user PIN, salted-PIN requires an ATM to generate a Transport
Final PIN from a user PIN, account number, and the salt value (stored on the bank card) through,e.g., a pseudo-random function. We explore different attacks on this solution, and propose variants ofsalted-PIN that can protect against known attacks. Depending on the solution variation, attacks at a
malicious intermediate switch now may only reveal the Transport Final PIN; both the user PIN and salt
value remain beyond the reach of an attacker’s switch. Salted-PIN requires modifications to service points(e.g., ATM, point-of-sale), issuer/verification facilities, and bank cards; however, changes to intermediateswitches are not required.

1

Introduction

Attacks on financial PIN processing APIs revealing customers’ PINs have been known to banks and security
researchers for years, e.g., [10], [6], [8], [9], [7] (failure modes of ATM PIN encryption were first discussed
in Anderson [2]). Apparently the most efficient of these PIN cracking attacks are due to Berkman and
Ostrovsky [4].1 However, proposals to counter such attacks are almost non-existent in the literature, otherthan a few suggestions; for example, maintaining the secrecy (and integrity) of some data elements related to
PIN processing (that are considered security insensitive according to current banking standards) such as the“decimalization table” and “PIN Verification Values (PVVs)/Offsets” has been emphasized [8], [4]. However,
implementing these suggestions requires modifications to all involved parties’ Hardware Security Modules(HSMs). Commercial solutions such as the PrivateServer Switch-HSM [1] rely mostly on tightly controllingthe key uploading process to a switch and removing unnecessary APIs or weak PIN block formats. Even if theflawed APIs are fixed, or non-essential attack APIs are removed to prevent these attacks, it may be difficultin practice to ensure that all intermediate (third-party controlled) switches are updated accordingly. Thusbanks rely mainly on protection mechanisms provided within banking standards, and policy-based solutions,e.g., mutual banking agreements to protect customer PINs.
A solution such as Mobile Password Authentication (MP-Auth) [14] is apparently capable of preventing
these attacks in addition to saving PINs from false ATM keypads and card reader attacks. However, MPAuth relies on public key operations, and thus cannot be deployed without significant modifications to∗ Version: March 31, 2009. Contact author: mmannan@scs.carleton.ca. A 6-page version of this manuscript appeared as ashort paper in Financial Cryptography and Data Security (FC) 2008 [16].
1 We encourage readers unfamiliar with financial PIN processing APIs and PIN cracking attacks to consult Section 2 forbackground, and Appendix A for a summary of attacks by Berkman and Ostrovsky [4].

1ATMs, switches and verification facilities. Another obvious solution (as suggested in [8], [4]) is to update the
PIN processing APIs, which also requires modifications to all involved parties’ Hardware Security Modules(HSMs).2
Designing solutions to mitigate PIN cracking attacks pose some interesting challenges. PIN transfers inbanking networks rely on symmetric key cryptography where the third-party controlled intermediate switchesalso possess shared keys to decrypt encrypted PINs (but have no access to issuer/verification keys). Althoughdecrypted PINs (and the decryption key itself) are not (ideally) accessible from outside of an HSM, API
flaws allow attackers to realistically extract enough information from the HSM (through legitimate API calls)
to enable PIN cracking attacks. Thus PIN cracking solutions must protect user PINs that travel throughthird-party switches which may be less security conscious or even actively malicious. Our solution attempts
to address threats from such an adversary as well as hostile parties at a verification facility with limitedaccess (e.g., one who can call API functions from an HSM, but cannot access verification keys). However,
we do not consider ATM frauds that are not scalable such as false keypads and card reader attacks [11].
One primary reason that PIN cracking attacks are possible is that actual user PINs, although encrypted,
travel from ATMs to a verification facility through several (untrustworthy) intermediate switches. If, forexample, hashed PINs were sent in an encrypted form, attackers may not be able to reveal user PINs even in
the presence of API flaws. However, as PINs are generally short (4 digits), an offline dictionary attack may
still easily allow recovery of actual PINs. From reviewing the history of API attacks, we also note that evena complete overhauling of PIN processing APIs may be subject to presently-unknown API flaws that might
be exploited to reveal user PINs. Therefore we seek a solution that precludes real user PINs being extracted
at verification facilities, and especially at switches (which are beyond the control of issuing banks), even in
the presence of API flaws. One possible solution in this direction is not to send the actual user PIN itself
through untrusted intermediate nodes. Our proposal follows such a direction.
While PIN cracking attacks get more expensive as the PIN length increases, it is unrealistic to consider
larger (e.g., 12-digit) user PINs, for usability reasons.3 As part of our proposal, we assume that a uniquerandom salt value of sufficient length (e.g., 128 bits) is stored on a user’s bank card, and used along withthe user’s regular four-digit PIN (Final PIN ) to generate4 a larger (e.g., 12 digit) Transport Final PIN(TFP). This TFP is then encrypted and sent through the intermediate switches. Thus we essentially expand
the 4-digit PIN to 12 digits. We build our salted-PIN solution on this simple idea. Our proposal requires
updating bank cards (magnetic-stripe/chip card), service-points (e.g., ATMs), and issuer/verification HSMs.
However, our design goal is to avoid changing any intermediate switches, or requiring intermediate switches
be trusted or compliant to anything beyond existing banking standards.
Salted-PIN provides the following benefits.
1. It does not depend on policy-based assumptions, and limits existing PIN cracking attacks even whereintermediate switches are malicious.
2. It significantly increases the cost of launching known PIN cracking attacks; for example, the setup
cost for the translate-only attack (see Appendix A) for building a complete Encrypted PIN Block(EPB) table now requires more than a trillion API calls in contrast to 10,000 calls as in Berkman and
Ostrovsky [4].
3. Incorporating service-point specific information such as “card acceptor identification code” and “cardacceptor name/location” (as in ISO 8583) into variants of salted-PIN, we further restrict attacks to belimited to a particular location/ATM.
Organization. Background on financial PIN processing is provided in Section 2. We outline the proposed
salted-PIN solution in Section 3. Known attacks that apply to the basic version of salted-PIN are discussed
in Section 4. In Section 5 we introduce three variants of salted-PIN to counter these attacks. Implementation
challenges to salted-PIN are also briefly discussed in Section 5. Section 6 concludes. In Appendix A, we
review several (representative) attacks as outlined by Berkman and Ostrovsky [4].
2 For an overview of HSMs and related attacks, see Anderson et al. [3]3 A 12-digit PIN can be constructed by storing eight digits on the bank card while a user memorizes the other four digits
as usual. However, as the real PIN is sent encrypted in this solution, attackers at a malicious switch can recover the PIN andcreate fake cards. (An anonymous FC 2008 referee pointed us to this idea and its relative advantages and disadvantages.)
4 For example, through a pseudo-random function (PRF).

2

2

BackgroundIn this section, we provide a basic overview of PIN processing and PIN block formats. More background onbanking networks is discussed elsewhere (e.g., [10], [17]).
PIN Processing Architecture. When a user inputs her PIN at an ATM, the PIN is encrypted to form an
Encrypted PIN Block (EPB) using a transport key shared between the ATM and the next switch connectedto the ATM. A switch can be a stand-alone facility for PIN transportation (and other related bank network
activities), or part of a bank’s verification facility. PIN blocks are processed inside Hardware Security
Modules (HSMs). Each switch shares a transport key with other switches that it is connected to. At averification center, a switch may also have the issuer key (for PIN verification). A standardized set of PIN
processing APIs is used for PIN creation, transportation, and verification. The intent is that this allows
banks to protect user PINs from application programmers (or anyone having access to PIN processing APIs)
at verification facilities as well as in switches.
There are several standardized PIN block formats (see below). An EPB may travel across several HSMs
on its way to a verification site. When transmitted from one HSM to another, re-formatting (i.e., translatingfrom one PIN block format to another) may be required. Thus all HSMs must implement translation APIs
to allow reformatting of an EPB. A switch decrypts an EPB, checks the PIN block format (e.g., validity of
PIN digits, PIN length), changes the format if required, and re-encrypts the PIN block with the destination
switch’s transport key. As all PIN operations are performed by HSMs, an application programmer (ideally)cannot learn anything about PINs transported as EPBs.
PIN Block Formats. We outline four PIN block formats from ISO 9564-1 [12], three of which are approved
by VISA for online transactions (e.g., through ATMs). Assume that a PIN is four decimal digits long. A
PIN block is composed of 16 hex digits, i.e., 64-bits. Let ‘P’ be a PIN digit (0 to 9), PAN the least significant
12 digits of a customer’s Primary Account Number (excluding the check digit), and let ‘A’ be a PAN digit(0 to 9). An ISO-0 PIN block is calculated as follows.
ISO-0 PIN Block = Original PIN Block ⊕ Formatted PAN
Here, Original PIN Block = 04 PPPP FFFF FFFF FF,
with ‘F’ denoting the hex digit F
Formatted PAN Block = 00 00AA AAAA AAAA AA
The leftmost zero in the original PIN block stands for ISO-0, and the digit 4 is the PIN length (which
could be as high as 12). An ISO-0 PIN block is the result of XORing an original PIN block with a formatted
PAN. The ISO-1 PIN Block format is 14 PPPP RRRR RRRR RR, where ‘R’ is a random hex digit (0 to F). The
ISO-2 PIN Block format is 24 PPPP FFFF FFFF FF, which is used only when creating a card. An ISO-3 PIN
block is calculated as follows.
ISO-3 PIN Block = Formatted PIN Block ⊕ Formatted PAN
Here, Formatted PIN Block = 34 PPPP RRRR RRRR RR,
with ‘R’ a hex digit from A to F
Formatted PAN Block = 00 00AA AAAA AAAA AA
In summary, ISO-2 is the weakest PIN format; it is not allowed for online processing, and it has not beenused in the PIN cracking attacks. ISO-0 and ISO-3 PIN blocks depend on a user PIN and account number.
The ISO-1 format is not bound to a user’s account number, and is recommended to be used in situations
where the PAN is unavailable. Attacks exploiting translate-only APIs (see Section A.1) depend on the factthat any ISO-0 and ISO-3 PIN formats can be translated to the less secure ISO-1 format (as the ISO-1
format does not depend on the user PAN). Translation APIs are also generally implemented by all HSMs.
IBM Calculate-Offset API. IBM’s calculate-offset API outputs an offset using a PAN and EPB. If thecalculated offset value corresponds to the stored value for that PAN, then the PIN inside the EPB is verified.
Offset values are assumed by the banking standards to be security insensitive, and are generally stored inplaintext. Fig. 1 illustrates how an offset value is calculated for PIN verification. Here, a Natural PIN iscalculated from a customer’s PAN, and the Final PIN is a customer-chosen PIN. Subtraction is digit by3

PAN

PIN Key(issuer)
Decimalization
Table

Encrypt PAN

Decimalize the encrypted PAN

Natural PIN (4 leftmost digits)EPB
PIN blockformatTransport
Key

Decrypt EPB and extract
Final PIN

Final PIN - Natural PIN

OffsetFigure 1: Offset calculation (adapted from [17])digit modulo 10. An issuer key (residing inside an HSM) is used to encrypt a user’s PAN. The encrypted
PAN may contain hex digits (A to F), and it is decimalized using a decimalization table (mapping hex digits
to decimal digits). The four left-most digits of the decimalized encrypted PAN constitute the user’s Natural
PIN. The Final PIN is extracted from the user’s PAN, EPB (containing the user’s encrypted Final PIN), thePIN block format, and the transport key (residing inside the HSM). The offset is calculated by subtracting
the Natural PIN from the Final PIN.
VISA PIN Verification Value (PVV). Fig. 2 depicts how a VISA PIN Verification Value (PVV) is
calculated. PVVs are used in a similar fashion as IBM offset values, and also (generally) stored in a plaintext
database. A customer’s PVV may be written on her bank card as well (for offline PIN verification).
EPB

PIN blockformatTransport
Key

Decrypt EPB and extract
Final PIN (4 digits)

PAN

Transformed Security Parameter (TSP) =11 PAN digits || PIN Key Index || Final PIN

PIN KeyIndex

PVV Key(issuer)
Decimalization
Table

Encrypt TSP

Extract 4 decimal digits

PVV

Figure 2: PVV calculation (adapted from [17], || denotes concatenation)

4

3

Salted PIN

Here we present the salted-PIN proposal in its simplest form.
Threat model and notation. Our threat model assumes attackers have access to PIN processing APIs
and transaction data (e.g., Encrypted PIN Blocks, account number) at switches or verification centers, but
do not have direct access to keys inside an HSM, or modify HSMs in any way. Attackers can also create fakecards from information extracted at switches or verification centers and use those cards (perhaps throughoutsider accomplices). We primarily consider large scale attacks such as those that can extract millions of
PINs in an hour [4]. We do not address attacks that are not scalable, such as card skimming, attacks on
EMV5 PIN entry devices [11], or cases where an accomplice steals a card and calls an insider at a switch orverification center for an appropriate PIN. PIN cracking attacks that we consider are successful only when
online PIN verification is applied (i.e., encrypted PINs are sent to a verification center for approval). In
addition to magnetic-stripe cards, these attacks are also valid for chip/EMV cards except when offline/onchip PIN verification is used (assuming card issuers allow EMV cards to fallback to magstripe processing
for backward compatibility or chip failure). Note that, if and when chip cards are deployed worldwide,
and offline PIN verification is the de facto mode of operation, most current PIN cracking attacks involving
intermediate switches become invalid, consequently eliminating the need for new solutions. Although suchcards are being gradually adopted, apparently magstripe cards (and the magstripe mode of operation of chipcards) along with existing flawed APIs will remain in operation for a long time to come. For example, wehave seen that the transition away from DES and triple-DES to more modern cryptographic algorithms hastaken far longer than many might have originally predicted. The following notation is used:
P AN
P IN
P INt
Salt
fK (·)

User’s Primary Account Number (generally 14 or 16-digit).
User’s Final PIN (e.g., 4-digit, issued by the bank or chosen by the user).
User’s Transport Final PIN (TFP).
Long-term secret value shared between the user card and issuing bank.
A cryptographically secure Pseudo-Random Function (PRF).6 Here K is the
PRF key.

Generating salted-PINs. A randomly generated salt value of adequate length (e.g., 128 bits, to makedictionary attacks infeasible) is selected by a bank for each customer. The salt is stored on a bank card (chipcard or magstripe) in plaintext, and in an encrypted form at a verification facility under a bank-chosen salt
key. API programmers (i.e., those who use HSM API) have access to this encrypted salt (but do not know
the salt key or plaintext salt values). Encrypted salt values also cannot be overwritten by API programmers.
A user inputs her PIN at an ATM, and the ATM reads the plaintext salt value from the user’s bank cardand generates a Transport Final PIN (TFP) as follows.
P INt = fSalt (P AN, P IN )

(3.1)
12

The PRF output is interpreted as a number and divided by 10 ; the 12-digit remainder (i.e., PRF
output modulo 1012 ) is chosen as P INt and treated as the Final PIN from the user. Note that the maximum
allowed PIN length by ISO standards is 12. The ATM encrypts P INt with the transport key shared withthe adjacent switch, and forms an Encrypted PIN Block (EPB). An intermediate switch decrypts an EPB,
(optionally) reformats the PIN block, and re-encrypts using the next switch’s transport key. Additional
functionalities are not required from these switches.
To set the initial offset or PIN verification value (PVV), an issuer generates a random PIN (e.g., 4 digitslong) and salt for a user, and then uses equation (3.1) to generate P INt . The transport key of the verification
HSM is used to encrypt P INt and form an EPB. This EPB is used to call a calculate offset/PVV function
with the user’s PAN and encrypted salt to generate the initial offset/PVV (note that each of these values is
now 12 digits long).
Offset/PVV verification with salted-PIN. The salted-PIN verification for the IBM offset method (recall
Section 2) is shown in Fig. 3. The Natural PIN is calculated from a PAN using an issuer’s PIN key. The
5 EMV is a growing standard for chip-based bank cards, initially developed by Europay, MasterCard, and VISA; see
http://www.emvco.com.
6 For example, as used in PwdHash [18].

5PAN
PIN Key(issuer)
Decimalization
Table

Encrypt PAN

Decimalize the encrypted PAN

Natural PIN (4 leftmost digits)
Encrypted
Salt

Salt Key(issuer)

Decrypt Salt

Transport Natural PIN =Decimalize(PRF(PAN, Natural PIN, Salt))

PAN

EPB
PIN block format

Decrypt EPB and extract
Transport Final PIN

Transport
Key

Transport Final PIN - Transport Natural PIN

OffsetFigure 3: Salted-PIN verification for the IBM offset method
encrypted salt value corresponding to the PAN is decrypted using a salt key (like the PIN key and transport
key, the salt key also resides inside an HSM). The Transport Natural PIN is generated from the Natural
PIN using equation (3.1). The Transport Final PIN is extracted from an EPB, and the Transport Natural
PIN is subtracted from it (digit by digit modulo 10 subtraction) to get the offset. This calculated offset
value is compared with the corresponding PAN’s stored (e.g., in a database) offset value. The salted-PIN
verification for VISA PVV is shown in Fig. 4. The salt value is appended at the end of the Transformed
Security Parameter (TSP), which is encrypted and decimalized to calculate the PVV. Note that we design
the offset/PVV verification functions to keep them similar to the existing functions although these can befurther simplified; for example, instead of storing offset/PVV values, EPBs directly may be stored andcompared with incoming EPBs.
Salted-PIN protection against PIN cracking attacks. We discuss attacks (e.g., translate-only [4]) thatreveal a user’s TFP in Section 4. An attacker with write-access to the PVV database at a verification facility
can choose any PIN for a specific account (see Section A.3). With the salted-PIN solution, an attacker canstill choose any PIN to pack in an EPB and write the resulting PVV to a database. However, without
knowing the salt value, overwriting a user’s PVV does not help in an attack for the following reason. The
salted-PIN verification function for PVV (Fig. 4) ensures use of the encrypted salt value as indexed by auser’s PAN; thus for a successful PVV verification, a user’s salt must be known or the encrypted salt value
must be replaced.

4

Attacks on Salted-PIN

We now discuss attacks against the basic version of salted-PIN.

4.1

Enumerating EPBs through Translate-only Attacks

Here the goal of an attacker is to create a table of EPBs, and then crack all or a subset of user accounts.
The following attacks in part follows an efficient variant of the translate attack as outlined by Berkman and
Ostrovsky [4]. For these attacks, we assume an attacker Mi is an insider (e.g., application programmer) ata switch or verification center, and an outsider accomplice Ma who helps Mi in carrying out user input at
an ATM. These attacks are possible for the following reason. Although a TFP is calculated from a long(e.g., 128 bits, sufficient to deter dictionary attacks) salt value, only 12 digits of the PRF output are used.

6

Encrypted Salt

Salt Key(issuer)

Decrypt Salt

EPB
Transport
Key

Decrypt EPB and extract
Transport Final PIN

PIN block format
PAN

Transformed Security Parameter (TSP) =PAN || PIN Key Index || Transport Final PIN || Salt

PIN KeyIndex

PVV Key(issuer)

Encrypt TSP

Decimalization
Table

Extract 12 decimal digits

PVV

Figure 4: Salted-PIN verification for VISA PVVThus an attacker only requires any pair of salt and PIN combination that can generate a targeted account’s
TFP instead of finding the actual salt/PIN values.
Targeting all accounts. Assume that Mi extracts the salt value (Salta ) and PAN from a card he possesses,
and uses equation (3.1) to generate the 12-digit TFP P INat (through software or a hardware device, using
any PIN P INa ). Let P INat consist of p1 p2 p3 . . . p12 where each pi (i = 1 to 12) is a valid PIN digit. Then
Ma inserts this card to an ATM, and enters P INa . Assume that the generated P INat is encrypted by the
ATM to form an EPB, E1 . Mi captures E1 at a switch. If E1 is not in the ISO-1 format, Mi translates
it into ISO-1 (to disconnect E1 from the associated PAN). Let the translated (if needed) E1 in the ISO-1
format be E1′ . E1′ is then translated from ISO-1 to ISO-0 using p3 p4 . . . p12 00 as the input PAN. This special
PAN is chosen so that the XOR of PIN positions 3 to 12 with PAN positions 1 to 10 removes p3 . . . p12 when
the translation API is called; i.e.,
PIN block inside E1′ = 0
Input PAN = 0
Resulting ISO-0 PIN block = 0

C
0
C

p1
0
p1

p2
0
p2

p3
p3
0

p4
p4
0

p5
p5
0

p6
p6
0

p7
p7
0

p8
p8
0

p9
p9
0

p10
p10
0

p11
p11
0

p12
p12
0

F
0
F

F
0
F

Assume the resulting EPB is Ep1 p2 which is the same as the one containing a TFP p1 p2 0000000000 with
PAN 0. Now we can create all EPBs containing every 12 digit TFPs starting with p1 p2 from Ep1 p2 . For
example, an EPB with p1 p2 q3 q4 . . . q12 as the TFP can be generated through transforming Ep1 p2 using PAN
q3 q4 . . . q12 00 (in ISO-0). Thus we can create all 1010 EPBs with TFPs from p1 p2 0 . . . 0 to p1 p2 9 . . . 9.
Starting from a different p1 p2 , all 1012 EPBs containing every 12 digit TFP can be generated as follows.
Ma uses the previous bank card (i.e., the same salt and PAN) with different PINs (obviously, including
wrong PINs) to calculate TFPs using software or a special device. When a TFP is found with the first twodigits different than p1 p2 , the corresponding PIN is entered at an ATM. The attacker Mi at the switch thengenerates another set of 1010 EPBs containing TFPs starting with this different p1 p2 . The attack continues
with different PINs until all 100 possible values of the initial two TFP digits are covered. Thus using these
100 EPBs containing TFPs starting with the different first two digits (i.e., from 00 to 99), Mi can create atable of EPBs for all possible TFPs (with corresponding PINs). The cost of building this table is slightly
over 1012 API calls (for each 100 Ep1 p2 , at most two API calls are required). The cost of selecting the initial
EPBs (i.e., that contain TFPs with two different starting digits) is insignificant as Ma can calculate TFPs
offline, i.e., without involving any API calls to HSMs.
To launch an attack, a valid EPB of a target customer is collected. The EPB is translated to ISO-1 (todecouple it from the target account, if not already in ISO-1), then to ISO-0 with PAN 0. The resulting EPB
is then located on the EPB table (as created in the setup phase). The corresponding PIN from the table can7now be used to exploit a card generated with the target’s PAN, and the attacker’s salt value (i.e., Salta ).
The cost of this attack is at most two API calls and a search of O(1012 ), i.e., O(240 ).
In summary, the setup cost of this attack is about 1012 API calls with a per account cost of two API
calls plus a search of O(1012 ). The same translate-only attack by Berkman and Ostrovsky [4] on the current
implementation of PIN processing requires only about 10,000 API calls as setup cost, and a per account costof two API calls plus a search of O(103 ).
Algorithm 1 Steps in the partial table attack
1: for i = 0 to 106 − 1 do
2:
Ec0 = TranslateISO−0 (Ec , i × 100)3:
if Ec0 is in the table then
4:
TFP in Ec = 106 × (six digit TFP from the table) + i
5:Salt and PIN values corresponding to Ec is used to generate a fake card
6:
exit
7:
end if
8: end for
Trade-off between table size and per EPB attack cost. The per account cost of the above attack is
not high enough to deter an attack. However, the setup cost of building the table with all one trillion EPBs
is apparently significant (although this is a one-time cost). By reducing the table size, the attack can belaunched with fewer API calls although the per EPB attack cost increases accordingly.
Assume that the attacker builds a table of 106 EPBs (i.e., one half of the original table size) containing
TFPs ending with six zeros (000000), i.e., storing only the first six digits of a TFP. With this table, anattacker can calculate TFP of any target EPB Ec in 106 steps (assuming the EPB arrives in the ISO1 format, or the attacker translates it into ISO-1); each step then requires one API call. The attack is
described in Algorithm 1.
Now the cost of attacking N accounts is 106 + N × 106 API calls. The attacker can also vary the tablesize and the number of steps for each target account. For any table size 10n for n ∈ {2, 3, . . . , 12}, therequired number of per account translate steps is 1012−n . Thus in general the cost of attacking N accounts
is 10n + N × 1012−n .

4.2

Replay Attack

In this attack, an adversary Mi at a switch or verification center collects a valid EPB Ec for a target PAN
Ac , and then creates a fake card with the account number Ac (and any salt value). Note that Mi here does
not know the actual salt value or PIN for the target account. An accomplice Ma uses the fake card withany PIN at an ATM, and the ATM generates a false EPB Ea . At the switch/verification center Mi locates
Ea in transfer, and replaces Ea with the previously collected correct EPB Ec . Thus the fake card will beverified by the target bank, and Ma can access the victim’s account.
Note that this attack works against the basic variant of salted-PIN as well as current PIN implementations
without requiring any API calls. Although quite intuitive, this attack has not been discussed elsewhere to
our knowledge.

5

Variants, Implementation Challenges and Lessons Learned

As we discussed in Section 4, the basic version of salted-PIN is vulnerable to several attacks. Other than
the replay attack, the setup cost of launching these attacks is not trivial as previous PIN cracking attacks(cf. [4]) although the per account attack cost is apparently manageable. In this section, we outline threevariants of salted-PIN to practically restrict these attacks by increasing the per account attack cost.
Variant 1: Service-point specific salted-PIN. If a fake bank card is created for a target account(e.g., through the attacks in Section 4), the card can be used from anywhere as long as it remains valid8

(i.e., the issuing bank does not cancel it). To restrict such attacks, we modify equation (3.1) as follows.
P INt = fSalt (P AN, P IN, spsi)(5.1)

Here spsi stands for service-point specific information such as a “card acceptor identification code” and“card acceptor name/location” as in ISO 8583 (Data Elements fields). The verification center must receive
spsi as used in equation (5.1). Although any PIN cracking attack (Section 4.1) can be used to learn a TFPor build a full/partial EPB table, the table is valid only for the particular values of spsi. Also, the replay
attack (Section 4.2) may succeed only when the accomplice exploits a compromised card from a particularATM. Thus this construct generates a localized TFP for each PIN verification, and thereby restricts thefake card to be used only from a particular location/ATM. Note that for this variant, the verification facility
cannot use PVV or Offset values, because they would be different for each ATM. Another verification value
would need to be designed.
Variant 2: Salted-PIN with double EPBs. ISO PIN block formats restrict PIN length to 12 digits in
an EPB. This length limit enables a search of O(240 ) in a pre-built table (see in Section 4.1). As a variant,instead of choosing 12 digits from the result of equation (3.1), we can take 24 digits (i.e., PRF output modulo
1024 ) and create two P INt blocks, each 12 digits long. As a result, two EPBs must be sent from an ATM,and a verification facility needs both EPBs to verify a user’s PIN. However, intermediate switches may notneed to be aware of this. An attack similar to Section 4.1 can be launched on each EPB separately, and two
tables can be built for both parts of a 24-digit TFP; the cost of building the table simply doubles (two TFP
tables, each has 1012 entries). Using the tables, a 24-digit TFP can be extracted from the two EPBs of any
target account. However, determining a valid pair of salt value and PIN is not straightforward as the attackin Section 4.1. To generate a fake card (i.e., to find an appropriate salt value and PIN for the intended TFP)
for this variant of salted-PIN, attackers must apparently carry out a computation of 1024 (i.e., O(280 )) steps.
However, this variant is vulnerable to the replay attack (Section 4.2) when equation (3.1) is used. Again,
service-point specific information as used in equation (5.1) for generating TFP can practically limit suchattacks.
Variant 3: End-to-end PIN encryption/MAC. Using the stored salt as an encryption key, end-to-end
PIN encryption can be achieved between an ATM and verification center. The salt value can also be used
for calculating a message authentication code (MAC) for a user’s Final PIN. This variant can secure PIN
transportation to the extent of the algorithm used for encryption or MAC. Thus it can effectively eliminate
PIN enumeration by an attacker at a switch or verification center. However, to restrict the replay attack(Section 4.2), one or more service-point specific items must be used with a PIN for encryption or MAC. Also,
this variant will require updating intermediate switches.
Implementation challenges. One implementation challenge for salted-PIN could be the storage requirement for the salt (39 decimal digits or 128 bits) that must be stored on a bank card. There are four possible
scenarios: (1) magnetic-stripe (magstripe) cards; (2) chip-card with a magnetic stripe at a magstripe reader
terminal; (3) chip-card with online PIN verification; and (4) chip-card with offline PIN verification. For
the last case, as a PIN does not leave the card, PIN cracking attacks are immaterial. For the first twocases, the amount of data that can be stored on a magnetic stripe is limited by ISO standards; for example,
according to ISO-7811, track one in a magstripe bank card holds 79 six-bit characters (plus a parity check),and track two holds 40 four-bit (plus a parity) characters. These two tracks are generally present in most
magstripe bank cards (there is also a third track on some cards). A salt may be stored on a magstripe cardby overloading non-essential data fields in track one (e.g., discretionary data, name, expiration date), andredundant fields in track two (e.g., PAN). Chip-cards offer significantly more storage capability, and thus forthe third case, accommodating the salt may not be an issue.
Salted-PIN requires that service points (e.g., ATMs, point-of-sale terminals) are capable of computing
PRF as in equation (3.1). Thus another implementation challenge is posed by the limited computing abilityof old magstripe reader terminals with limited CPU capabilities and cryptographic support of only a DES
chip; recent terminals (e.g., Motorola’s PD4750) generally operate on a 32-bit processor, and computing a
PRF is not a computational issue.
Lessons learned and discussion. Now we briefly discuss the lessons learned from designing different
variants of salted-PIN. These lessons, we believe, may help others in building robust security protocols.

91. Minimizing disclosure of reusable information. In the banking network, encrypted user PINs
are sent through multiple switches to the verification center for user authentication. Such a scheme
always bears the risk of exposing the long-term, reusable secret PIN. We argue that if long-term secrets
are converted to one-time use passcodes, then the discovery of a flaw may not necessarily lead to thecompromise of a reusable secret. Some techniques such as Lamport’s hash chain [13] have been publicly
known for decades. Unfortunately, applications of these schemes appear to be low.
2. Reducing the value of disclosed information. In general, currently attackers enjoy the benefitof compromising sensitive secrets once, and then reusing those multiple times. Localization of secrets
or sensitive information as applied in the service-point specific salted-PIN variant, may also be usefulin other settings, e.g., restricting identity fraud as a result of data breaches [15]. Making attacks
unattractive (i.e., the reward is less than the required efforts) is an easier goal than making attacks
impossible, and is often effective and sufficient. As defenders (such as API designers) and attackers areboth humans, it makes little sense, at least on a philosophical ground, to believe that defenders candesign protocols or techniques that cannot be defeated one way or another. However, we can “designfor damage control”, i.e., design protocols in such a way that when they break, they still do not expose
long-term user secrets. Incorporating such damage control techniques into the design itself may makeour protocols more resilient to attacks.

6

Conclusion

In the 30-year history of financial PIN processing APIs, several flaws have been uncovered. In this paper,
we summarize some API attacks from Berkman and Ostrovsky [4] for context, and introduce a salted-PIN
proposal and three of its variants to counter these attacks. Our preliminary analysis in this paper indicatesthat salted-PIN can provide a higher barrier to these attacks in practice by making them considerably
more expensive (computationally). We have discussed some deployment issues, but acknowledge that this
discussion is not exhaustive; deployment barriers may arise from unseen aspects. Salted-PIN is motivatedprimarily by the realistic scenario in which an adversary may control switches, and use any standard API
functions to reveal a user’s PIN; i.e., an attacker has the ability to perform malicious API calls to HSMs,
but cannot otherwise modify an HSM.
Our proposal of salted-PIN is intended to stimulate further research and solicit feedback from the banking community regarding: (1) whether salted-PIN may improve PIN security in real terms; (2) practicalbarriers of deploying salted-PIN; and (3) any significant weaknesses of salted-PIN. We focus on providing atechnical solution to update PIN processing APIs, some of which are well-known to be flawed. Instead of
relying, perhaps unrealistically, on honest intermediate parties (who diligently comply with mutual banking
agreements), we strongly encourage the banking community to invest effort in designing protocols that do
not rely on such assumptions which end-users (among others) have no way of verifying. It has been speculated [4] that PIN cracking attacks may explain numerous unexplained phantom withdrawals [5] as reported
by many ATM fraud victims. As reported [19] recently (June 20, 2008), the compromise of a third-party
PIN processor may have been the reason for a large number of Citibank card fraud.

Acknowledgements
This work benefited substantially from discussion and/or feedback from a number of individuals, including:Bernhard Esslinger of University of Siegen, Joerg-Cornelius Schneider and Henrik Koy of Deutsche Bank,
especially regarding attacks on the simple version of salted-PIN; a reviewer from a large Canadian bank;
Glenn Wurster; and anonymous reviewers. The first author is supported in part by an NSERC CGS. The
second author is Canada Research Chair in Network and Software Security, and is supported in part by an
NSERC Discovery Grant, the Canada Research Chairs Program, and NSERC ISSNet.

10

References[1] Algorithmic Research (ARX). PrivateServer Switch-HSM. White paper. http://www.arx.com/
documents/Switch-HSM.pdf.
[2] R. Anderson. Why cryptosystems fail. Communications of the ACM, 37(11), Nov. 1994.
[3] R. Anderson, M. Bond, J. Clulow, and S. Skorobogatov. Cryptographic processors – a survey. Proceedings of the IEEE, 94(2), Feb. 2006. Invited paper.
[4] O. Berkman and O. M. Ostrovsky. The unbearable lightness of PIN cracking. In Financial Cryptography
and Data Security (FC), volume 4886 of LNCS, Scarborough, Trinidad and Tobago, Feb. 2007.
[5] M. Bond. Phantom withdrawals: On-line resources for victims of ATM fraud. http://www.
phantomwithdrawals.com.
[6] M. Bond. Understanding security APIs. Ph.D. Thesis, Computer Laboratory, University of Cambridge,
2004.
[7] M. Bond. Attacks on cryptoprocessor transaction sets. In Workshop on Cryptographic Hardware andEmbedded Systems (CHES), Paris, France, May 2001.
[8] M. Bond and P. Zielinski. Decimalisation table attacks for PIN cracking. Technical report (UCAM-CLTR-560), Computer Laboratory, University of Cambridge, 2003.
[9] M. Bond and P. Zielinski. Encrypted? Randomised? Compromised? (When cryptographically secured
data is not secure). In Workshop on Cryptographic Algorithms and their Uses, Gold Coast, Australia,
July 2004.
[10] J. Clulow. The design and analysis of cryptographic APIs for security devices. Masters Thesis, Universityof Natal, Durban, South Africa, 2003.
[11] S. Drimer, S. J. Murdoch, and R. Anderson. Thinking inside the box: System-level failures of tamper
proofing. In IEEE Symposium on Security and Privacy, Oakland, CA, USA, May 2008.
[12] International Organization for Standardization (ISO). Banking – Personal Identification Number (PIN)
management and security – Part 1: Basic principles and requirements for online PIN handling in ATM
and POS systems, Apr. 2002. International Standard, ISO 9564-1.
[13] L. Lamport. Password authentication with insecure communication. Communications of the ACM,
24(11), Nov. 1981.
[14] M. Mannan and P. van Oorschot. Using a personal device to strengthen password authentication froman untrusted computer. In Financial Cryptography and Data Security (FC), volume 4886 of LNCS,
Scarborough, Trinidad and Tobago, Feb. 2007.
[15] M. Mannan and P. van Oorschot. Localization of credential information to address increasingly inevitabledata breaches. In New Security Paradigms Workshop (NSPW), Lake Tahoe, CA, USA, Sept. 2008.
[16] M. Mannan and P. van Oorschot. Weighing down “The Unbearable Lightness of PIN Cracking” (shortpaper). In Financial Cryptography and Data Security (FC), volume 5143 of LNCS, Cozumel, Mexico,
Jan. 2008.
[17] O. M. Ostrovsky. Vulnerabilities in the financial PIN processing API. Masters Thesis, Tel Aviv University, 2006.
[18] B. Ross, C. Jackson, N. Miyake, D. Boneh, and J. C. Mitchell. Stronger password authentication usingbrowser extensions. In USENIX Security, 2005.
[19] Wired.com. Citibank replaces some ATM cards after online PIN heist – update. Blog article (June 20,2008). http://blog.wired.com/27bstroke6/2008/06/citibank-issues.html.

11

A

Review of Earlier PIN Cracking Attacks

For convenience to the reader and for reference within, here we summarize several representative attacks
from Berkman and Ostrovsky [4]. For reasons of brevity, we omit how some specific assumptions requiredby these attacks are met, as well as any efficiency analysis of these attacks (e.g., how many API calls are
required for a given attack to succeed).

A.1

Translate PIN Block Attacks

We review the translate-only API attack which requires an attacker to generate/collect Encrypted PIN
Blocks (EPBs) of all possible PINs, and access to the translate API function. This attack reveals plaintext
PINs, and can be applied at a switch or verification facility. The steps in the attack are as follows.
1. Let Ax be any attacker chosen PAN.
2. Attackers collect/generate 10, 000 EPBs which pack all possible PINs in any ISO format (i.e., theformat and PAN of those EPBs are immaterial). Suppose i is any 4-digit PIN, and Ei′ packs i in any
ISO format.
3. Translate all 10, 000 EPBs to ISO-0 EPBs using Ax as the PAN. Assume Ei is the resulting EPB fromthe translation API.
Ei = TranslateISO−0 (Ei′ , Ax ), where i ∈ {0000 . . . 9999}.
Now Ei packs PIN i in the ISO-0 format (with respect to Ax ). Make a table with the resulting EPBs
and PINs, i.e., (Ei , i).
4. For any customer EPB, Ec , calculate
Et = TranslateISO−0 (TranslateISO−1 (Ec ), Ax ).
Here, an attacker first converts the customer EPB to ISO-1 (which unlinks a PIN with the corresponding
customer PAN), and then uses this result with the attacker’s chosen PAN to generate an EPB in ISO-0
format.
5. Locate Et in the table generated at step 3. The corresponding PIN is the PIN packed inside Ec .

A.2

Attacks Exploiting the IBM Calculate-Offset API

The steps in the IBM Calculate-Offset attack at a verification facility and intermediate switch are now
outlined.
Calculate-Offset Attacks at a Verification Facility. Here the attacker is someone at a verification
facility, e.g., an application developer. The steps in the attack are as follows.
1. Generate an EPB Ea that packs a known Final PIN P Fa .
2. For any customer account, Ac , calculate:offset = CalculateOffset(Ea , Ac ).
If the customer’s Natural PIN is P Nc , then offset = P Fa − P Nc . Here ‘−’ is digit by digit modulo
10 subtraction; offset and P Fa are known to the attacker. Thus the attacker learns the customer’s
Natural PIN. If the attacker can read the plaintext offset value of the customer, then the customer’s
Final PIN is revealed.
Calculate-Offset Attack at a Switch. The steps of a calculate-offset attack at a switch are as follows.
1. Generate an EPB Ea that packs a known Final PIN P Fa .
2. Select any (random) PAN Ax .
12

3. Assume that attackers do not have access to the real issuer key at a switch. However, they can calculate
a dummy offset using a dummy issuer key (i.e., whatever issuer key is available in the switch’s HSM):
offset d1 = CalculateOffset(Ea , Ax )i.e., offset d1 = P Fa − P Nxd . Here P Nxd is the dummy Natural PIN with respect to the account Ax .
So now P Nxd can be calculated as both P Fa and offset d1 are known.
4. For any customer EPB Ec which packs the customer’s Final PIN P Fc , calculate:offset d2 = CalculateOffset(Ec , Ax )i.e., offset d2 = P Fc − P Nxd . The value of P Nxd is known from the previous step, thus revealing thecustomer’s Final PIN.

A.3

Attacks Exploiting the VISA PIN Verification Value (PVV)

The steps in the VISA PVV attack at a verification facility and intermediate switch are outlined below.
PVV Attacks at a Verification Facility. Attackers need an EPB with a known PIN, and may need write
access to the issuer’s PVV database. Again, like offset values, PVVs are considered security insensitive. The
attack is as follows.
1. Generate an EPB Ea which packs a known Final PIN P Fa .
2. For any customer PAN Ac ,pvv = CalculatePVV(Ea , Ac ).
3. Use the calculated PVV with known PIN to create new bank cards (this may also require updating
the PVV database at the verification facility).
PVV Attacks at a Switch. Using 10,000 EPBs which pack all possible PINs, attackers can reveal candidate
PINs (less than two, on average) for any customer as follows. Note that the attack HSM here does not haveaccess to the real issuer PVV key; the attack succeeds if any PVV key is available.
1. Choose any PAN Ax .
2. Generate EPBs for all possible PINs; assume Ei packs PIN i, where i ∈ {0000 . . . 9999}.
3. For all EPBs generated in step 2, calculate PVVs with respect to Ax :pvvi = CalculatePVV(Ei , Ax ).
Now sort the values of pvvi and build a table of entries (pvvi , i). More than one (on average less thantwo) PINs may be indexed by a given PVV.
4. For any customer EPB Ec , compute
pvv = CalculatePVV(Ec , Ax ).
Use the resulting PVV as an index to the table built in step 3. The corresponding PIN is the customer’s
Final PIN P Fc ; in case of multiple PIN values indexed by pvv, P Fc is one of those values; building thetable using a different Ax may resolve collisions.

13